188 lines
5.4 KiB
Markdown
188 lines
5.4 KiB
Markdown
|
# 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.
|