Karte 807: Basis-Image des gemeinsamen Runtime-Images auf Digest pinnen

[daniel-marthaler]

Was

runtime/Dockerfile: FROM eclipse-temurin:25.0.3_9-jre-alpine → …@sha256:28db6fdf60e3…, Tag bleibt als Lesehilfe stehen. Plus ein Kommentarblock mit Messung, Grund und Rueckweg.

Warum — der Tag traegt eine Version und ist trotzdem beweglich

	Index-Digest
lokal auf der Build-Maschine vorliegender Stand des Tags	sha256:c707c0d18cb9…
in der Registry heute hinter demselben Tag	sha256:28db6fdf60e3…

Gegenprobe, dass das nicht bloss zwei Digest-Ebenen desselben Bildes sind: c707c0d1 ist selbst ein Index (application/vnd.oci.image.index.v1+json) und kommt in den vier Plattform-Manifesten von 28db6fdf nicht vor.

Dritte Messung: die Layer des laufenden plaintext-runtime:jre25 (gebaut 27.06.2026) stimmen mit den 6 Layern des lokal vorliegenden Basis-Images nicht ueberein — der Stand, aus dem das heute laufende Runtime-Image entstand, ist nicht mehr identifizierbar.

Dieses Image ist die Basis jeder Plaintext-App: 16 laufende Container auf dem NAS (plaintext-{app,guild,iot,schuetu}-{int,prod}-{blue,green}), alle auf Image-Id 0ba0e1ad1402.

Beleg am echten Bau

POSITIVKONTROLLE  docker build --platform linux/amd64 -t plaintext-runtime:karte807-probe .
                  -> Successfully built 0b88f85425e4
NEGATIVKONTROLLE  derselbe Dockerfile mit erfundenem Digest
                  -> manifest for eclipse-temurin:…@sha256:0000… not found: manifest unknown
FUNKTIONSPROBE    java  -> openjdk version "25.0.3" 2026-04-21 LTS (Temurin-25.0.3+9)
                  sh    -> /bin/bash, /usr/bin/wget (GNU Wget 1.25.0), uid=1000(appuser)

Die Negativkontrolle ist der Punkt: sie zeigt, dass der Pin tatsaechlich greift und nicht still ignoriert wird. Die Funktionsprobe deckt den HEALTHCHECK ab, der wget braucht.

Die Probeimages sind wieder entfernt.

Wirkung und Rueckweg

Die Aenderung loest keinen Bau und keinen Rollout aus. runtime/build-runtime.sh wird von Hand gestartet; erst dort wirkt der Pin. Der naechste Bau liefert dann ein Runtime-Image auf neuerer Basis als das heute laufende — das waere ohne Pin genauso, nur unbemerkt und nicht wiederholbar.

Rueckweg: @sha256:… streichen. Aktualisieren: neuen Index-Digest ermitteln und ersetzen.

Kein Deploy

ci-cd-pipeline.yaml ist on: workflow_call (kein Push-Trigger), namespace-lint.yaml ist ein Lint. Ein Merge hier rollt nichts aus — Deploy-Slot 413 ist nicht noetig.

Was das NICHT loest

Die eigenen Images (plaintext-runtime, plaintext-website, plaintext-fwtool, volvo-login-automation, plaintext-kalenderimport) haben weiterhin keine RepoDigests — sie werden per docker save | ssh | docker load verteilt, und dieser Weg uebertraegt keine Digests. Der Weg dorthin fuehrt ueber GHCR und ist derzeit blockiert: der NAS bekommt auf docker manifest inspect ghcr.io/plaintext-gmbh/… als root denied (beide Pakete sind privat, anonym HTTP 403) — siehe Karte 775. Analyse, Optionen und Empfehlung stehen vollstaendig in Karte 807.