Blue-Green-Deployment arbeitet mit zwei vollständigen Umgebungen, zwischen denen der Verkehr umgeschaltet wird. Eine davon trägt die Besucher, die andere nimmt den neuen Stand auf; nach der Prüfung wechseln die Rollen.
- Blue-Green-Deployment
Zwei vollständige Umgebungen, zwischen denen der Verkehr umgeschaltet wird.
Beispiel: „Beim Blue-Green-Deployment lief der neue Stand eine Stunde ungenutzt mit, bevor umgeschaltet wurde.“Die Farben sind reine Namen für die beiden Hälften. Umgeschaltet wird am Lastverteiler, im Reverse Proxy oder über einen Eintrag im DNS.
Abgrenzung zum Canary Release: Dieses leitet erst einen Bruchteil des Verkehrs um. Blue-Green schaltet alles auf einmal.
Wie ein Blue-Green-Deployment abläuft
In drei Zügen. Der neue Stand entsteht in der ungenutzten Hälfte, wird dort geprüft, und dann geht der Verkehr dorthin. Die alte Hälfte bleibt stehen und nimmt den nächsten Stand auf.
Die Abbildung zeigt den Aufbau samt der Datenbank, die beide Hälften teilen.
Der Rückweg ist deshalb ein zweites Umschalten und in Sekunden erledigt. Das ist der eigentliche Gewinn dieses Verfahrens, siehe Rollback.
Was ein Blue-Green-Deployment kostet
Die doppelte Infrastruktur. Zwei Umgebungen heißen zwei Server oder zwei Gruppen davon, und beide müssen die volle Last tragen können, auch wenn jeweils nur eine arbeitet.
Für eine Website mit einem Server ist das überdimensioniert. Dort erreicht das Umschalten per Verweis denselben Effekt zum Preis eines Verzeichnisses.
Wo die gemeinsame Datenbank klemmt
An den Daten, die weiterlaufen. Beide Hälften schreiben in dieselbe Datenbank, sonst gingen Bestellungen verloren, die während der Prüfung eintreffen; damit gelten für Strukturänderungen dieselben Regeln wie beim Ausrollen ohne Pause.
Wer die Datenbank mitverdoppelt, bekommt das umgekehrte Problem: Zwei Stände mit eigenen Daten lassen sich hinterher nicht zusammenführen. In der Praxis bleibt die Datenbank deshalb gemeinsam.