Add db details to app README.
This commit is contained in:
10
.gitignore
vendored
10
.gitignore
vendored
@@ -7,9 +7,9 @@ secrets.yaml
|
||||
CLAUDE.md
|
||||
**/.claude/settings.local.json
|
||||
|
||||
# Wild Cloud
|
||||
**/config/secrets.env
|
||||
**/config/config.env
|
||||
|
||||
# Test directory - ignore temporary files
|
||||
test/tmp
|
||||
|
||||
# Test directory
|
||||
/test/tmp
|
||||
/test/test-cloud/*
|
||||
!/test/test-cloud/README.md
|
||||
|
@@ -130,6 +130,25 @@ To reference operator configuration in the configuration files, use gomplate var
|
||||
|
||||
When `wild-app-add` is run, the app's Kustomize files will be compiled with the operator's Wild Cloud configuration and secrets resulting in standard Kustomize files being placed in the Wild Cloud home directory.
|
||||
|
||||
#### External DNS Configuration
|
||||
|
||||
Wild Cloud apps use external-dns annotations in their ingress resources to automatically manage DNS records:
|
||||
|
||||
- `external-dns.alpha.kubernetes.io/target: {{ .cloud.domain }}` - Creates a CNAME record pointing the app subdomain to the main cluster domain (e.g., `ghost.cloud.payne.io` → `cloud.payne.io`)
|
||||
- `external-dns.alpha.kubernetes.io/cloudflare-proxied: "false"` - Disables Cloudflare proxy for direct DNS resolution
|
||||
|
||||
#### Database Initialization Jobs
|
||||
|
||||
Apps that rely on PostgreSQL or MySQL databases typically need a database initialization job to create the required database and user before the main application starts. These jobs:
|
||||
|
||||
- Run as Kubernetes Jobs that execute once and complete
|
||||
- Create the application database if it doesn't exist
|
||||
- Create the application user with appropriate permissions
|
||||
- Should be included in the app's `kustomization.yaml` resources list
|
||||
- Use the same database connection settings as the main application
|
||||
|
||||
Examples of apps with db-init jobs: `gitea`, `codimd`, `immich`, `openproject`
|
||||
|
||||
#### Secrets
|
||||
|
||||
Secrets are managed in the `secrets.yaml` file in the Wild Cloud home directory. The app's `manifest.yaml` should list any required secrets under `requiredSecrets`. When the app is added, default secret values will be generated and stored in the `secrets.yaml` file. Secrets are always stored and referenced in the `apps.<app-name>.<secret-name>` yaml path. When `wild-app-deploy` is run, a Secret resource will be created in the Kubernetes cluster with the name `<app-name>-secrets`, containing all secrets defined in the manifest's `requiredSecrets` key. These secrets can then be referenced in the app's Kustomize files using a `secretKeyRef`. For example, to mount a secret in an environment variable, you would use:
|
||||
@@ -187,3 +206,15 @@ After running these commands against your own Helm chart, you will have a Kustom
|
||||
- Use `component: web`, `component: worker`, etc. in selectors and pod template labels
|
||||
- Let Kustomize handle the common labels (`app`, `managedBy`, `partOf`) automatically
|
||||
- remove any Helm-specific labels from the Kustomize files, as Wild Cloud apps do not use Helm labels.
|
||||
|
||||
## Notice: Third-Party Software
|
||||
|
||||
The Kubernetes manifests and Kustomize files in this directory are designed to deploy **third-party software**.
|
||||
|
||||
Unless otherwise stated, the software deployed by these manifests **is not authored or maintained** by this project. All copyrights, licenses, and responsibilities for that software remain with the respective upstream authors.
|
||||
|
||||
These files are provided solely for convenience and automation. Users are responsible for reviewing and complying with the licenses of the software they deploy.
|
||||
|
||||
This project is licensed under the GNU AGPLv3 or later, but this license does **not apply** to the third-party software being deployed.
|
||||
|
||||
See individual deployment directories for upstream project links and container sources.
|
||||
|
Reference in New Issue
Block a user