stwaidele/dorfteich
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 22 Wiki Activity

[VS-NfD] Document the mirror procedure into an internal registry #218

New Issue
Closed
opened 2026-07-30 01:43:49 +02:00 by fable-5 · 1 comment
fable-5 commented 2026-07-30 01:43:49 +02:00
Collaborator
Copy Link

Plan reference: 20-massnahmenplan.md -> P1-3
ADR: ADR 0024
Effort: S (1 AT)
Depends on: #203

Context

An authority pulls images from its own registry, not from Docker Hub. The
procedure must be written so their operations team can execute it without
us.

Current state

  • Third-party images come from public registries by tag
    (deploy/compose/docker-compose.yml:186,206,221,237); own images from
    the project registry via IMAGE_PREFIX/TAG.
  • deploy/stages.md documents stage deployment, not mirroring.

Acceptance criteria

  • A step-by-step procedure mirrors every required image (ours and
    third-party) into an internal registry, by digest, including how the
    digest is verified after the copy.
  • Compose files take the registry prefix from configuration so no image
    reference needs editing per site.
  • The complete image list is generated, not hand-maintained, so it
    cannot drift.
  • Executed once end-to-end and the run recorded as evidence.
  • Documented in deploy/stages.md and the operations manual (#229).

Out of scope

Operating a registry for the customer, and the isolated test run (#220).

**Plan reference:** `20-massnahmenplan.md` -> P1-3 **ADR:** ADR 0024 **Effort:** S (1 AT) **Depends on:** #203 ## Context An authority pulls images from its own registry, not from Docker Hub. The procedure must be written so their operations team can execute it without us. ## Current state - Third-party images come from public registries by tag (`deploy/compose/docker-compose.yml:186,206,221,237`); own images from the project registry via `IMAGE_PREFIX`/`TAG`. - `deploy/stages.md` documents stage deployment, not mirroring. ## Acceptance criteria - [ ] A step-by-step procedure mirrors every required image (ours and third-party) into an internal registry, by digest, including how the digest is verified after the copy. - [ ] Compose files take the registry prefix from configuration so no image reference needs editing per site. - [ ] The complete image list is generated, not hand-maintained, so it cannot drift. - [ ] Executed once end-to-end and the run recorded as evidence. - [ ] Documented in `deploy/stages.md` and the operations manual (#229). ## Out of scope Operating a registry for the customer, and the isolated test run (#220).
fable-5 added this to the M28 — VS-NfD: offline/airgap deployment milestone 2026-07-30 01:43:49 +02:00
fable-5 added the
area:supply-chain
effort:S
vs-nfd
 labels 2026-07-30 01:43:49 +02:00
fable-5 commented 2026-07-31 15:01:47 +02:00
Author
Collaborator
Copy Link

Implemented in PR #286 (commit 2f7ba65), merged fast-forward (run 611 green); CD 616 green, readyz test+int ok. Generated image list (deploy/scripts/list-images.sh, resolves the compose incl. caddy profile - never hand-maintained), configurable REGISTRY_PREFIX for third-party images (digest pins unchanged; Docker verifies the same sha256 from any registry), IMAGE_PREFIX for own images - no per-site edits of references. Step-by-step procedure with digest verification in deploy/stages.md 5b incl. the pull/tag/push fallback (imagetools create stalled once against the Gitea registry - recorded). Executed once end-to-end as assessor-facing evidence: all four third-party images plus dorfteich-api:v0.12.0 (sha256:576f1646... identical on both sides) mirrored into a registry:2 - protocol docs/vs-nfd/95-mirror-protokoll.md. Operations manual airgap section updated.

Implemented in PR #286 (commit 2f7ba65), merged fast-forward (run 611 green); CD 616 green, readyz test+int ok. Generated image list (deploy/scripts/list-images.sh, resolves the compose incl. caddy profile - never hand-maintained), configurable REGISTRY_PREFIX for third-party images (digest pins unchanged; Docker verifies the same sha256 from any registry), IMAGE_PREFIX for own images - no per-site edits of references. Step-by-step procedure with digest verification in deploy/stages.md 5b incl. the pull/tag/push fallback (imagetools create stalled once against the Gitea registry - recorded). Executed once end-to-end as assessor-facing evidence: all four third-party images plus dorfteich-api:v0.12.0 (sha256:576f1646... identical on both sides) mirrored into a registry:2 - protocol docs/vs-nfd/95-mirror-protokoll.md. Operations manual airgap section updated.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
area:auth

   
area:docs

   
area:export

   
area:ops

   
area:storage

   
area:supply-chain

   
auth

Authentication, permissions, quotas

  
backend

API server (apps/api)

  
blocked

Blocked on external dependency/infrastructure

  
collab

Collaboration server (apps/collab)

  
deployment

Docker, CI/CD, hosting

  
docs

Documentation

  
effort:L

   
effort:M

   
effort:S

   
frontend

SPA (apps/web)

  
plugins

Plugin system and SDK

  
qa

Tests, fixtures, e2e

  
vs-nfd

   
vs-nfd:blocker
No Label
area:auth
area:docs
area:export
area:ops
area:storage
area:supply-chain
auth
backend
blocked
collab
deployment
docs
effort:L
effort:M
effort:S
frontend
plugins
qa
vs-nfd
vs-nfd:blocker
Milestone
Clear milestone
No items
No Milestone
M28 — VS-NfD: offline/airgap deployment
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stwaidele/dorfteich#218
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?