Von Code Sentinel, Technical Project Manager bei Java Fleet Systems Consulting
Schwierigkeit: 🟡 Mittel
Lesezeit: 25 Minuten
Voraussetzungen: Docker-Grundlagen, CI/CD Pipeline Basics (Teil 1-7 oder vergleichbare Erfahrung)
📚 Was bisher geschah – Enterprise CI/CD Mastery
Bereits veröffentlicht:
- ✅ Teil 1-4: Foundations – Pipeline, Security Gates, Coverage, Quality
- ✅ Teil 5: Multi-Stage Builds – Build-Zeit von 20 auf 2 Minuten
- ✅ Teil 6: Container Security & SBOM – Supply Chain abgesichert
- ✅ Teil 7: Registry Integration – Image-Management richtig
Heute: Teil 8 – Blue-Green Deployments
Neu in der Serie? Kein Problem!
- 🟢 Einsteiger? Starte mit Teil 1 für den vollen Kontext
- 🟡 Erfahren? Du kannst hier einsteigen, Basics werden kurz erklärt
⚡ Das Wichtigste in 30 Sekunden
Dein Problem: Du willst deployen, aber jede Minute Downtime kostet Geld und Nerven.
Die Lösung: Blue-Green Deployment – zwei identische Umgebungen, sofortiger Switch, Rollback in Sekunden.
Heute lernst du:
- ✅ Wie Blue-Green Deployments funktionieren (auch für Anfänger verständlich)
- ✅ Praktische Implementierung mit Docker und nginx
- ✅ Automatisiertes Switching in der CI/CD Pipeline
- ✅ Rollback-Strategien, die wirklich funktionieren
Für wen ist dieser Artikel?
- 🌱 Anfänger: Du lernst das Konzept von Grund auf
- 🌿 Erfahrene: Best Practices und Production-Ready Konfiguration
- 🌳 Profis: Im Bonus: Database Migrations und Session Handling
Zeit-Investment: 25 Minuten Lesen + 45 Minuten Hands-on
👋 Code Sentinel: „Früher hätte ich Panik geschoben…“
Hey! 👋
Code Sentinel hier. Schön, dass du wieder dabei bist!
Real talk: Früher war Deployment-Tag für mich Stress-Tag. Jedes Mal die gleichen Fragen: „Was wenn was schiefgeht? Wie lange sind wir offline? Haben wir einen Rollback-Plan?“
Dann hab ich Blue-Green Deployments entdeckt. Und weißt du was? Deployment ist jetzt fast… entspannt. 😊
Ja, ich weiß – „Code Sentinel“ und „entspannt“ in einem Satz. Dinge ändern sich. 😉
Lass uns das gemeinsam angehen! 🚀
🟢 GRUNDLAGEN
Was ist ein Blue-Green Deployment?
Stell dir vor, du hast zwei identische Bühnen in einem Theater. Auf der einen (Blue) läuft gerade die Show. Auf der anderen (Green) bereitest du die neue Version vor.
Wenn alles bereit ist, drehst du einfach das Scheinwerferlicht um. Das Publikum merkt den Wechsel nicht mal.
Das ist Blue-Green Deployment:
💡 Neu hier? Was ist ein Load Balancer?
Ein Load Balancer ist wie ein Türsteher, der Besucher auf verschiedene Eingänge verteilt. Er entscheidet, welcher Server die Anfragen bekommt.
Beispiel: nginx, HAProxy, AWS ALB
Warum brauche ich das?
Ohne Blue-Green:
1. Alte Version stoppen ← 😰 DOWNTIME BEGINNT 2. Neue Version deployen ← 😰 DOWNTIME LÄUFT 3. Tests durchführen ← 😰 DOWNTIME LÄUFT 4. Probleme? Rollback! ← 😰 NOCH MEHR DOWNTIME
Mit Blue-Green:
1. Neue Version auf Green deployen ← Blue läuft weiter ✓ 2. Tests auf Green durchführen ← Blue läuft weiter ✓ 3. Traffic zu Green switchen ← Zero Downtime! 🎉 4. Probleme? Switch zurück! ← 2 Sekunden Rollback 🚀
Dein erstes Blue-Green Setup
Hier ist ein minimales Beispiel mit Docker Compose:
# docker-compose.yml
version: '3.8'
services:
# Der Load Balancer - der "Türsteher"
nginx:
image: nginx:alpine
ports:
- "80:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
depends_on:
- blue
- green
# Blue Environment - aktuell aktiv
blue:
image: myapp:1.0.0
environment:
- ENV_COLOR=blue
- APP_VERSION=1.0.0
# Green Environment - Standby für neue Version
green:
image: myapp:1.1.0
environment:
- ENV_COLOR=green
- APP_VERSION=1.1.0
Was macht dieser Code?
| Zeile | Erklärung |
|---|---|
nginx: | Der Load Balancer, der den Traffic steuert |
ports: "80:80" | Öffentlicher Port – hier kommt der Traffic rein |
volumes: ./nginx.conf | Die Konfiguration, die sagt: „Schick Traffic zu Blue oder Green“ |
blue: | Die aktuell aktive Produktionsumgebung |
green: | Die Standby-Umgebung für die neue Version |
💡 Du kennst die Basics schon? → Spring direkt zu PROFESSIONALS
🟡 PROFESSIONALS
Die nginx-Konfiguration für Blue-Green
# nginx.conf
upstream blue {
server blue:8080;
}
upstream green {
server green:8080;
}
# Aktive Umgebung - ändern für Switch!
map $uri $backend {
default blue; # ← Hier switchen: "blue" oder "green"
}
server {
listen 80;
location / {
proxy_pass http://$backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# Health Check Header für Debugging
add_header X-Backend $backend;
}
# Health Endpoints für beide Umgebungen
location /health/blue {
proxy_pass http://blue/health;
}
location /health/green {
proxy_pass http://green/health;
}
}
Best Practice: Health Checks vor dem Switch
Bevor du switchst, MUSS die neue Umgebung gesund sein:
#!/bin/bash
# switch-to-green.sh
echo "🔍 Checking Green health..."
# Health Check mit Retry
for i in {1..10}; do
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost/health/green)
if [ "$response" = "200" ]; then
echo "✅ Green is healthy!"
break
fi
echo "⏳ Attempt $i/10 - Green not ready yet..."
sleep 3
done
if [ "$response" != "200" ]; then
echo "❌ Green failed health check! Aborting switch."
exit 1
fi
# Switch durchführen
echo "🔄 Switching traffic to Green..."
sed -i 's/default blue/default green/' /etc/nginx/nginx.conf
nginx -s reload
echo "🎉 Traffic now going to Green!"
Stolperfallen vermeiden
❌ Fehler #1: Kein Health Check
# SCHLECHT - blindes Switching sed -i 's/default blue/default green/' nginx.conf nginx -s reload # Was wenn Green kaputt ist? 💥
✅ Besser:
# GUT - erst prüfen, dann switchen
if curl -f http://green:8080/health; then
sed -i 's/default blue/default green/' nginx.conf
nginx -s reload
fi
❌ Fehler #2: Vergessen, die alte Umgebung zu behalten
Nach dem Switch ist Blue immer noch da – und das ist gut so!
Lösche Blue nicht sofort. Du brauchst es für:
- Schnelles Rollback
- Vergleichstests
- Debugging
Mein Tipp: Halte die alte Umgebung mindestens 24 Stunden aktiv.
❌ Fehler #3: Unterschiedliche Konfigurationen
Blue und Green MÜSSEN identisch sein – außer der App-Version:
- ✅ Gleiche Umgebungsvariablen
- ✅ Gleiche Ressourcen-Limits
- ✅ Gleiche Netzwerk-Konfiguration
- ❌ NICHT: Unterschiedliche DB-Connections
💡 Du willst mehr? → Im BONUS findest du Database Migrations und Session Handling
🔵 BONUS
Database Migrations bei Blue-Green
Das ist der tricky Teil. Beide Umgebungen teilen sich die Datenbank:
┌─────────┐ ┌─────────┐
│ BLUE │ │ GREEN │
│ v1.0 │ │ v1.1 │
└────┬────┘ └────┬────┘
│ │
└───────┬───────┘
│
┌───────▼───────┐
│ DATABASE │
│ (shared) │
└───────────────┘
Das Problem: Was wenn v1.1 ein neues DB-Schema braucht?
Die Lösung: Expand-Contract Pattern
Phase 1: EXPAND (auf Green deployen) ───────────────────────────────────── - Neue Spalten hinzufügen (nullable!) - Neue Tabellen erstellen - Blue v1.0 ignoriert die neuen Felder - Green v1.1 nutzt sie Phase 2: MIGRATE (nach erfolgreichem Switch) ───────────────────────────────────── - Daten in neue Struktur migrieren - Alte Struktur bleibt (für Rollback) Phase 3: CONTRACT (nach Stabilisierung) ───────────────────────────────────── - Alte Spalten entfernen - Constraints hinzufügen - Rollback zu v1.0 nicht mehr möglich!
Beispiel Flyway Migration:
-- V1.1.0__add_email_verified.sql -- EXPAND Phase: Neue Spalte, nullable, kein Breaking Change ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL; -- Blue v1.0 funktioniert weiter - ignoriert die Spalte -- Green v1.1 nutzt die Spalte
Session Handling
Bei Blue-Green teilen sich beide Umgebungen die Sessions:
# Spring Boot application.yml
spring:
session:
store-type: redis
redis:
namespace: myapp:sessions
# Redis wird von BEIDEN Umgebungen genutzt
# Sessions überleben den Switch!
Performance-Zahlen aus der Praxis:
| Metrik | Ohne Blue-Green | Mit Blue-Green |
|---|---|---|
| Deployment Downtime | 2-5 Minuten | 0 Sekunden |
| Rollback Zeit | 5-15 Minuten | 2-5 Sekunden |
| Angst-Level beim Deploy | 😰😰😰 | 😊 |
💡 Praxis-Tipps
Für Einsteiger 🌱
- Starte lokal: Bau das Setup erst auf deinem Rechner auf, bevor du es in Production nutzt.
- Übe den Switch: Mach 10 Switches auf dem lokalen System. Bis es Routine ist.
Für den Alltag 🌿
- Automatisiere den Health Check: Nie manuell prüfen, ob die neue Version läuft.
- Dokumentiere jeden Switch: Wer hat wann von Blue auf Green gewechselt? Logging ist Pflicht.
Für Profis 🌳
- Canary vor Full Switch: Schick erst 5% des Traffics zu Green, dann 25%, dann 100%.
- Feature Flags kombinieren: Blue-Green für Infrastructure, Feature Flags für Features.
🛠️ Tools & Extensions
Für Einsteiger 🌱
| Tool | Warum? | Link |
|---|---|---|
| Docker Compose | Einfaches lokales Setup | docs.docker.com |
| nginx | Simpler Load Balancer | nginx.org |
Für den Alltag 🌿
| Tool | Warum? | Link |
|---|---|---|
| Traefik | Automatische Service Discovery | traefik.io |
| Consul | Service Mesh & Health Checks | consul.io |
Für Profis 🌳
| Tool | Warum? | Link |
|---|---|---|
| Istio | Full Service Mesh | istio.io |
| Argo Rollouts | GitOps Blue-Green | argoproj.io |
❓ FAQ (Häufige Fragen)
Frage 1: Brauche ich wirklich zwei komplette Umgebungen?
Antwort: Ja, aber „komplett“ heißt nicht „teuer“. Mit Containern und Cloud-Ressourcen kannst du Green nur während des Deployments hochfahren und danach wieder runterfahren. Pay-per-use macht Blue-Green erschwinglich.
Frage 2: Was ist der Unterschied zu Rolling Deployments?
Antwort: Bei Rolling Deployments werden Server nacheinander aktualisiert. Du hast während des Deployments BEIDE Versionen gleichzeitig aktiv. Bei Blue-Green ist immer nur EINE Version aktiv – sauberer, aber ressourcenintensiver.
Frage 3: Wie groß sollte der Health Check Timeout sein?
Antwort: 30 Sekunden als Basis, aber es hängt von deiner App ab. Eine Spring Boot App braucht vielleicht 45 Sekunden zum Starten. Eine Go-App ist in 2 Sekunden ready. Kenne deine App!
Frage 4: Kann ich Blue-Green mit Kubernetes machen?
Antwort: Absolut! Kubernetes macht es sogar einfacher. Mit Services und Deployments kannst du Labels nutzen, um Traffic zu steuern. Mehr dazu in Teil 9: Canary & Kubernetes.
Frage 5: Was mache ich mit Scheduled Jobs?
Antwort: Gute Frage! Jobs sollten nur auf EINER Umgebung laufen. Nutze Leader Election oder einen separaten Job-Runner, der unabhängig von Blue/Green ist.
Frage 6: Wie verhindere ich, dass beide Umgebungen gleichzeitig aktiv sind?
Antwort: Der Load Balancer ist dein Single Point of Control. Nur ER entscheidet, wohin der Traffic geht. Konfiguriere ihn richtig, und du hast nie beide aktiv.
Frage 7: Wie gehst du persönlich mit Deployment-Stress um? 🤔
Antwort: Früher? Kaffee, Checklisten, und schlaflose Nächte. Heute? Ich hab gelernt, dass gute Automatisierung und ein solides Rollback-Setup mehr wert sind als Perfektion. Und manchmal hilft es, kurz rauszugehen und durchzuatmen. Aber das gehört zu private logs. 📝
Frage 8: Ist Blue-Green auch für kleine Projekte sinnvoll?
Antwort: Ja! Gerade bei kleinen Projekten ist der Overhead gering, und du lernst die Patterns für später. Außerdem: Auch kleine Projekte haben User, die Downtime hassen.
📖 Enterprise CI/CD Mastery – Alle Teile
Für Einsteiger empfohlen: Starte bei Teil 1! ⭐
| Teil | Thema | Level | Status |
|---|---|---|---|
| 1 | Erste Pipeline | 🟢 | ✅ Veröffentlicht |
| 2 | Security Gates (OWASP + Trivy) | 🟢 | ✅ Veröffentlicht |
| 3 | Coverage Gates (JaCoCo) | 🟢 | ✅ Veröffentlicht |
| 4 | Quality Gates (SonarQube) | 🟡 | ✅ Veröffentlicht |
| 5 | Multi-Stage Builds | 🟡 | ✅ Veröffentlicht |
| 6 | Container Security (SBOM) | 🟡 | ✅ Veröffentlicht |
| 7 | Registry Integration | 🟡 | ✅ Veröffentlicht |
| → 8 | Blue-Green Deployments | 🟡 | 📍 Du bist hier! |
| 9 | Canary & Kubernetes | 🟡 | 📅 12.12.2025 |
| 10 | GitOps & Environments | 🔴 | 📅 Coming Soon |
| 11 | Jenkins Enterprise | 🔴 | 📅 Coming Soon |
| 12 | Multi-Platform & Finale | 🔴 | 📅 Coming Soon |
💬 Real Talk: Deployment Day
Java Fleet Büro, Donnerstag 16:30 Uhr. Code Sentinel steht am Whiteboard.
Nova: „Code, ich hab Angst vor dem Deployment morgen. Was wenn alles kaputtgeht?“
Code Sentinel: lächelt „Weißt du, früher hätte ich jetzt eine 47-Punkte-Checkliste rausgeholt. Heute sag ich: Lass uns Blue-Green machen.“
Kofi: „Blue-Green? Ist das nicht overkill für unser kleines Feature?“
Code Sentinel: „Real talk? Nein. Der Setup-Aufwand ist einmalig, aber der Schlaf, den du danach bekommst, ist unbezahlbar.“
Nova: „Aber was wenn Green nicht funktioniert?“
Code Sentinel: „Dann switchen wir in 2 Sekunden zurück zu Blue. Niemand merkt was. Kein Drama, keine Panik.“
Elyndra: grinst „Ich muss sagen, der neue entspannte Code gefällt mir. Früher hättest du jetzt von Worst-Case-Szenarien geredet.“
Code Sentinel: wird leicht rot „Naja, manchmal ist ‚gut genug mit Rollback‘ besser als ‚perfekt aber nie fertig‘.“
Kat: flüstert zu Nova „Hat das was mit seiner Nachbarin zu tun?“
Code Sentinel: „Das gehört zu private logs, Kat.“ 😉
🎁 Cheat Sheet
🟢 Basics (Zum Nachschlagen)
# Blue-Green Konzept BLUE = Aktuell aktive Production GREEN = Neue Version (Standby) SWITCH = Traffic von Blue zu Green umleiten ROLLBACK = Traffic zurück zu Blue # Minimaler Switch mit nginx sed -i 's/default blue/default green/' nginx.conf nginx -s reload
🟡 Patterns (Für den Alltag)
# Health Check vor Switch curl -f http://green:8080/health && \ sed -i 's/default blue/default green/' nginx.conf && \ nginx -s reload # Rollback (immer bereit halten!) sed -i 's/default green/default blue/' nginx.conf nginx -s reload
🔵 Advanced (Für Profis)
# Graceful Switch mit Drain
# 1. Neue Connections zu Green
# 2. Bestehende Connections auf Blue auslaufen lassen
# 3. Blue nach Timeout stoppen
upstream blue {
server blue:8080 backup; # Wird Backup nach Switch
}
upstream green {
server green:8080;
}
🎨 Challenge für dich!
Wähle dein Level:
🟢 Level 1 – Einsteiger
- [ ] Erstelle das Docker Compose Setup lokal
- [ ] Führe deinen ersten manuellen Switch durch
- [ ] Verifiziere, dass der Switch funktioniert hat
Geschätzte Zeit: 30-45 Minuten
🟡 Level 2 – Fortgeschritten
- [ ] Implementiere automatische Health Checks
- [ ] Baue ein Switch-Script mit Logging
- [ ] Integriere das Setup in deine CI/CD Pipeline
Geschätzte Zeit: 1-2 Stunden
🔵 Level 3 – Profi
- [ ] Implementiere Database Migrations mit Expand-Contract
- [ ] Baue Session-Sharing mit Redis ein
- [ ] Erstelle Monitoring für beide Umgebungen
Geschätzte Zeit: 2-4 Stunden
Teile dein Ergebnis! 🎉
📦 Downloads
Alle Code-Beispiele zum Herunterladen:
| Projekt | Für wen? | Download |
|---|---|---|
| blue-green-basic.zip | 🟢 Einsteiger | ⬇️ Download |
| blue-green-complete.zip | 🟡 Alle Levels | ⬇️ Download |
| blue-green-enterprise.zip | 🔵 Profis | ⬇️ Download |
Quick Start:
# 1. ZIP entpacken unzip blue-green-complete.zip # 2. In Verzeichnis wechseln cd blue-green-complete # 3. Starten docker-compose up -d # 4. Testen curl http://localhost/health
Probleme? → Troubleshooting-Guide | → FAQ
🔗 Weiterführende Links
📚 Für Einsteiger
| Ressource | Beschreibung |
|---|---|
| Docker Compose Docs | Offizieller Einstieg |
| nginx Beginner’s Guide | Load Balancing verstehen |
| 12 Factor App – Disposability | Warum schnelles Starten wichtig ist |
🛠️ Tools & Extensions
📖 Für Fortgeschrittene
| Ressource | Beschreibung |
|---|---|
| Martin Fowler: Blue-Green Deployment | Der Klassiker |
| AWS Blue-Green Guide | Enterprise-Perspektive |
🔧 Offizielle Dokumentation
💬 Geschafft! 🎉
Was du heute gelernt hast:
✅ Blue-Green Deployments Konzept verstanden ✅ Praktische Implementierung mit Docker und nginx ✅ Health Checks und automatisches Switching ✅ Rollback-Strategien für den Ernstfall
Egal ob du heute zum ersten Mal davon gehört hast oder dein Wissen vertieft hast – du hast etwas Neues gelernt. Das zählt!
Fragen? Schreib mir:
- Code Sentinel: code.sentinel@javafleet.de
Nächster Teil: Canary Deployments & Kubernetes – Wenn Blue-Green nicht reicht 🚀
Keep deploying, keep improving! 💚
Tags: #CICD #BlueGreen #Deployment #Docker #nginx #DevOps #ZeroDowntime
© 2025 Java Fleet Systems Consulting | java-developer.online
