Blau-grüner Einsatz

Was ist Blue-Green Deployment?

Blue-Green-Deployment ist eine Softwareentwicklungstechnik, bei der zwei Produktionsumgebungen (eine "blaue Umgebung" und eine "grüne Umgebung") verwendet werden, um den Softwareeinführungsprozess sicherer zu machen. Es handelt sich dabei um eine relativ komplexe Bereitstellungsstrategie, die jedoch die Ausfallzeiten bei der Aktualisierung deiner Anwendung in der Produktion effektiv minimiert.

Die beiden Produktionsumgebungen werden so identisch wie möglich gehalten. Der neu bereitgestellte Code wird in die derzeit inaktive Umgebung gepusht. Sobald die neuen Änderungen in der Produktion getestet wurden, schaltet ein Router auf die Umgebung um, in der die neuen Änderungen live sind, und sorgt so für einen reibungslosen Übergang.

Mit einer blau-grünen Bereitstellungsstrategie kannst du deine Anwendung in der Produktion mit minimaler Ausfallzeit aktualisieren. Dabei werden zwei identische Kopien deiner Anwendung bereitgestellt, eine "blaue" und eine "grüne". Die blaue Kopie ist die aktuelle Produktionsversion deiner Anwendung und die grüne ist die neue Version, die du einsetzen willst. Du teilst einige deiner Server für das Hosting der neuen Version der Anwendung ein und die übrigen Server hosten die vorherige Version.

Sobald die grüne Version implementiert und getestet ist, kannst du den Datenverkehr schrittweise von der blauen auf die grüne Version umleiten. Beginne schrittweise, indem du z.B. 20 % des Datenverkehrs auf die grüne Kopie umleitest und den Prozentsatz dann im Laufe der Zeit erhöhst. So kannst du eventuelle Probleme erkennen, bevor du umstellst.

Wenn du ein Problem feststellst, kannst du schnell zur blauen Kopie zurückkehren, indem du den gesamten Datenverkehr dorthin zurückleitest. Aus diesem Grund wird die Blue-Green-Bereitstellung auch als "Zero-Downtime"-Bereitstellungsstrategie bezeichnet.

Mit Blue-Green Deployment bekommst du:

• Keine Ausfallzeiten: Die Umstellung von blau auf grün erfolgt sofort. Für die Kunden gibt es während der Bereitstellungsphase keine Ausfallzeiten, da beide Umgebungen aktiv und identisch sind.
• Rollback Funktionen: Bei Problemen kannst du einfach zur blauen Umgebung zurückwechseln.
• Risikominimierung: Indem du eine vollständig getestete Umgebung (grün) hast, bevor du den Live-Verkehr dorthin leitest, wird das Risiko, dass fehlerhafte oder fehlerhafte Updates direkt auf das Live-System (blau) übertragen werden, erheblich reduziert.

Mit der Blue-Green-Bereitstellung werden die Ausfallzeiten und das Risiko, das mit der Bereitstellung neuer Änderungen auf einem Live-System verbunden ist, erheblich reduziert.

Wie wird Blue-Green Deployment eingesetzt?

Blue-Green Deployment ist eine komplexe Deployment-Strategie. Du solltest einen gut definierten Plan haben, da diese Strategie teurer sein kann als andere Verteilungsstrategien, z. B. A/B-Testing.

• Verwende eine skalierbare Infrastruktur. Das hilft dir, die Gesamtkosten zu senken.
• Praktiziere Chaos Engineering in einer grünen Umgebung. So kannst du die Zuverlässigkeit deiner Anwendung testen, ohne deine Endnutzer/innen zu beeinträchtigen.
• Verwalte den Datenbankstatus sorgfältig. Das ist eine der größten Herausforderungen bei der blau-grünen Bereitstellung.
• Ändere Load Balancer, nicht DNS. So hast du mehr Kontrolle über das Routing des Datenverkehrs.

Phasen eines blau-grünen Bereitstellungsmodells

Hier sind die 9 Stufen eines blau-grünen Bereitstellungsmodells:

1. Umgebungen einrichten: Erstelle identische blaue und grüne Umgebungen.

2. Updates in die grüne Umgebung einspielen: Änderungen in der grünen Umgebung implementieren.

3. Testen und Validieren : Führe umfassende Tests in der grünen Umgebung durch.

4. Verifizierung und Qualitätskontrolle : Überprüfe die Aktualisierungen auf Leistung und Kompatibilität.

5. Umstellung : Leite den Live-Verkehr zügig von der blauen auf die grüne Umgebung um.

6. Überwachung (Post Deployment): Überprüfe Grün kontinuierlich auf Probleme oder Anomalien.

7. Rollback (bei Bedarf) : Kehr schnell zur stabilen blauen Umgebung zurück, wenn Probleme auftreten.

8. Promote green to blue: Sobald die grüne Umgebung stabil ist, mache sie zur neuen Live-Produktionsumgebung (blau).

