Claimio is a Spring Boot 3 backend (structured schadeformulier intake) deployed to k3s via Helm. Images are built by GitHub Actions and pushed to GHCR; CD runs helm upgrade against the project namespace. The Helm chart lives at the repo root in k8s/ (not helm/).
| | Production | Staging |
|---|---|---|
| Namespace | claimio | claimio-staging |
| Ingress host | api.claimio.nl | claimio.staging.glorylabs.nl |
| Backend image | ghcr.io/mahmoudholding/claimio/backend | same |
| Helm chart | k8s/ | k8s/ (values-staging.yaml) |
| Backend port | 8094 | 8094 |
Claimio deploys to the shared single-node k3s staging cluster. Before touching staging, read the shared ops docs — they are the source of truth for the cluster's quirks (and Claimio is the project where several of them were first confirmed):
CREATEROLE → Redis RESP2/standalone → NetworkPolicy → actuator probe paths → manual CD dispatch when CI ends failure on a non-blocking job). The pg18 CREATEROLE and the /actuator/health/** 403 (#88) fixes were both proven on Claimio.local-path PV; this is the recovery (quiesce → recreate stranded PVCs → re-run the CREATEROLE grant → staggered bring-up).PR merged to develop → staging auto-deploys (namespace claimio-staging)
PR merged to main → production auto-deploys (namespace claimio)
CI builds + pushes the image (.github/workflows/ci-backend.yml), then CD (.github/workflows/cd-backend.yml, "CD — Backend") runs on CI success.
⚠️ CD often skips because CI ends failure on a non-blocking job (Trivy / Flutter / Maestro / ZAP) even when Build & Push Image succeeded. When that happens, deploy the built image manually:
gh workflow run "CD — Backend" --ref develop \
-f image_tag=sha-<develop-head-7> \
-f environment=staging
# Staging
helm upgrade --install claimio k8s/ \
--namespace claimio-staging \
-f k8s/values-staging.yaml \
--set image.backend.tag=sha-<commit>
# Production
helm upgrade --install claimio k8s/ \
--namespace claimio \
--set image.backend.tag=sha-<commit>
Sealed from the Claimio vault (mahmoudholdingbv.1password.com), items claimio-secrets-{staging,production}, into secret claimio-backend-secret:
| Field | Purpose |
|---|---|
| database-password | DML-only app runtime user |
| database-admin-password | schema-owner / Flyway admin user |
| jwt-secret | JWT signing (≥32 chars) |
| jwt-previous-secret | previous JWT key (rotation overlap) |
| redis-password | Redis auth |
| auditpic-api-key | AuditPic integration |
| pii-encryption-key | PII field encryption |
| pii-hmac-key | PII HMAC index |
Regenerate the env-specific sealed manifest (needs a live op session or OP_SERVICE_ACCOUNT_TOKEN):
OP_SERVICE_ACCOUNT_TOKEN=<token> ./scripts/seal-secrets.sh staging # or: production
git add k8s/sealed-secrets/backend-secrets-staging.yaml
git commit -m "chore: update sealed secrets (staging)"
git push
CD applies k8s/sealed-secrets/backend-secrets-${ENV}.yaml before helm upgrade. Never sed-rename a SealedSecret's namespace — they are namespace-scoped and the cluster can't decrypt a re-targeted manifest.
kubectl get pods -n claimio-staging # backend should be 1/1
# health (no public DNS for staging — use Host-header curl or port-forward):
curl -k -H "Host: claimio.staging.glorylabs.nl" https://136.144.174.219/actuator/health
{"status":"UP"} = healthy. The k8s probes hit /actuator/health/liveness and /actuator/health/readiness, so SecurityConfig must permit /actuator/health/** (see recipe step 6b — confirmed on Claimio #88).
helm rollback claimio -n claimio # or claimio-staging
Reacties