doc-rel

docker-compose release picker — weil latest kein Versionierungs-Konzept ist 🎯

Status- und Versions-Picker für docker-compose Stacks. Holt Tag-Listen aus Registries (Docker Hub, dock.mau.dev, generische OCI-v2), zeigt Drift gegen das aktuell deployte Image, lässt per fzf interaktiv wechseln, und kennt Postgres-Major-Upgrade-Recipes via pg_upgrade Helper-Container.

Features

• Status-Modus: Auf einen Blick — welches Image läuft, welche Version ist die neueste im Channel, was läuft tatsächlich (sha256 Running-Digest), Postgres- Majors über der aktuellen.
• fzf-Picker: Service → Channel → Version. Back-Navigation auf jeder Ebene. Meta-Tags (postgres:17) und latest-Tags landen prompt-nah, kein Endlos-Scrollen.
• Tag-Cache + Timeouts: --max-time 15, kein endloses Hängen bei langsamen Registries. Cache pro Run, kein doppeltes Fetchen.
• Drift-Anzeige: ↑3 → v2.6.1 direkt im Picker — sehen ohne klicken.
• Postgres-Upgrade-Recipe: bei Major-Wechsel automatisch copy-pasteable Schritte für pg_upgrade via tianon/postgres-upgrade:N-to-M, inkl. Disaster-Recovery-Dump, Rollback-Anweisung, Compose-Auto-Patching.
• Running-Digest-Log (.versions.log): pro Stack mitgeschrieben — welches sha256 lief wann. Rollback-Hilfe für Stacks die latest nutzen.

Aufruf

doc-rel                # Status aller Services
doc-rel p|-p|--pick    # fzf-Picker
doc-rel h|-h|--help    # Hilfe
doc-rel exec           # (TODO) Upgrade auto-ausführen
doc-rel docker-compose.yml          # expliziter compose-Pfad
doc-rel --pick docker-compose.yml   # Pfad + Mode

Integration via Taskfile (empfohlen)

Wenn du go-task-basierte docker-compose Wrapper nutzt (siehe holm-tools repo):

# TaskfileMain.yml
tasks:
  release:
    cmds:
      - bash /pfad/zu/doc-rel.sh {{.CLI_ARGS}}

Alias:

alias doc-rel='task release --'

Damit ist doc-rel system-zentral verfügbar in jedem Stack-Verzeichnis ohne per-Stack-Script-Duplikat.

Voraussetzungen

• bash ≥ 4.3 (assoc-arrays, local -n)
• curl, jq, awk, sed
• fzf (nur für --pick-Modus)
• docker compose (oder task template:doc wrapper)
• task (go-task, optional für system-zentrale Integration)

Postgres-Upgrade-Strategie

Bei Postgres-Major-Wechsel (z.B. 15 → 17) wird ein Recipe ausgegeben das:

1. Pre-Flight: Tabellenliste + Row-Counts in Logfile festhalten
2. Bridge stoppen: alle non-DB Services down (verhindert Writes)
3. Disaster-Dump: pg_dumpall ins Volume als Sicherheitsnetz
4. DB stoppen
5. Layout-Reorg: Alpine One-Shot reorganisiert <vol>/pg<N> oder root-cluster nach <vol>/<N>/data/ (tianon-Konvention)
6. pg_upgrade: via tianon/postgres-upgrade:N-to-M mit custom-entrypoint (Superuser aus compose-POSTGRES_USER, nicht hardcoded postgres)
7. Compose-Patch: image + PGDATA werden automatisch gesetzt
8. pg_hba.conf-Übernahme: vom alten Cluster (tianon-initdb erzeugt nur localhost-trust, fehlt der host all all all scram-sha-256-Eintrag)
9. vacuumdb --analyze-in-stages: Pflicht (pg_upgrade copyt keine Statistiken)
10. Verifikation + Diff gegen Pre-Flight
11. Bridge starten
12. Disaster-Dump mit RETAIN-<heute+4w>-Suffix markieren

Rollback: compose-PGDATA zurück auf <vol>/<old>/data/ — alter Cluster wurde nie angefasst.

Changelog

Siehe CHANGELOG.md.

Lizenz

MIT — siehe LICENSE. Entwickelt mit Unterstützung von Claude.ai (Anthropic).