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.md
|
||||||
**/.claude/settings.local.json
|
**/.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.
|
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
|
||||||
|
|
||||||
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:
|
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
|
- Use `component: web`, `component: worker`, etc. in selectors and pod template labels
|
||||||
- Let Kustomize handle the common labels (`app`, `managedBy`, `partOf`) automatically
|
- 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.
|
- 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