Was ist Blue Green Deployment?

Eine Umgebung ist im Live-Betrieb und dient den Benutzern; sie ist mit „blau“ gekennzeichnet. Eine andere Umgebung, die „grüne“ Umgebung, wird für die Bereitstellung und das Testen einer neuen Version verwendet. Wenn die neue Version genehmigt wird, wird der Verkehr sofort von der blauen Umgebung zur grünen umgeleitet.

Die Strategie wurde von Jez Humble und David Farley in ihrem bahnbrechenden Buch von 2010 Continuous Delivery: Zuverlässige Software-Veröffentlichungen durch Build, Test und Bereitstellungsautomatisierung popularisiert und benannt.

Blue-green ist eine Technik zur kontinuierlichen Bereitstellung, die es ermöglicht, Ausfallzeit zu vermeiden und sofort ein Rollback auf eine alte Version durchzuführen. Es ermöglicht einfaches A/B-Testing und schafft eine sichere Entwicklungsumgebung, ohne dass Endbenutzer auf eine noch nicht fertige Version stoßen.

Die Formulierung „blue-green“ ist zwar am gebräuchlichsten, es gibt aber auch Varianten. Netflix verwendet „red/black“, aber das Konzept bleibt dasselbe. Manchmal möchten Entwickler mehr als zwei Umgebungen haben. Das Farbbenennungsschema ist effektiv, um zwischen zwei Umgebungen zu unterscheiden. Unternehmen können jedoch auch Namenskonventionen wie Versionsnummern, Build-IDs oder angepasste Titel verwenden, insbesondere wenn mehr als zwei Umgebungen beteiligt sind.

Obwohl das Konzept einfach ist, gibt es mehrere Schritte und Variablen innerhalb dieser Schritte, um eine stabile und sichere Blue-Green-Implementierung zu schaffen, die die Vorteile der Strategie nutzt.

Die Erstellung identischer Umgebungen für die blau-grüne Bereitstellung kann entweder manuell oder durch automatisierte Werkzeuge erfolgen. Infrastructure as Code, oder IaC, ist ein automatisierter Ansatz zur Bereitstellung. IaC verwendet maschinenlesbare Konfigurationsdateien, die einer Anleitung oder einem Rezept ähneln und die die automatische Bereitstellung und Konfiguration der IT-Infrastruktur nach vordefinierten Spezifikationen ermöglichen.

IaC ermöglicht es Entwicklern, automatisch eine Kopie der bereits betriebsbereiten blauen Umgebung zu erstellen, die dann als grüne Umgebung verwendet werden kann. Entwickler können diese Vorlagen dann nach Bedarf bearbeiten, da sie wissen, dass sie von einem vertrauenswürdigen Ausgangspunkt ausgehen. Der Einsatz von IaC trägt dazu bei, eine wiederholbare und präzise Replikation zu gewährleisten.

Eine weitere Methode ist die Containerisierung, bei der Anwendungscode, Abhängigkeiten und APIs zusammen in einem „Container-Image“ verpackt werden. Die Verwendung von Containern garantiert, dass die gesamte Umgebung identisch ist. Kubernetes, eine Open-Source-Container-Orchestrierungsplattform, wird häufig für die Containerisierung in der blau-grünen Bereitstellung verwendet.

Nachdem die Umgebungen erstellt wurden, wird die Anwendung in der blauen (live) Umgebung bereitstellen.

Ein Load Balancer ist ein Mechanismus, der häufig vor Anwendungen als Werkzeug von Cloud-Providern oder Kubernetes-Umgebungen eingesetzt wird und den Produktionsdatenverkehr nach Bedarf lenkt. In diesem Szenario leitet der Load Balancer den Datenverkehr an die aktive, blaue Umgebung weiter.

Anschließend wird der neue Code mit den Anwendungsupdates in der grünen Produktionsumgebung bereitgestellt. Da der Load Balancer den Datenverkehr an die blaue Produktionsumgebung weiterleitet, ist die grüne Umgebung ein sicherer Bereich zum Experimentieren, Testen und Konfigurieren. 

Wenn der Bereitstellungsprozess in die grüne Umgebung abgeschlossen ist, führen Sie alle notwendigen Validierungsschritte durch. Diese Schritte können Sicherheitsscans, Leistungschecks, Bug-Scans und mehr umfassen.

Wenn die grüne Umgebung von allen notwendigen Stakeholdern validiert und genehmigt ist, aktualisieren Sie den Load Balancer, um den Datenverkehr von der blauen vorherigen Version zur grünen neuen Version zu leiten.

Diese Umstellung erfolgt sofort; Benutzer werden zu keinem Zeitpunkt einen Fehler oder etwas anderes als die blauen oder grünen Umgebungen sehen.

