Wie funktioniert Blue-Green Deployment?
Beim Blue-Green Deployment existieren zwei identische Produktionsumgebungen — Blue (aktiv) und Green (Standby). Ein neues Release wird auf die inaktive Umgebung deployt und getestet. Durch Umschalten des Load Balancers wird die neue Version live — bei Problemen kann sofort zurückgeschaltet werden.
Blue-Green & Canary im ArgoCD-WorkshopBlue-Green Deployment löst das Problem der Ausfallzeit beim Release durch Redundanz. Es existieren zwei vollständig funktionsfähige, identische Produktionsumgebungen. Eine ist aktiv und bedient den gesamten Live-Traffic (Blue), die andere steht bereit (Green). Eine neue Version wird vollständig auf die inaktive Umgebung deployt und dort getestet, während die aktive ungestört weiterläuft.
Der eigentliche Release ist dann ein einziger, schneller Schritt: Der Load Balancer oder Router schwenkt den Traffic von Blue auf Green um. Die neue Version ist sofort und vollständig live. Tritt ein Problem auf, ist der Rollback ebenso schnell — ein erneutes Umschalten zurück auf die alte Umgebung, die unverändert bereitsteht.
Der Hauptvorteil ist nahezu unterbrechungsfreier Betrieb mit sehr schnellem, risikoarmem Rollback. Der Preis dafür ist Ressourcenaufwand: Es müssen zeitweise zwei vollständige Produktionsumgebungen vorgehalten werden. In Cloud-Umgebungen mit elastischer Skalierung ist das gut beherrschbar, bei fester On-Premise-Hardware oder in OT-Umgebungen kann der doppelte Ressourcenbedarf zur Hürde werden.
Eine wichtige Herausforderung ist der Umgang mit Zustand, insbesondere Datenbanken. Wenn beide Umgebungen auf dieselbe Datenbank zugreifen, müssen Schema-Änderungen rückwärtskompatibel sein, damit ein Rollback nicht an inkompatiblen Datenstrukturen scheitert. Hier unterscheidet sich Blue-Green deutlich vom Canary Release, der schrittweise statt vollständig umschaltet.
Unterbrechungsfreies Release eines Kundenportals
Ein Industrieunternehmen deployt sein B2B-Portal über Blue-Green. Die neue Version läuft vollständig auf der Green-Umgebung, wird intern abgenommen, und der Go-Live ist ein Traffic-Switch in Sekunden — ohne Wartungsfenster für die Kunden.
Schneller Rollback nach Produktionsfehler
Nach dem Umschalten meldet das Monitoring eines Fertigungsbetriebs erhöhte Fehlerraten in der neuen Version. Das Team schwenkt den Load Balancer in unter einer Minute zurück auf die alte Umgebung, die unverändert lief.
- Was unterscheidet Blue-Green Deployment vom Canary Release?
- Blue-Green schaltet den gesamten Traffic auf einmal zwischen zwei kompletten Umgebungen um. Canary leitet zunächst nur einen kleinen Prozentsatz auf die neue Version und steigert ihn schrittweise. Blue-Green ist binär, Canary graduell.
- Wie gehe ich bei Blue-Green mit Datenbank-Migrationen um?
- Schema-Änderungen sollten rückwärtskompatibel gestaltet werden, sodass alte und neue Anwendungsversion gegen dasselbe Schema laufen können. So bleibt ein schneller Rollback möglich, ohne dass Datenstrukturen den Wechsel blockieren.
- Lohnt sich Blue-Green trotz des doppelten Ressourcenbedarfs?
- Wenn niedrige Ausfallzeit und schneller, sicherer Rollback geschäftskritisch sind, ja. In elastischen Cloud-Umgebungen ist der doppelte Bedarf nur temporär. Bei knapper, fester Hardware kann ein Rolling Update oder Canary die ressourcenschonendere Wahl sein.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance