msolarczek/craftvia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
craftvia/docs/PROMPT-lane-garage-provision.md
T
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
Details
CI / audit (push) Canceled after 0s
Details
CI / sbom (push) Canceled after 0s
Details
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

2.9 KiB
Raw Permalink Blame History

Kickoff-Prompt — Lane B: Garage Provisioning (Bucket/Key/Rechte)

Du übernimmst Lane B der Umstellung MinIO → Garage. Lies docs/KONZEPT-garage-migration.md (v. a. §3 „einziger Reibungspunkt", §4 D3, §6 Lane B). Kern: Garage legt Buckets/Keys nicht über S3-CreateBucket an, sondern über Admin-API/CLI — das automatisieren wir hier, idempotent.

Repo & Branch

  • origin: git.certvia.de/msolarczek/certvia — Basis-Branch dev.
  • Zweiter Remote: local-gitea = gitea.192.168.1.155.sslip.io/msolarczek/ISMS-Tool (Push auf dev = Test-Deploy).
  • Arbeite auf feature/garage-provision (aus dev), PR nach dev.

Ziel

Ein idempotenter Init-Job garage-provision (Compose-Service, restart: no, analog migrate), der aus einer frisch gestarteten Garage reproduzierbar den betriebsbereiten Zustand herstellt.

Scope

  • Neuer Compose-Service garage-provision in docker-compose.coolify.yml (mit Lane A abstimmen; depends_on: garage).
  • Provisioning-Skript (scripts/garage-provision.* oder Shell im Job) — CLI oder Admin-API (HTTP). Entscheidung im Skript-Kommentar begründen.
  • Doku in docs/DEPLOY-COOLIFY.md.

Aufgaben (alle idempotent — mehrfach ausführbar ohne Fehler)

  1. Layout sicherstellen (falls Lane A das nicht schon macht): Node zuweisen + layout apply.
  2. Bucket(s) anlegen: isms-documents (Uploads); Backup-Bucket nur, falls Backup-Store auf S3 statt BACKUP_LOCAL_DIR läuft.
  3. Access-Key bereitstellen — deterministisch: bevorzugt vorhandenen Key importieren (garage key import mit den Werten aus S3_ACCESS_KEY/S3_SECRET_KEY der Coolify-Env), damit App-Env und Garage garantiert synchron sind. (Alternative: Key erzeugen und Ausgabe in Coolify-Secrets übernehmen — nur wenn Import nicht praktikabel; Trade-off dokumentieren.)
  4. Rechte setzen: Key → Bucket read/write (owner nach Bedarf).
  5. Verifikation: am Ende prüfen, dass Bucket existiert und der Key Schreib-/Leserecht hat; bei Fehlkonfiguration mit klarer Meldung + Exit ≠ 0 abbrechen.

Vorgaben

  • Idempotenz zwingend: vor jedem create Existenz prüfen; „already exists" als Erfolg werten (der Job läuft bei JEDEM Deploy).
  • Kein Secret in Logs (Key/Secret nicht ausgeben). GARAGE_ADMIN_TOKEN aus Env.
  • Nicht crash-loopen bei fehlender Config: klare Fehlermeldung, definierter Exit (der Job ist restart:no, kein Dauerdienst).
  • Keine App-Code-Änderung (Lane C).

Definition of Done

  • Aus „leerer Garage" stellt ein einziger Job-Lauf Bucket + Key + Rechte her; zweiter Lauf ist ein sauberer No-Op.
  • Danach greift HeadBucket der App erfolgreich (Übergabe an Lane C/D).
  • Runbook-Schritt in docs/DEPLOY-COOLIFY.md dokumentiert.

Abhängigkeiten

Braucht Lane A (Garage-Service + Admin-Zugriff). Liefert die Vorbedingung für Lane C (ensureBucket prüft nur) und Lane D (Abnahme).

Reference in New Issue View Git Blame Copy Permalink