Container build en preview deployment via ZAD

[robbertbos]

Summary

• Multi-stage container/Dockerfile: MkDocs build + gehard nginx-base (RijksICTGilde, non-root, read-only-rootfs) met security headers (CSP, HSTS, etc.)
• Preview workflow: bouwt container en deployt naar ZAD op PRs en push naar main
• Production workflow: bouwt container en deployt naar ZAD op version tags (v*)
• Material Insiders dependency verwijderd (nu gratis in publieke repo)
• Omgevings-onafhankelijke image: draait standaard op de root, of onder een subpad/eigen domein via de optionele SITE_URL-env (stuurt interne links/beslishulp én canonical/sitemap). getBasePath() in modal.js leest dit basispad i.p.v. hardcoded paden.

Sluit #837

Test plan

• Lokaal bouwen: docker build -t algoritmekader -f container/Dockerfile .
• Lokaal draaien: docker run -p 8080:8080 algoritmekader → http://localhost:8080
• Beslishulp AI-verordening openen vanuit modal
• Onder een subpad: docker run -e SITE_URL=https://.../kader -p 8080:8080 algoritmekader (reverse proxy stuurt het prefix ongestript door)
• Preview deployment controleren via ZAD comment op PR
• Production deployment testen via tag push

[ravimeijerrig]

Info voor Algoritmeregister-team

Routing-eis voor de Algoritmekader-container (productie)

Wat je krijgt

Een container (poort 8080, unprivileged nginx) die de statisch gebouwde Algoritmekader-website serveert. De bestanden staan op de root van de webserver (/usr/share/nginx/html), dus bv. GET / → homepage, GET /voldoen-aan-wetten-en-regels/vereisten/ → die pagina.

De eis: prefix /kader/ moet vóór de container worden gestript

De site wordt gebouwd met SITE_URL=https://algoritmes.overheid.nl/kader/. Daardoor zet MkDocs en krijgen alle interne links, assets (CSS/JS)
en redirects het pad-prefix /kader/. De container zelf weet niets van dat prefix en serveert op root.

De ingress/reverse proxy vóór de container moet het /kader-prefix verwijderen voordat het request de container bereikt:

Publieke request (browser)	Wat de container moet ontvangen (poort 8080)
…/kader/	GET /
…/kader/voldoen-aan-wetten-en-regels/vereisten/	GET /voldoen-aan-wetten-en-regels/vereisten/
…/kader/assets/stylesheets/main.css	GET /assets/stylesheets/main.css

Doe je dat niet, dan laadt de homepage misschien wél, maar 404'en alle interne links en assets (de pagina komt kapot/zonder opmaak binnen).

Voorbeeld (Kubernetes nginx-ingress)

  metadata:
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /$2
  spec:
    rules:
      - host: algoritmes.overheid.nl
        http:
          paths:
            - path: /kader(/|$)(.*)
              pathType: ImplementationSpecific
              backend: { service: { name: algoritmekader, port: { number: 8080 } } }

(Op een ander platform: gelijkwaardige "strip path prefix /kader"-regel.)

Goed om te weten

• De container is bewust prefix-agnostisch: nginx draait met absolute_redirect off, dus redirects (bv. trailing-slash) zijn relatief. De browser plakt het
  /kader/-prefix er zelf weer voor. Je hoeft de container dus niet te configureren met het prefix — alleen strippen aan de ingress-kant.
• TLS termineert upstream (de container doet alleen HTTP op 8080). De container zet zelf wel al Strict-Transport-Security en de overige security-headers (CSP,
  X-Frame-Options, enz.) — die hoef je niet dubbel toe te voegen.
• Health/readiness: een GET op de root van de container (/ op 8080) levert 200 met de homepage. Via de publieke route is dat …/kader/.

Verificatie na deploy

