Files
craftvia/docs/PROMPT-lane-garage-infra.md
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
CI / audit (push) Canceled after 0s
CI / sbom (push) Canceled after 0s
Basis: Certvia dev@a48c5fb als Fundament für Craftvia
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 11:05:39 +02:00

3.0 KiB

Kickoff-Prompt — Lane A: Garage Infra & Deployment

Du übernimmst Lane A der Objektspeicher-Umstellung MinIO → Garage. Lies zuerst das Gesamtkonzept: docs/KONZEPT-garage-migration.md (v. a. §3 Reibungspunkt, §5 Zielarchitektur, §6 Lane A, §7 Runbook). Randbedingung: nur Test-Instanzen, keine Datenmigration — kompletter Neu-Deploy.

Repo & Branch

  • origin: git.certvia.de/msolarczek/certvia — Basis-Branch dev.
  • Zweiter Remote (interner Coolify-Test): local-gitea = gitea.192.168.1.155.sslip.io/msolarczek/ISMS-Tool. Ein Push auf dev löst den Test-Deploy aus.
  • Arbeite auf feature/garage-infra (aus dev), PR nach dev. Nach Merge dev auf beide Remotes pushen.

Ziel

Garage als Compose-Service, der minio in docker-compose.coolify.yml ersetzt — lauffähig auf der Test-Instanz, Admin-API erreichbar, Single-Node-Layout „ready".

Scope (nur diese Dateien/Bereiche)

  • docker-compose.coolify.yml: minio-Service durch garage ersetzen (nicht sofort löschen — auskommentiert/parallel lassen, bis Lane D abnimmt).
  • garage.toml (neu, als Config-Mount oder über Env) + ggf. docs/DEPLOY-COOLIFY.md ergänzen.
  • Keine App-Code-Änderung (das ist Lane C).

Vorgaben

  • Image pinnen auf eine aktuelle stabile Garage-Version (dxflrs/garage:vX.Y.Z), nicht latest.
  • Ports: 3900 = S3-API (von der App genutzt), 3903 = Admin-API (clusterintern, für Healthcheck/Provisioning), 3902 = Web optional. Nichts nach außen (Traefik) freigeben — genau wie MinIO bisher.
  • garage.toml: replication_factor = 1 (Single-Node), metadata_dir, data_dir, rpc_secret (aus GARAGE_RPC_SECRET), Block [s3_api] s3_region = "us-east-1", api_bind_addr = "[::]:3900", Block [admin] api_bind_addr = "[::]:3903", admin_token (aus GARAGE_ADMIN_TOKEN).
  • Volumes: garage_meta → /var/lib/garage/meta (KRITISCH), garage_data → /var/lib/garage/data.
  • Security analog Bestand: security_opt: no-new-privileges, cap_drop: ALL, Resource-Limits, restart: unless-stopped.
  • Healthcheck gegen Admin-API /health (3903).
  • Layout-Bootstrap dokumentieren: nach erstem Start Node einer Zone mit Kapazität zuweisen (garage layout assign … → garage layout apply). Falls möglich, an Lane B (Provisioning-Job) delegieren — dann hier nur vorbereiten.
  • Secrets: GARAGE_RPC_SECRET (32-byte hex) und GARAGE_ADMIN_TOKEN als Coolify-Env, literal setzen (nicht über ${…} referenzieren — bekannte Coolify-Interpolationsfalle). Keine echten Secrets ins Repo oder in Logs.

Definition of Done

  • Garage-Container startet in der Test-Instanz, Admin-/health grün, Layout „ready".
  • S3_ENDPOINT=http://garage:3900 intern erreichbar (kurzer aws s3 ls/curl-Nachweis).
  • garage_meta als zu sicherndes Volume in docs/DEPLOY-COOLIFY.md vermerkt.
  • Übergabepunkt an Lane B (Provisioning) klar dokumentiert (wie CLI/Admin-API erreichbar ist).

Abhängigkeiten

Lane B (Provisioning) baut direkt auf dir auf. Stimme das CLI-/Admin-API-Zugriffsmodell mit Lane B ab.