customer-installer/CONTAINER_UPDATE_STRATEGIE.md

Strategie: Docker-Container in Kunden-LXCs auf aktuellem Stand halten

Ziel

Eine sichere, reproduzierbare und möglichst ausfallarme Vorgehensweise, um Docker-Container in Kunden-LXCs regelmäßig zu aktualisieren.

---

Ausgangslage / Annahmen

• Jede Kundeninstanz läuft in einem eigenen LXC.
• In den LXCs werden Container per Docker bzw. Docker Compose betrieben.
• Es gibt produktive Workflows (z. B. n8n/API), bei denen ungeplante Downtime minimiert werden soll.
• Nicht jede neue Image-Version ist automatisch kompatibel (Breaking Changes möglich).

---

Leitprinzipien

1. Planbar statt ad hoc: feste Update-Fenster.
2. Versionen kontrollieren: möglichst mit festen Tags, nicht blind latest.
3. Vor jedem Update sichern: Konfiguration, Volumes, Datenbank.
4. Nach jedem Update prüfen: Health-Checks + funktionaler Smoke-Test.
5. Rollback jederzeit möglich: alte Versionen/Backups kurzfristig wiederherstellbar.
6. Standardisieren: identischer Prozess für alle Kunden-LXCs.

---

Empfohlener Betriebsprozess

1) Inventarisierung pro Kunden-LXC

Für jede Instanz dokumentieren:

• Container/Services (Name, Image, Tag)
• Abhängigkeiten (DB, Reverse Proxy, externe APIs)
• Persistente Daten (Volumes, Bind-Mounts, DB)
• Kritische Funktionen (Login, Webhook, Jobs, API-Calls)
• Wartungsfenster und SLA-Anforderungen

Ergebnis: pro Kunde eine „Service-Karte“.

---

2) Release- und Update-Policy definieren

• Routinezyklus: z. B. monatlich.
• Security-Fixes: außerplanmäßig mit Priorität.
• Versionierungsregel:
  • bevorzugt semantische stabile Tags (x.y.z)
  • latest vermeiden in Produktion
• Freigabestufen:
  1. Test-/Pilot-LXC
  2. kleine Kundengruppe
  3. Vollausrollung

---

3) Pre-Update-Checks (Pflicht)

Vor jedem Update in einem LXC:

• Freier Speicherplatz ausreichend?
• Host/LXC-Ressourcen ok (CPU/RAM/IO)?
• Docker/Compose lauffähig?
• Externe Abhängigkeiten erreichbar?
• Letztes erfolgreiches Backup vorhanden?

Wenn ein Check fehlschlägt: kein Update.

---

4) Backup-Strategie vor Update

Mindestens sichern:

• .env / Compose-Dateien / relevante Skripte
• Persistente Volumes (App-Daten)
• Datenbanken (Dump, konsistent)

Empfehlung:

• Zeitstempel-basierte Backup-Ordner
• Aufbewahrung nach Rotation (z. B. 7/30 Tage)
• Wiederherstellung regelmäßig testen (Restore-Drill)

---

5) Update-Durchführung (kontrolliert)

Empfohlene Reihenfolge:

1. Neue Images ziehen (pull)
2. Geplante Recreate/Restart pro Service
3. Abhängige Services in sinnvoller Reihenfolge starten
4. Kurz warten, bis Services „healthy“ sind

Wichtig:

• Keine parallelen Updates über alle Kunden auf einmal.
• In Wellen ausrollen (Batching), z. B. 5–10 Kunden pro Fenster.

---

6) Post-Update-Validierung

Nach jedem LXC-Update:

• Container laufen?
• Health-Status „healthy“?
• Logs ohne kritische Fehler?
• Funktionaler Smoke-Test:
  • UI erreichbar
  • Login/Token funktioniert
  • Kern-Workflow/Webhook testbar
  • API-Endpunkt liefert erwartete Antwort

Nur bei erfolgreicher Validierung gilt das Update als abgeschlossen.

---

7) Rollback-Plan (verbindlich)

Rollback auslösen bei:

• Health-Checks schlagen fehl
• Kritischer Funktionsfehler
• Ungewöhnliche Fehlerhäufung in Logs

Rollback-Optionen:

1. Rückkehr auf vorherige Image-Tags
2. Wiederherstellung von Volumes/DB aus Backup
3. Services neu starten und Smoke-Test wiederholen

Ziel: klare RTO/RPO-Grenzen pro Kundentyp.

---

8) Monitoring & Reporting

• Zentrales Logging (mind. pro LXC abrufbar)
• Update-Protokoll je Kunde:
  • Start/Ende
  • alte/neue Version
  • Ergebnis
  • aufgetretene Fehler
• Regelmäßiger Report:
  • Update-Quote
  • Fehlerquote
  • Rollback-Häufigkeit

---

9) Automatisierungsgrad steigern (Roadmap)

Stufe 1 (kurzfristig):

• Standardisiertes manuelles Verfahren + Checklisten

Stufe 2:

• Gemeinsames Update-Skript mit:
  • Prechecks
  • Backup
  • Pull/Recreate
  • Health-Check
  • Ergebniscode

Stufe 3:

• Orchestrierte Wellen-Rollouts über mehrere LXCs
• Benachrichtigungen (z. B. Mail/Chat) bei Erfolg/Fehler
• Teilautomatischer Rollback

---

Konkrete Empfehlung für euren Kontext

1. Sofort: Für alle Kunden-LXCs eine Inventarliste + feste Image-Tags einführen.
2. Kurzfristig: Standard-Runbook für Update/Backup/Rollback als Teamprozess etablieren.
3. Mittelfristig: Einheitliches Update-Skript für alle Kunden-LXCs umsetzen.
4. Dauerhaft: Pilot-zu-Production-Rollout in Wellen mit verpflichtenden Health-Checks.

---

Beispiel-Runbook (kompakt)

1. Wartungsfenster starten
2. Prechecks ausführen
3. Backup erstellen
4. Images aktualisieren
5. Container kontrolliert neu bereitstellen
6. Health-Checks + Smoke-Test
7. Erfolg dokumentieren oder Rollback
8. Abschlussmeldung / Report

---

Risiken und Gegenmaßnahmen

• Breaking Changes in neuen Images
  → Release Notes prüfen, zuerst Pilot-LXC.
• Dateninkonsistenz bei Update
  → konsistente DB-Dumps, Service-Reihenfolge beachten.
• Zu viele gleichzeitige Änderungen
  → schrittweiser Rollout, kleine Batches.
• Fehlendes Rollback
  → verpflichtende Backup- und Restore-Tests.

---

Fazit

Der nachhaltigste Weg ist ein standardisierter Update-Lifecycle aus Inventarisierung, Precheck, Backup, kontrolliertem Rollout, Validierung und Rollback-Fähigkeit. Damit bleiben Docker-Container in Kunden-LXCs aktuell, ohne Stabilität und Betriebsfähigkeit zu gefährden.