1. …/kader/ → homepage met correcte opmaak (CSS/JS geladen, geen 404's in de network-tab).
2. Diepe link, bv. …/kader/voldoen-aan-wetten-en-regels/vereisten/ → laadt direct.
3. Zonder trailing slash, bv. …/kader/voldoen-aan-wetten-en-regels/vereisten → redirect naar de versie mét slash, met /kader/ behouden (niet naar algoritmes.overheid.nl/voldoen-…).
4. Een niet-bestaand pad → de 404-pagina van het Algoritmekader (niet de generieke ingress-404).

Beslispunt

Kan/mag de ingress het prefix niet strippen? Dan moet de container in plaats daarvan op de root van het domein gehost worden en gebouwd worden met SITE_URL=https://algoritmes.overheid.nl/ (zónder /kader/). Dat wijzigt wel de publieke URL. Graag bevestigen welke van de twee het wordt.

[ravimeijerrig]

Is dit mogelijk?
Claude: github.event.repository.name behoudt de hoofdletters van de repo ("Algoritmekader"), terwijl GHCR de package lowercase opslaat ("algoritmekader/preview", want metadata-action lowercased bij de push). Als de API hoofdlettergevoelig is, matcht deze query niet en blijven afgesloten PR-images in GHCR staan (cleanup faalt stil door de2>/dev/null + exit 0). Indien dit speelt: lowercasen met CONTAINER_NAME="${CONTAINER_NAME,,}".

[ravimeijerrig]

docs/html/beslishulp.html:9 hardcodes data-fontPath="/Algoritmekader/assets/". The RijksSansWeb-*.woff2 files live at docs/assets/, so this only resolves on GitHub Pages (/Algoritmekader). In the container the site is under /kader (or /pr{N}/kader), and sub_filter only rewrites /ak-runtime-base — not /Algoritmekader. So the iframe requests /Algoritmekader/assets/RijksSansWeb-*.woff2 → 404, and the beslishulp falls back to default fonts. This is exactly the base-agnostic goal the rest of the branch achieves, so it stands out.

@uittenbroekrobbert wat denk jij?

[uittenbroekrobbert]

Dank Ravi — sinds je comment (10 juni) is de routing-aanpak bewust omgedraaid (commit f71727a8, "Container serveert de base-path zelf"). De instructie hierboven is daarmee op één punt achterhaald: het prefix /kader moet juist níét meer gestript worden.

Nieuwe situatie: de container krijgt SITE_URL=https://algoritmes.overheid.nl/kader mee en serveert het volledige /kader/-pad zélf (nginx location /kader/, plus bare-prefix-redirect /kader → /kader/). De ingress moet het pad ongewijzigd doorzetten — pathType: Prefix, géén rewrite-target. SITE_URL en het doorgestuurde prefix moeten hetzelfde zijn.

Publieke request	Wat de container ontvangt (poort 8080)
…/kader/	GET /kader/
…/kader/voldoen-aan-wetten-en-regels/vereisten/	GET /kader/voldoen-aan-wetten-en-regels/vereisten/
…/kader/assets/stylesheets/main.css	GET /kader/assets/stylesheets/main.css

Ingress-voorbeeld (nginx-ingress) — zónder rewrite:

spec:
  rules:
    - host: algoritmes.overheid.nl
      http:
        paths:
          - path: /kader
            pathType: Prefix
            backend: { service: { name: algoritmekader, port: { number: 8080 } } }

Health/readiness: let op — met een prefix gezet geeft GET / op de container een 404 (er is alleen een location /kader/). Richt de probe op /kader/ (publiek …/kader/), die geeft 200.

Onveranderd geldig uit je comment: TLS termineert upstream (container doet alleen HTTP op 8080); de container zet zelf alle security-headers (HSTS, CSP, X-Frame-Options, …) — niet dubbel toevoegen; redirects zijn relatief (trailing-slash blijft binnen /kader/); een onbekend pad geeft de Algoritmekader-404.

Je beslispunt: strippen is dus niet meer aan de orde. De gekozen weg is unstripped doorzetten. De root-variant (SITE_URL=https://algoritmes.overheid.nl/ zonder /kader/) blijft enkel een fallback als een subpad-route echt niet kan.

[uittenbroekrobbert]

@ravimeijerrig uitgezocht tegen de echte bundle (v1.2.15): de beslishulp bakt z'n fonts zelf in als data:font/woff2 (RijksoverheidSansWebText/SerifWeb) en leest data-fontPath niet — alleen showCloseOnEnd[Msg], showExportPDF en showExplanationField worden gelezen (via currentScript.getAttribute("data-"+n)). Er was dus geen externe woff2-request en geen 404/fallback voor de beslishulp-fonts; de premisse klopte niet voor deze versie.

We hebben het dode data-fontPath-attribuut daarom verwijderd (83eb100a) i.p.v. het pad te repareren. De RijksSansWeb-fonts van de hoofdsite laden los daarvan al base-agnostisch via ../assets/ in extra.css.