9. Aufräumenund für den nächsten Zyklus vorbereiten: Setze die grüne Umgebung zurück und bereite sie für zukünftige Updates vor.

Dieser gestraffte Prozess gewährleistet einen nahtlosen Übergang zwischen den Umgebungen und minimiert Ausfallzeiten und Risiken bei Aktualisierungen oder Änderungen am Live-System.

Blue-green deployment Use-Cases

Rollbacks

Einer der Hauptvorteile von Blue-Green Deployments ist Disaster Recovery. Da es zwei identische Produktionsumgebungen gibt, kann ein Router, wenn neue Änderungen in einer der beiden Umgebungen (z. B. der blauen Version) vorgenommen werden und Probleme auftreten, einfach auf die andere Umgebung (grüne Version) umschalten, in der die alte Version des Codes vorhanden ist, ohne dass es zu Ausfällen kommt.

Kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD-Pipeline)

Eines der Ziele der kontinuierlichen Integration (eine DevOps-Technik) ist es, Software so schnell wie möglich in Betrieb zu nehmen und den Entwicklungsprozess durch automatisierte Tests und häufige Code-Integration zu beschleunigen. Blue-Green Deployment ist eine Deployment-Strategie, die bei diesem Ziel helfen kann, indem sie mehr Code-Pushs in die Produktion ermöglicht und gleichzeitig das Risiko neuer Releases senkt.

Testen in der Produktion

Oft gibt es kleine Kompatibilitätsunterschiede zwischen der Staging-Umgebung und der Produktionsumgebung, egal wie sehr man sich bemüht, sie identisch zu machen. Für DevOps-Teams kann dies zu Problemen und Fehlern führen, die erst entdeckt werden können, wenn der Code in die Produktion überführt wurde. Die Blue-Green-Bereitstellung ermöglicht Tests in der Produktion, indem der neue Code in die tatsächliche Produktionsumgebung übertragen wird, um zu sehen, wie er sich verhält, bevor er reibungslos in den Produktionsverkehr und zu den tatsächlichen Nutzern überführt wird.

Kanarienvogel-Einsatz

Bei einem Canary-Release werden neue Änderungen nicht für alle, sondern nur für einen kleinen Teil der Nutzer/innen freigegeben. Ähnlich wie ein Kanarienvogel in einer Kohlenmine kann dieser kleine, kontrollierte Test genutzt werden, um festzustellen, ob die neue Version deines Codes fatale Fehler enthält. Die Blue-Green-Bereitstellung kann für solche Canary-Tests verwendet werden, indem der Router einfach einen Prozentsatz deines Datenverkehrs auf eine neue Version des Codes lenkt, um zu sehen, wie sie sich im Live-Verkehr verhält, bevor du die Änderung auf 100% deiner Nutzer/innen ausweitest.

A/B-Testing

Ein weiterer möglicher Use-Case für blau-grüne Einsätze sind A/B-Tests. In diesem Use-Case lädst du die neue Version deines Codes in die blaue Umgebung und lenkst 50 % deines Nutzerverkehrs auf die blaue Version im Vergleich zu deiner ursprünglichen grünen Version. Dann kannst du beobachten, wie die beiden Umgebungen in Bezug auf deine wichtigsten Kennzahlen abschneiden, und mithilfe statistischer Analysen die genauen Auswirkungen deiner neuen Anwendung ermitteln.

Lastausgleich

Ein weiterer möglicher Use-Case für Blue-Green Deployment ist der Lastausgleich. Wenn der Blue/Green-Einsatz so eingerichtet ist, dass die beiden Produktionsumgebungen auf getrennten Servern (und nicht auf einer virtuellen Maschine) laufen, kann ein Router den Datenverkehr zwischen der blauen und der grünen Version der Produktionsumgebung problemlos ausgleichen, da sie funktional identisch sind.

Was sind die Vorteile des blau-grünen Einsatzes?

Hier sind einige der wichtigsten Vorteile dieser Bereitstellungsmethode:

Null Ausfallzeit: Du kannst deine Anwendung in der Produktion ohne Ausfallzeiten aktualisieren, da zwei identische Kopien laufen. Du kannst den Datenverkehr von einer auf die andere umschalten.

Rollback: Wenn du mit der neuen Version deiner Anwendung Probleme hast, kannst du ganz einfach zur vorherigen Version zurückkehren.

Geringeres Risiko: Du kannst die neue Version deiner Anwendung in der grünen Umgebung testen, bevor du sie in der Produktion einsetzt.

Kontrollierte Bereitstellung: Du hast die Kontrolle über den Bereitstellungsprozess. Entscheide, wie viel Datenverkehr in die grüne Umgebung geleitet werden soll, und beobachte, ob es Probleme gibt, bevor du den Wechsel vornimmst.

Skalierbarkeit: Die Blue-Green-Implementierung kann leicht skaliert werden, um mehr Datenverkehr zu bewältigen, indem weitere Server zur grünen Umgebung hinzugefügt werden.

