# 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`.