DNS-Aktualisierungen können verwendet werden, um Benutzer in die gewünschte Umgebung zu leiten, allerdings kann es zu erheblichen Verzögerungen kommen, da die Caches die IP-Adresse aktualisieren. Aufgrund dieser Bedenken werden Load Balancer bevorzugt, da die Updates sofort wirksam werden.

Obwohl der Validierungsschritt die meisten potenziellen Fehler oder Leistungsprobleme aufgedeckt haben sollte, ist es dennoch wichtig, die neu eingerichtete Live-Umgebung zu überwachen. Analysesoftware und -dienste können hier helfen. Der Vergleich von Aktivitäten kann Aufschluss darüber geben, ob etwas Ungewöhnliches vor sich geht.

Wenn doch etwas schiefgeht, kann der Nutzerverkehr in die blaue Umgebung umgeleitet werden, während die Entwickler das Problem beheben.

Die Stilllegung einer stillgelegten blauen Umgebung ist optional; Einige Unternehmen möchten die blaue Umgebung möglicherweise auf unbestimmte Zeit beibehalten, für den Fall, dass die grüne Umgebung irgendwann zurückgesetzt werden muss. Aber es gibt auch potenzielle Kostengründe dafür, Blue Environment irgendwann in seinem Lebenszyklus außer Betrieb zu nehmen. Alternativ kann die blaue Umgebung zur nächsten experimentellen oder grünen Umgebung werden.

Die Continuous Integration/Continuous Delivery Pipeline ist "ein automatisierter DevOps-Workflow, der den Softwarebereitstellungsprozess rationalisiert." Diese Pipeline ermöglicht die kontinuierliche Bereitstellung von Codeänderungen in Anwendungen.

Es handelt sich um eine Praxis, die eng mit Blue-Green-Deployment verknüpft ist: CI/CD ermöglicht Blue-Green-Deployment, und Blue-Green-Deployments werden häufig in CI/CD-Pipelines integriert, um Software-Updates ohne Ausfallzeiten und mit reduziertem Risiko zu veröffentlichen.

CI-Pipelines testen und integrieren automatisch neuen Code, bevor er in das zentrale Repository integriert wird, wodurch das Risiko verringert wird, dass fehlerhafter Code die Bereitstellung erreicht. CD-Pipelines nutzen eine Blue-Green-Bereitstellung-Strategie, um schnelle Releases zu optimieren, ohne die Benutzer zu beeinträchtigen. Blau-grüne Bereitstellung bietet nahezu kontinuierliche Verfügbarkeit und sicheren Rollback, was eine große Rolle bei der Erreichung des übergeordneten CI/CD-Ziels häufiger und zuverlässiger Codeveröffentlichungen spielt.

Angelehnt an die Redewendung vom Kanarienvogel im Kohlebergwerk, stellen Canary-Deployments eine weitere Möglichkeit dar, das Risiko bei der Einführung neuer Softwareversionen zu reduzieren.

Während bei Blue/Green-Deployments zwei separate Umgebungen geschaffen werden, von denen jede typischerweise entweder den gesamten oder gar keinen Datenverkehr empfängt, verfolgt Canary einen anderen Ansatz. Canary-Releases haben nur eine Umgebung, in der mehrere Versionen gehostet werden.

Bei einer Canary-Bereitstellung werden neue Versionen zunächst für einen kleinen Prozentsatz der Benutzer freigegeben. Anschließend können die Entwickler feststellen, ob mehr Fehler auftreten, die Leistung nachlässt oder andere Probleme entstehen. Dieser kleine Prozentsatz an Nutzern fungiert als „Kanarienvogel im Kohlebergwerk“. Wenn keine Probleme auftreten, wird der Datenverkehr zur neuen Version stetig erhöht, wobei gleichzeitig ständig auf Fehler geprüft wird.

Der größte Vorteil einer Canary-Bereitstellung gegenüber einer Blue/Green-Bereitstellung liegt in den Infrastrukturkosten, da für eine Canary-Bereitstellung nur eine Umgebung benötigt wird, während für eine Blue/Green-Bereitstellung zwei Umgebungen benötigt werden. Aber Canary-Bereitstellungen können auch komplexer und riskanter sein, wenn ein Rollback erforderlich ist, verglichen mit der einfachen Load-Balancing-Umleitung von Blue/Green.

Die Canary-Deployment-Methode kann nützlich sein, wenn potenzielle Fehler nicht so wichtig sind wie die möglichst schnelle Bereitstellung einer neuen Version für die Benutzer, oder wenn Entwickler die Auswirkungen anhand von echtem Benutzerfeedback überwachen möchten.

