# 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.