Beispiel für Blue-green Deployment

Angenommen, dein Entwicklungsteam arbeitet an einer Web-App und möchte eine neue Funktion freigeben, aber Ausfallzeiten vermeiden und einen reibungslosen Übergang zum neuen Code gewährleisten. Zusätzlich zu deiner Staging-Umgebung würdest du zwei identische Produktionsumgebungen einrichten (eine "blaue Version" und eine "grüne Version"), wobei ein Router den Datenverkehr zur grünen Version leitet.

Dann kannst du die neuen Änderungen in die blaue Version der Produktionsumgebung einspielen und sehen, wie sie sich in der realen Produktionsumgebung verhalten. Es könnte sich herausstellen, dass es Fehler gibt, die nur in der Produktionsumgebung auftreten. In diesem Fall kannst du ganz einfach zur Entwicklungsversion zurückkehren, ohne dass dies Auswirkungen auf deine Nutzer hat.

Wenn du mit der Leistung der neuen Version der Anwendung zufrieden bist, kannst du einen Teil deines Nutzerverkehrs in die blaue Umgebung leiten, um einen Kanarienvogeltest mit echten Nutzern durchzuführen. Wenn dabei keine Probleme festgestellt werden, kannst du 100 % deines Datenverkehrs in die neue Umgebung leiten, was zu einer reibungslosen Veröffentlichung der neuen Funktionen führt.

Wenn nach der Umstellung Probleme entdeckt werden, kannst du den Datenverkehr wieder zurück in die grüne Umgebung leiten, in der sich die vorherige Version deines Codes befindet, um ein einfaches Rollback durchzuführen.

Wenn du sicher bist, dass es keine Probleme mit dem neuen Code gibt, kannst du die blaue Umgebung in die grüne Umgebung klonen, so dass du wieder zwei identische Produktionsumgebungen hast. Du kannst dann den Entwicklungszyklus fortsetzen oder den zweiten Server bei Bedarf als Load Balancer einsetzen, wenn du eine Lastspitze siehst.

Was sind die Nachteile der blau-grünen Bereitstellung?

Hier sind einige der Hauptnachteile:

Mehr Ressourcen: Du musst zwei identische Umgebungen vorhalten, was teurer sein kann als andere Bereitstellungsstrategien.

Mehr Koordination: Du musst sowohl die Bereitstellung der neuen Version der Anwendung in der grünen Umgebung als auch die Umstellung von der blauen auf die grüne Umgebung koordinieren.

Langsamere Umstellung: Die Umstellung auf verschiedene Untergruppen kann langsamer sein als bei anderen Bereitstellungsstrategien, z. B. A/B-Testing. Du musst den gesamten Datenverkehr aus der blauen Umgebung ableiten, bevor du auf die grüne Umgebung umschaltest.

Nicht für alle Anwendungen geeignet: Die blau-grüne Bereitstellung ist nicht für alle Anwendungen geeignet. Zum Beispiel für Anwendungen, die viele Zustände verwenden, wie Datenbanken.

Granularität auf Feature-Ebene: Ein grüner Bereitstellungsprozess ermöglicht keine Granularität auf Feature-Ebene. Wenn du also ein Problem mit einer bestimmten Funktion hast, musst du die gesamte Version zurücksetzen, nicht nur die betroffene Funktion. Wenn du eine große oder komplexe Anwendung bereitstellst, kann es schwierig sein, diese Methode anzuwenden.

Feature Flags vs. Blue-green Deployment

Ein alternativer Entwicklungsansatz zum Blue-Green Deployment ist die Verwendung von Feature Flags oder Feature Toggles als Rolling Deployment. Bei Feature Flags werden neue Funktionen und Code in bedingten Code verpackt, der aus der Ferne ein- oder ausgeschaltet werden kann. Auf diese Weise können Entwickler/innen neue Funktionen in die Produktion einführen und haben eine einfache Möglichkeit zum Rollback, ohne zwei Produktionsumgebungen pflegen zu müssen.

Neben der einfachen Ein- und Ausschaltfunktion können Feature Flags auch für Targeting-Rollouts verwendet werden, bei denen eine Funktion nur für ein bestimmtes Segment des Nutzerverkehrs aktiviert wird. Dies ermöglicht Use-Cases wie Canary Deployments und A/B-Testing, ohne dass du zwei separate Produktionsumgebungen unterhalten musst.

Wenn du auf der Suche nach einem einfachen Workflow bist, um mit Feature Flags zu beginnen, ist Optimizely free feature flagging eine kostenlose Lösung von Optimizely, mit der du schnell und sicher Feature Toggles und A/B-Testing in deiner App implementieren kannst. Optimizely Rollouts ist für die beliebtesten Sprachen und Bibliotheken verfügbar, darunter JavaScript, Ruby, Node, React und Python.

Starten Sie noch heute mit dem kostenlosen Feature Flags!