Files
jakman85andClaude Opus 4.8 d1248e6778 feat(backup): wire Velero + CNPG Barman to the live MinIO S3 target
Author the GitOps side of off-cluster backups against the on-Proxmox MinIO
(http://192.168.1.9:9000, path-style; buckets velero + cnpg).

Velero (R-STATE-03):
- HelmRelease (chart 8.x / Velero 1.15) + velero-plugin-for-aws init container +
  node-agent kopia File System Backup (deployNodeAgent, uploaderType=kopia,
  snapshotsEnabled=false). BSL default -> bucket velero, s3ForcePathStyle.
- Two daily Schedules: `daily` backs up the whole cluster's resources+PVC data
  (defaultVolumesToFsBackup opt-out) EXCEPT monitoring+unifi; `daily-resources-only`
  captures monitoring+unifi RESOURCES only (Prometheus TSDB, Loki 72h logs, and the
  ~7.4GiB UniFi VM disk are reconstructable — excluded from volume backup).
- velero-cloud-credentials SOPS Secret (cloud INI key, ns velero).
- Own non-gating Flux tier clusters/base/backup.yaml (dependsOn platform-config,
  wait:false) + clusters/dev SOPS decryption patch — mirrors headlamp.

CNPG native Barman PITR (R-IDP-05 / R-STATE-03):
- keycloak-db, nextcloud-db, semaphore-db gain spec.backup.barmanObjectStore
  (s3://cnpg/<cluster>, endpointURL MinIO, gzip WAL+data, 30d retention) + a daily
  ScheduledBackup (6-field cron, immediate) each.
- Per-namespace scoped-key SOPS Secrets (<db>-backup-credentials), same-ns only.
- render.py: emit-waves now recognizes <svc>-db-backup-credentials.sops.yaml as a
  DB-wave sidecar (+ self-test); wave-0 kustomization regenerated.

Creds mirror platform/backup/minio-credentials.sops.yaml (scoped key k3s-backup),
SOPS round-trip verified with the cluster age key. gate: green.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-08-28 22:37:17 -05:00
..

clusters/

Flux entrypoints and the environment-overlay model (R-ENV-02, R-GITOPS-01/02/03).

Governing spec: docs/05-gitops-and-delivery.md, docs/02-environments-and-provisioning.md, ADR-0004 (Flux).

Phase 0 scaffolding only. These are structurally-correct stubs. No cluster exists — nothing here reconciles until WS-INFRA delivers a cluster and bootstraps Flux (roadmap Phase 1).

Layout — base + overlay (never fork the base)

clusters/
  base/                 shared Flux objects (one authoring, both environments)
    flux-system.yaml    GitRepository — the reconciliation source (bootstrap → Gitea)
    platform.yaml       Flux Kustomization → ./platform   (reconciles first)
    apps-wave-0.yaml    Flux Kustomization → ./apps/wave-0 (dependsOn platform-config)
    apps-wave-1.yaml    Flux Kustomization → ./apps/wave-1 (dependsOn apps-wave-0)
    apps-wave-2.yaml    Flux Kustomization → ./apps/wave-N (dependsOn apps-wave-N-1)
    cluster-vars.yaml   ConfigMap of overlay knobs (BASE defaults)
    kustomization.yaml
  dev/                  ACTIVE build target — patches cluster-vars with dev values only
    kustomization.yaml
  prod/                 DESIGN-ONLY until roadmap Phase 7 — patches cluster-vars with prod values only
    kustomization.yaml

How the overlay model satisfies R-ENV-02

The base authors the reconciliation graph once. platform.yaml and apps.yaml (Flux Kustomizations) both declare postBuild.substituteFrom the cluster-vars ConfigMap. Platform and app manifests use ${TOKEN} placeholders for every value that legitimately differs between environments (issuer, replica counts, storage sizes, retention, node placement).

clusters/dev and clusters/prod differ ONLY by the values they patch into cluster-vars — they add no resources of their own and never copy/fork a base manifest. Promotion to prod (docs/02) is a change to the prod overlay's variables, nothing else.

How Flux is pointed at an environment

flux bootstrap (run by WS-INFRA in Phase 1) targets one environment's path per cluster:

# dev cluster
flux bootstrap ... --path=clusters/dev
# prod cluster (Phase 7 only — design-only until then)
flux bootstrap ... --path=clusters/prod

Bootstrap materializes the flux-system Kustomization that renders the chosen overlay, which pulls in base/ and applies the env-scoped cluster-vars.

Reconciliation order

GitRepository (flux-system)
        │
        ▼
Kustomization: platform  (./platform, substituteFrom cluster-vars)
        │  healthy
        ▼
Kustomization: apps-wave-0  (./apps/wave-0, dependsOn platform-config, substituteFrom cluster-vars)
        │  healthy
        ▼
Kustomization: apps-wave-1  (./apps/wave-1, dependsOn apps-wave-0)
        │  healthy
        ▼
Kustomization: apps-wave-N  (./apps/wave-N, dependsOn apps-wave-N-1)

Wave 0 dependsOn platform-config (transitively platform) so CNI/storage/TLS/DNS/gateway exist before any workload reconciles. The app tier is split into dependency-ordered WAVES (catalog/render.py --emit-waves): each apps-wave-<N> health-gates (wait:true) ONLY its own wave, so a crashloop in a later wave can no longer stall an earlier wave or block new revisions. See DESIGN-waves.md for the wave table + cutover runbook.

TODOs (later phases — do not action in Phase 0)

  • Source cutover (WS-GITOPS, Phase 6): base/flux-system.yaml currently points at the bootstrap source. After Gitea is onboarded, repoint spec.url to gitea.home.keithjackson.dev and keep an off-cluster mirror (spec docs/05 "Source-of-truth", CONTRIBUTING.md).
  • SOPS decryption (WS-SEC, Phase 1): add spec.decryption.provider: sops (age secret name only, never plaintext) to the platform/apps Kustomizations once the age key is bootstrapped (ADR-0007).
  • Split ordered Flux Kustomizations if intra-platform ordering needs to be explicit (e.g. a separate cilium/longhorn Kustomization others dependsOn).