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.
45 lines
1.7 KiB
YAML
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 }}
|