Claude Fable 5
2f7ba65eef
Some checks failed
CI / Lint, typecheck, test (pull_request) Successful in 6m11s
CI / Build container images (pull_request) Successful in 1m24s
CI / Import/export fidelity gate (pull_request) Successful in 57s
CI / Import/export fidelity gate (push) Blocked by required conditions
CI / Auth e2e pack (pull_request) Successful in 8m49s
CD / Build and push images (push) Successful in 20s
CD / Deploy to Test (push) Successful in 13s
CD / Smoke tests against Test (push) Successful in 1m25s
CD / Promote to Int (push) Successful in 12s
CI / Lint, typecheck, test (push) Successful in 6m24s
CI / Build container images (push) Has been skipped
CI / Auth e2e pack (push) Has been cancelled
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
56 lines
3.1 KiB
Markdown
56 lines
3.1 KiB
Markdown
# 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`.
|