Von Code Sentinel, Technical Project Manager bei Java Fleet Systems Consulting
Was bisher geschah
- Teil 1: Docker Fundamentals – Container vs. VMs, Images, Volumes
- Teil 2: Compose & Multi-Container Apps – Spring Boot Personen-API + Postgres + pgAdmin
- Teil 3: Production-Ready – Multi-Stage Builds, Security Hardening, Healthchecks, Logs & SBOM
Jetzt kommt der nächste Schritt: Day-2 Operations & Orchestration Basics.
Denn nach dem Deployment beginnt der eigentliche Alltag: Systeme pflegen, sichern, überwachen und orchestrieren. Und für alle die die offiziellen Dokumentation einsehen wollen hier der Link.
Kurze Zusammenfassung – Das Wichtigste in 30 Sekunden
- Day-2 Operations = Alles nach dem Deployment: Updates, Backups, Monitoring, Alerting.
- Praxis: Wir zeigen Postgres-Backup/Restore und Observability mit Prometheus/Grafana.
- Orchestration Basics: Warum Compose nicht reicht, Einstieg in Docker Swarm & Kubernetes.
🔍 Was bedeutet „Day-2 Operations“?
Der Begriff kommt aus dem IT-Betrieb:
- Day 0: Planung & Architektur
- Day 1: Erstes Deployment – App läuft und ist erreichbar
- Day 2: Der Betrieb danach – Backups, Monitoring, Updates, Skalierung, Fehlerbehebung
Beispiel:
- Day-1:
docker compose up→ API liefert Personen → Freude 🎉 - Day-2: DB läuft voll → Restore nötig, Monitoring muss Alarme schicken → Routinearbeit.
👉 Kurz: Nicht nur starten, sondern dauerhaft am Laufen halten.
Moin! Code Sentinel hier – Zeit für den Realitäts-Check 🛡️
„It works on my machine“ ist kein Erfolg. Produktion heißt: laufend beobachten, sichern, patchen, reagieren.
Und sobald die App wächst, reicht Compose nicht mehr – du brauchst Orchestrierung.
1️⃣ Updates & Rollouts – Software lebt
Warum?
Software ist nie fertig. Bugs, Sicherheitslücken und neue Features erfordern Updates. Wer nicht regelmäßig deployed, sammelt technologische Schulden.
Wie?
- Immutable Tags: Nutze myapp:1.0.1 statt
latest. So ist immer klar, welche Version läuft. - Rolling Updates: Ersetze Container schrittweise, damit der Service erreichbar bleibt.docker compose up -d –no-deps –build app
- Blue/Green Deployment: Zwei Umgebungen (Blue aktiv, Green passiv). Update läuft auf Green → Tests → Umschalten. Zero-Downtime.
Praxis:
Unsere Personen-API könnte so von 1.0.0 auf 1.0.1 aktualisiert werden, ohne Ausfallzeit.
2️⃣ Backup & Disaster Recovery – Daten sind Gold
Warum?
Code ist ersetzbar, Daten nicht. Ein Datenverlust ist oft ein Totalschaden.
Backup-Frequenz:
- Entwicklung: 1x täglich
- Produktion: abhängig von Änderungsrate → oft stündlich oder kontinuierlich (Point in Time Recovery)
Restore-Szenarien:
- Fehler: Entwickler löscht Tabelle
- Hardware-Ausfall: Volume defekt
- Sicherheitsvorfall: Ransomware
Praxis im Projekt:
- Backup:./scripts/backup.sh
- Fehler-Simulation:docker exec -it persons-postgres-teil4 psql -U devuser -d devdb -c „DELETE FROM persons;“
- Restore:./scripts/restore.sh persons-postgres-teil4 devdb devuser backup_20250901_101500.sql
- Test:curl http://localhost:8080/api/persons | jq → Personen sind wieder da ✅
Merksatz: Backups sind nutzlos ohne regelmäßige Tests des Restores.
3️⃣ Observability – Logs, Metrics, Traces
Warum?
Ohne Beobachtbarkeit bist du blind.
- Logs: Ereignisprotokolle der App. Erkennen Fehler, Warnungen.
docker logs -f persons-app-teil4Prod: zentral sammeln (ELK, Loki). - Metrics: Zahlen wie CPU, Speicher, Request-Latenz.
→ Spring Boot Actuator liefert /actuator/metrics, Prometheus sammelt, Grafana visualisiert. - Traces: Ablauf eines Requests über mehrere Services hinweg. Hilfreich bei Microservices. Standard: OpenTelemetry.
Praxis:
Unsere API liefert Metriken via /actuator/prometheus. Prometheus + Grafana im Compose zeigen Diagramme.
4️⃣ Alerting – Probleme erkennen, bevor Kunden sie spüren
Warum?
Monitoring ohne Alarm ist wertlos.
Typische Alerts:
- Healthcheck schlägt fehl → App down
- Volume fast voll → Datenbank droht auszufallen
- API-Latenz > 2s → Performanceproblem
Tools: Prometheus Alertmanager, Grafana Alerts, Cloud Monitoring.
Praxisidee:
Alarm: „Wenn weniger als 8 Personen in der DB → Slack-Nachricht.“
5️⃣ Orchestration Basics – über Compose hinaus
Warum?
Compose ist super für Dev, aber Prod braucht mehr: Skalierung, Selbstheilung, Config/Secrets.
Docker Swarm
- In Docker integriert (
docker swarm init) - Nutzt Stacks statt Compose-Files
- Rolling Updates und Scaling out-of-the-box
Stackfile-Beispiel:
version: "3.9"
services:
app:
image: ghcr.io/org/persons-app:1.0.0
deploy:
replicas: 3
update_config:
parallelism: 1
order: start-first
Kubernetes Basics
- Industriestandard für Container-Orchestration
- Bausteine:
- Pod: kleinste Einheit (Container)
- Deployment: Skalierung & Updates
- Service: Zugriff von außen & LoadBalancing
- ConfigMap/Secret: Konfiguration & sensible Daten
Beispiel (k8s/persons-api-deployment.yml im Projekt):
apiVersion: apps/v1
kind: Deployment
metadata:
name: persons-api
spec:
replicas: 2
selector:
matchLabels:
app: persons-api
template:
metadata:
labels:
app: persons-api
spec:
containers:
- name: persons-api
image: ghcr.io/org/persons-app:1.0.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: persons-api-svc
spec:
type: ClusterIP
selector:
app: persons-api
ports:
- port: 8080
targetPort: 8080
Unterschiede:
- Compose: lokal, kleine Teams
- Swarm: einfach, kleine Cluster
- Kubernetes: Standard, mächtig, komplex
FAQ – Häufige Fragen
F1: Reicht Compose für Produktion?
Für kleine Setups ja. Ab Skalierung → Swarm oder Kubernetes.
F2: Wie oft sollte ich Backups fahren?
So oft, wie du Datenverlust verkraften kannst. (Regel: RPO = Recovery Point Objective)
F3: Brauche ich sofort Tracing?
Bei monolithischen Apps: Nein. Bei Microservices: Ja.
F4: Was passiert, wenn ich kein Alerting habe?
Du erfährst von Problemen erst, wenn Kunden anrufen. Zu spät.
F5: Warum Kubernetes?
Weil es Standard ist. Fast alle Cloud-Anbieter setzen darauf.
Teaser
Im nächsten Teil geht es um Security & Zero-Downtime Strategies:
- Canary Releases
- Blue/Green mit K8s
- Secret Management in der Cloud
Tags: #Docker #Day2Ops #Backups #Monitoring #Observability #Orchestration #Kubernetes #DevOps
