Oleks
bdc43bb1d6
ci/woodpecker/push/container Pipeline was successful
The deploy/fleet-overlay templates had drifted from what actually runs in anton-helm-workloads (verified live + against the emdash-kotkanagrilli reference). Canonical design co-locates everything in the `kotkan` namespace: - source.yaml: GitRepository flux-system -> kotkan, so the HelmRelease chart sourceRef resolves same-namespace (no cross-namespace ref). - secrets.yaml: deploy-key Secret -> kotkan, defined once in the staging overlay; dropped the duplicate definition from the production overlay (production references the shared key by name). - image-automation.yaml: IUA write-back sourceRef anton-workloads-image-automation/flux-system -> anton-helm-workloads/kotkan (the existing read source already has push access). - README.md / DEPLOYMENT.md: namespace + ownership docs corrected.
53 lines
2.6 KiB
Markdown
53 lines
2.6 KiB
Markdown
# Fleet overlay templates
|
|
|
|
The YAMLs under `cms-plugins-staging/` and `cms-plugins-production/` are the
|
|
FluxCD manifests that drive each environment. They are **not** consumed from
|
|
this repo — they live here as a versioned blueprint, intended to be copied
|
|
into the workloads repo that Flux watches:
|
|
|
|
```
|
|
git.oleks.space/anton/helm-workloads
|
|
├─ cms-plugins-staging/ ← copy from deploy/fleet-overlay/cms-plugins-staging/
|
|
├─ cms-plugins-production/ ← copy from deploy/fleet-overlay/cms-plugins-production/
|
|
└─ kustomization.yaml ← add both directories to `resources:`
|
|
```
|
|
|
|
See `../../DEPLOYMENT.md` for the full pipeline and the first-time setup
|
|
checklist (deploy keys, sops secrets, Woodpecker secrets, DNS).
|
|
|
|
## Shape
|
|
|
|
Each env directory contains five files, mirroring the emdash-kotkanagrilli
|
|
layout in `~/projects/servers/fleet/apps/base/`:
|
|
|
|
- `source.yaml` — `GitRepository` pointing at this repo on the matching
|
|
branch (`staging` / `production`), restricted to `/deploy/helm` via the
|
|
`ignore` rule so Flux only pulls the chart.
|
|
- `helmrelease.yaml` — `HelmRelease` consuming the chart from `./deploy/helm`
|
|
in that `GitRepository`. Pinned by digest (see image-automation.yaml).
|
|
- `image-automation.yaml` — `ImageRepository` + `ImagePolicy` +
|
|
`ImageUpdateAutomation`. Watches the floating `staging` / `production`
|
|
tag in the Gitea OCI registry, resolves the current digest, and rewrites
|
|
the digest setter in `helmrelease.yaml` (which is what actually makes
|
|
`helm upgrade` see a change when CI retags the image).
|
|
- `secrets.yaml` — the pod's env-var secret
|
|
(`cms-plugins-{staging,production}-secrets`, in `kotkan`). The staging
|
|
overlay's `secrets.yaml` additionally defines the shared SSH deploy key
|
|
(`cms-plugins-deploy-key`, also in `kotkan` so the GitRepository
|
|
`secretRef` resolves same-namespace); production references that same key
|
|
by name and does NOT redefine it. **Templates here are NOT encrypted** —
|
|
sops-encrypt them before pushing to anton-helm-workloads.
|
|
- `kustomization.yaml` — bundles the above.
|
|
|
|
## Why this lives in two repos
|
|
|
|
The chart (`deploy/helm/`) ships with the app — that way a chart change
|
|
is reviewed and tagged alongside the code that depends on it. The
|
|
HelmRelease references the chart as a path inside a `GitRepository`,
|
|
not as an OCI artifact, so there's no "publish chart" step in CI.
|
|
|
|
The HelmRelease itself lives in the workloads repo because that repo is
|
|
the source of truth for what runs on the kotkanagrilli.fi subdomain
|
|
pool. Same convention as the existing `kotkanagrilli/` (legacy WP) and
|
|
`hello-kotkan/` entries there.
|