stwaidele/dorfteich
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 22 Wiki Activity
issue-288-restore-partitioned
dorfteich/docs/vs-nfd/95-mirror-protokoll.md
Claude Fable 5 2f7ba65eef
Some checks failed
CI / Lint, typecheck, test (pull_request) Successful in 6m11s
Details
CI / Build container images (pull_request) Successful in 1m24s
Details
CI / Import/export fidelity gate (pull_request) Successful in 57s
Details
CI / Import/export fidelity gate (push) Blocked by required conditions
Details
CI / Auth e2e pack (pull_request) Successful in 8m49s
Details
CD / Build and push images (push) Successful in 20s
Details
CD / Deploy to Test (push) Successful in 13s
Details
CD / Smoke tests against Test (push) Successful in 1m25s
Details
CD / Promote to Int (push) Successful in 12s
Details
CI / Lint, typecheck, test (push) Successful in 6m24s
Details
CI / Build container images (push) Has been skipped
Details
CI / Auth e2e pack (push) Has been cancelled
Details
#218: mirror procedure into an internal registry 
Airgapped sites pull from their own registry (ADR 0024). The image list
is GENERATED (deploy/scripts/list-images.sh resolves the compose file
incl. the caddy profile) so a mirror can never silently miss a service;
third-party images gain a configurable ${REGISTRY_PREFIX:-} in the
compose file (digest pins unchanged - Docker verifies the same sha256
regardless of which registry serves it), own images keep IMAGE_PREFIX;
no image reference is ever edited per site.

Step-by-step procedure in deploy/stages.md 5b: generate list, copy
digest-preservingly (docker buildx imagetools create; plain
pull/tag/push as the documented fallback - the digest comparison closes
the loop either way), verify the digest in the mirror against the pin,
point the deployment via REGISTRY_PREFIX/IMAGE_PREFIX.

Executed once end-to-end and recorded as assessor-facing evidence
(docs/vs-nfd/95-mirror-protokoll.md): all four third-party images
mirrored digest-identically into a local registry:2, plus
dorfteich-api:v0.12.0 (sha256:576f1646... identical on both sides; the
imagetools stall against the Gitea registry is recorded with its
workaround). Operations manual's airgap section now lists the mirror
part as available.

Refs #218.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8
2026-07-31 14:33:04 +02:00

3.1 KiB
Raw Permalink Blame History

Mirror-Protokoll — Spiegelung in eine interne Registry (Issue #218)

Nachweis der einmaligen End-to-End-Ausführung des Mirror-Verfahrens aus deploy/stages.md §5b (ADR 0024). Prüfer-taugliche Belegstufe: live verifiziert — jede Zeile unten ist die tatsächliche Ausgabe des Verifikationsschritts, nicht eine Erwartung.

  • Datum: 2026-07-31
  • Umgebung: Dritt-Images: macOS-Arbeitsplatz (OrbStack-Docker) mit Ziel-Registry registry:2 auf localhost:5001; eigenes Image: Host ONE mit Ziel-Registry registry:2 auf 127.0.0.1:5002 — stellvertretend für die interne Registry der Behörde; das Verfahren ist registry-agnostisch.
  • Quelle der Image-Liste: deploy/scripts/list-images.sh mit TAG=v0.12.0 (der aktuelle Prod-Stand), generiert aus deploy/compose/docker-compose.yml inkl. caddy-Profil.
  • Kopierwerkzeug: Dritt-Images per docker buildx imagetools create (kopiert Manifeste registry-zu-registry ohne Re-Encoding — digest-erhaltend). Eigenes Image per docker pull + tag + push; der Digest-Vergleich schließt die Schleife (Beobachtung 31.07.: imagetools create stallte vom Arbeitsplatz gegen die Gitea-Registry, während die Registry-API sofort antwortete — der pull/push-Weg ist der robuste Ausweich, solange der Digest verifiziert wird).

Ergebnis je Image

Verifikation jeweils per docker buildx imagetools inspect localhost:5001/mirror/<name> — der Digest im Spiegel muss dem Pin aus der Compose-Datei gleichen.

Image Gepinnter Digest (Compose) Digest im Spiegel Ergebnis
caddy:2.10-alpine sha256:4c6e91c6ed0e2fa03efd5b44747b625fec79bc9cd06ac5235a779726618e530d identisch OK
postgres:17.5-alpine sha256:6567bca8d7bc8c82c5922425a0baee57be8402df92bae5eacad5f01ae9544daa identisch OK
pandoc/core:3.6 sha256:5b8a29d9b70d5d8ca766e5d1dcfc41916b23ab79276a80527be70516110f4c1e identisch OK
gotenberg/gotenberg:8 sha256:67097317623a503ba2a6a7e9ae8db6929a1f7e1bbd88077bacf2d325fbdab923 identisch OK
dorfteich-api:v0.12.0 sha256:576f16467563871a9655059fc9cdcce49e3951b54a8697065081a9a6832d2294 identisch OK

(Die drei übrigen eigenen Images web/collab/backup folgen exakt demselben Kommando mit anderem Namen; das Verfahren ist je Image identisch und die Liste kommt generiert aus dem Skript — stellvertretend wurde api als größtes eigenes Image kopiert.)

Abweichungen

Alle kopierten Digests stimmen mit den Pins bzw. dem Quell-Digest überein. Einzige Beobachtung: der Werkzeug-Stall von imagetools create gegen die Gitea-Registry (oben) — dokumentiert samt Ausweichweg in deploy/stages.md §5b.

Pflege

Bei jedem Digest-Update (deploy/stages.md §5a) und jedem Release wiederholt der Betreiber die Schritte 1–3 aus §5b für die geänderten Images; die Liste kommt IMMER frisch aus list-images.sh.