Allerdings gibt es auch einen hybriden Ansatz. Load Balancer können einen Teil des Benutzerverkehrs, beispielsweise 1 %, in die grüne Umgebung leiten, während 99 % in die blaue Umgebung geleitet werden. Dadurch werden beide Strategien effektiv miteinander kombiniert und es bietet umfassende Einblicke in den Einsatz mit der Möglichkeit, schnell und einfach Rollbacks durchzuführen.

Die blau-grüne Einführung bietet viele Vorteile, egal ob sie als Alles-oder-Nichts-Strategie oder als Testlauf eingesetzt wird.

Da die Lastausgleichsfunktion den Datenverkehr sofort an die gewünschte Umgebung weiterleitet, kommt es für Endbenutzer nie zu Ausfallzeit. Dies ist ein großer Vorteil für Instanzen mit hohem Datenverkehr, bei denen Ausfallzeiten zu erheblichen Geschäftsproblemen führen können.

Durch die Verwendung zweier getrennter Umgebungen, von denen eine als sicher und betriebsbereit bekannt ist, können Entwickler Änderungen sofort rückgängig machen, falls Probleme auftreten. Wenn die grüne Umgebung Probleme darstellt, kann der Verkehr einfach in die blaue Umgebung umgeleitet werden.

Zwei separate Umgebungen vereinfachen die Analyse von Metriken, Analysen und A/B-Tests für die verschiedenen Versionen. Analyse- und Überwachungsdaten können entweder mit der blauen oder der grünen Umgebung verknüpft werden, was einen einfachen Vergleich und Zustand ermöglicht. Dies steht im Gegensatz zur Canary-Bereitstellung, die schwieriger zu unterscheiden ist, da beide Versionen gleichzeitig aktiv sind.

Eine grüne, experimentelle Umgebung ermöglicht das gründliche Testen neuer Versionen außerhalb der Sichtweite des Endbenutzers. Neue Versionen werden mit einem hohen Maß an Zuversicht eingeführt, dass sie wie vorgesehen funktionieren werden. In Fällen, in denen dies nicht der Fall ist, kann der Datenverkehr sofort wieder in die stabile blaue Umgebung umgeleitet werden.

Obwohl die Blue Green Deployment viele Vorteile bietet, gibt es potenzielle Nachteile und nicht optimale Anwendungsfälle, die Entwicklungsteams berücksichtigen sollten.

Mit zwei vollständig bereitgestellten Umgebungen können die Kosten für Hosting und Infrastruktur steigen. Es ist nicht unbedingt so, dass diese Kosten genau doppelt so hoch sind wie die Kosten für eine einzelne Umgebung. In manchen Fällen hat die grüne Umgebung einen kleineren Fußabdruck, die blaue Umgebung wird schnell stillgelegt oder einige Ressourcen werden zwischen den beiden Umgebungen geteilt. Es ist jedoch wahrscheinlich, dass es zu Kostensteigerungen kommen wird.

Die Synchronisierung von Datenbanken zwischen alten und neuen Umgebungen ist zwar nicht nur bei Blue Green Deployment ein Problem, kann aber eine Herausforderung darstellen. In einem blau-grünen System mit häufigen oder komplexen Schemaänderungen kann es zum Beispiel schwierig sein, die Kompatibilität aufrechtzuerhalten.

Um zu verhindern, dass die Live-Umgebung unterbrochen wird, müssen Schemaänderungen abwärtskompatibel sein, was bedeutet, dass das neue System mit dem älteren System funktionieren kann. Wenn nicht, benötigen die Umgebungen möglicherweise separate Datenbanken, die in Echtzeit synchronisiert werden müssen. Diese bidirektionale Synchronisation birgt ihre eigenen Risiken, wie Inkonsistenzen und Leistungseinbußen.

Um dieses Problem zu lösen, beinhalten CI/CD-Tools wie GitHub Actions Datenbankbereitstellungsprozesse, die Schema-Aktualisierungen automatisch verwalten. Manchmal können zu komplexe Schemaänderungen den Wert einer blau-grünen Bereitstellung zunichte machen.

Bei zustandsbehafteten Anwendungen, d.h. solchen, die über Anfragen hinweg dauerhafte Daten beibehalten, können Blue Green Deployments Probleme verursachen. Zu den zustandsabhängigen Anwendungen gehören beispielsweise Warenkörbe, die ihren Inhalt über mehrere Besuche hinweg speichern, oder Nachrichtenprotokolle. Wenn Datenbanken in verschiedenen Umgebungen nicht gemeinsam genutzt werden und nicht kompatibel sind, können diese Daten verloren gehen.

Microservice-Anwendungen sind oft hochkomplexe Systeme, die aus vielen verschiedenen, einzeln einsetzbaren Komponenten bestehen. Da Microservices-Entwickler möglicherweise dutzende Male am Tag deployen möchten, gilt die inkrementelle Natur eines Canary-Deployments als sicherere Wahl.