Blue-Green Deployment

Einfach erklärt

Blue-Green Deployment nutzt zwei möglichst gleichartige Produktionsumgebungen. Eine ist live (Blue), die andere wird vorbereitet (Green). Bei einem Release wird der Traffic kontrolliert umgeschaltet – meist mit sehr kurzer oder keiner sichtbaren Unterbrechung.

Der Ablauf:

Zustand 1: Blue ist live
┌─────────────┐     ┌─────────────┐
│   BLUE      │ ←── │   Router    │ ←── Traffic
│   v1.0      │     └─────────────┘
│   (live)    │
└─────────────┘
┌─────────────┐
│   GREEN     │     (idle)
│   v1.0      │
└─────────────┘

Zustand 2: Deploy auf Green
┌─────────────┐     ┌─────────────┐
│   BLUE      │ ←── │   Router    │ ←── Traffic
│   v1.0      │     └─────────────┘
│   (live)    │
└─────────────┘
┌─────────────┐
│   GREEN     │     ← Deploy v2.0, Tests
│   v2.0      │
└─────────────┘

Zustand 3: Switch zu Green
┌─────────────┐
│   BLUE      │     (standby für Rollback)
│   v1.0      │
└─────────────┘
┌─────────────┐     ┌─────────────┐
│   GREEN     │ ←── │   Router    │ ←── Traffic
│   v2.0      │     └─────────────┘
│   (live)    │
└─────────────┘

Technischer Deep Dive

Kubernetes Blue-Green

# Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
        - name: app
          image: myapp:1.0
---
# Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
        - name: app
          image: myapp:2.0
---
# Service (Switch durch Selector-Änderung)
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: blue  # Ändern zu "green" für Switch
  ports:
    - port: 80

Switch durchführen:

kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'

Nginx Blue-Green

upstream blue {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

upstream green {
    server 10.0.0.3:8080;
    server 10.0.0.4:8080;
}

# Aktive Umgebung (ändern für Switch)
upstream active {
    server 10.0.0.1:8080;  # Blue
    server 10.0.0.2:8080;
}

server {
    location / {
        proxy_pass http://active;
    }
}

AWS mit Terraform

resource "aws_lb_listener_rule" "blue_green" {
  listener_arn = aws_lb_listener.main.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = var.active_color == "blue" ? 
                       aws_lb_target_group.blue.arn : 
                       aws_lb_target_group.green.arn
  }

  condition {
    path_pattern {
      values = ["/*"]
    }
  }
}

# Switch: terraform apply -var="active_color=green"

Datenbank-Strategien

Strategie	Beschreibung	Komplexität
Shared DB	Beide Versionen nutzen dieselbe DB	Niedrig
Backward-Compatible Migrations	Neue Spalten optional, alte bleiben	Mittel
Expand-Contract	Erst erweitern, dann alte Spalten entfernen	Hoch
Separate DBs	Daten-Sync zwischen Blue und Green	Sehr hoch

Rollback

# Problem erkannt? Sofort zurück zu Blue:
kubectl patch service myapp -p '{"spec":{"selector":{"version":"blue"}}}'

# Oder mit AWS:
aws elbv2 modify-listener --listener-arn $ARN \
  --default-actions Type=forward,TargetGroupArn=$BLUE_TG

Rollback ist meist schnell möglich, weil auf die vorherige Umgebung zurückgeschaltet werden kann – sofern Datenbank- und Zustandsänderungen kompatibel bleiben.