msolarczekandClaude Opus 5
c8e6f30a27
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>
38 lines
2.9 KiB
Markdown
38 lines
2.9 KiB
Markdown
# 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).
|