Files
register-referentie/infra/helm/big-reference/templates/config.yaml
T
not 7a5840149c feat(k8s): Helm chart for the whole stack on a single-node cluster (refs #25)
One chart whose values.yaml is a near-literal transcription of
infra/docker-compose.yml, rendered by three generic templates (Deployment, Job,
Service) over a `workloads` map — so the two stacks can be diffed by eye instead
of by archaeology, and adding a service is a values edit.

Platform-forced deviations, each commented where it appears:
- `args`, never `command`: compose replaces the image CMD, Kubernetes replaces the
  ENTRYPOINT. The chart fails to render on `command`, because the symptom (postgres
  refusing to run as root, Keycloak exec-ing `start-dev`) is nothing like the cause.
- The four Django services apply their own setup_configuration in the web pod
  rather than in a separate init Job: both scripts migrate, and without compose's
  depends_on they race the same database.
- OpenZaak and Objecten are addressed by service FQDN, because Django rejects a
  single-label host in a URL — the reason compose passes container IPs around.
- NodePorts, no ingress; databases are emptyDir until persistence.storageClass is
  set, so the stack comes up on a cluster with no CSI driver.

The upstream config inputs stay in the repo and become ConfigMaps via
infra/helm/seed-configmaps.sh — the Kubernetes sibling of infra/seed-config.sh —
so the compose stack and the chart cannot fork. infra/helm/registry.yaml runs an
in-cluster registry because Talos cannot side-load an image and a laptop-side one
needs a root-level firewall change.
2026-09-04 17:51:21 +02:00

45 lines
1.7 KiB
YAML

{{- /*
Shared env blocks — the Kubernetes equivalent of the YAML anchors in
infra/docker-compose.yml (&oz-env, &nrc-env, &objecttypen-env, &objecten-env).
A workload picks them up with `envFrom`, so the web/celery/init variants of an
upstream image stay guaranteed-identical, and `kubectl get cm oz-env -o yaml`
shows what a pod actually got.
The *file* inputs (setup_configuration data.yaml, Keycloak realms, BPMN/DMN, the
seed scripts) are NOT here: they live in the repo and are turned into ConfigMaps
by infra/helm/seed-configmaps.sh, exactly as infra/seed-config.sh streams them
into the compose config volumes. Copying them into the chart would fork them.
*/ -}}
{{- range $group, $env := .Values.envGroups }}
---
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ $group }}-env
labels:
{{- include "big.labels" (dict "root" $ "name" (printf "%s-env" $group)) | nindent 4 }}
data:
{{- range $k, $v := $env }}
{{ $k }}: {{ tpl (toString $v) $ | quote }}
{{- end }}
{{- end }}
{{- /*
Portal OIDC config. The images bake config.json with the compose authority
(keycloak:8080), which a browser outside the cluster cannot resolve; these
ConfigMaps mount over it with the node address Keycloak's issuer is pinned to
(KC_HOSTNAME below), so the token the browser gets and the issuer the BFF
discovers are the same string. Same mechanism as infra/host-browser.yml.
*/ -}}
{{- range $realm := list "digid" "medewerker" }}
---
apiVersion: v1
kind: ConfigMap
metadata:
name: portal-config-{{ $realm }}
labels:
{{- include "big.labels" (dict "root" $ "name" (printf "portal-config-%s" $realm)) | nindent 4 }}
data:
config.json: |
{ "authority": "{{ printf "http://%s:%v" $.Values.host (index $.Values.nodePorts "keycloak") }}/realms/{{ $realm }}" }
{{- end }}