Blue-Green-Deployment-Strategie erklärt

Was ist ein Blue-Green-Deployment?

Blue-Green-Deployment ist eine Strategie für das Deployment von Anwendungen, bei der alte und neue Versionen parallel in zwei identischen Produktionsumgebungen laufen. Die ältere Version läuft beispielsweise in der blauen Umgebung, während die neue Version in der grünen Umgebung getestet wird. Sobald die Tests abgeschlossen sind, leitet ein Router oder Load Balancer Anfragen nach und nach an die grüne Umgebung weiter. Anschließend führen Entwickler Smoke-Tests durch, bevor der Traffic dauerhaft auf die grüne Umgebung umgestellt wird.

Bei diesem Ansatz werden Software-Updates mithilfe zweier ähnlicher Produktionsumgebungen (blau und grün) bereitgestellt.

• Blaue Umgebung: die aktuelle Produktionsversion der Anwendung

• Grüne Umgebung: die neue Version der Anwendung, die gerade getestet wird

Wie funktioniert ein Blue-Green-Deployment?

So funktioniert ein Blue-Green-Deployment:

1. Bereitstellen

Die neue Version der Anwendung wird in der grünen Umgebung bereitgestellt.

2. Testen

Die neue Version wird in der grünen Umgebung getestet, um sicherzustellen, dass sie alle Anforderungen an Performance und Sicherheit erfüllt.

3. Umschalten

Sobald die neue Version stabil ist, wird der Traffic von der blauen auf die grüne Umgebung umgeleitet.

4. Rollback

Werden Probleme festgestellt, kann der Traffic wieder auf die blaue Umgebung umgeleitet werden.

Wann ist ein Blue-Green-Deployment sinnvoll?

Blue-Green-Deployments eignen sich besonders für die folgenden Szenarien:

• Beide Umgebungen sind identisch und voneinander isoliert.

• Ein Router oder Load Balancer sollte zur Verfügung stehen.

• Das System sollte Continuous Updates unterstützen.

Die Bedeutung von Blue-Green-Deployments für DevOps-Prozesse

Eine wichtige Voraussetzung für eine effiziente DevOps-Pipeline ist, Code effizient für Endnutzer bereitzustellen. Durch kontinuierliches Deployment von Code-Änderungen lässt sich Software schnell veröffentlichen. Dabei können jedoch auch Fehler und Sicherheitslücken in die Produktion gelangen, die bei automatisierten Prüfungen übersehen wurden. Je nach Unternehmen sind entweder die Entwickler selbst oder ein Operations-Team für das Deployment von Code verantwortlich. Das Operations-Team stellt Build-Artefakte aus der CI/CD-Pipeline bereit.

In beiden Fällen benötigen Teams eine Möglichkeit, neue Anwendungsversionen schnell in einer Sandbox-Umgebung zu testen, sie für Nutzer bereitzustellen und bei Problemen in der Produktion wieder auf frühere Versionen zurückzusetzen. Der Wechsel zur neuen Version will gut geplant sein. Moderne Entwicklungsteams arbeiten häufig nach dem Prinzip „früh und häufig veröffentlichen“. Das ist mit komplexeren Releases, bei denen Ausfallzeiten außerhalb der Stoßzeiten eingeplant werden müssen, nicht vereinbar. Der Wechsel muss schnell erfolgen, um Ausfallzeiten zu minimieren.

Die Grundidee von Blue-Green-Deployments besteht darin, zwei identische Produktionsumgebungen einzurichten: eine für die vorherige Version und eine für Tests der neuen Version. Die beiden Umgebungen können auf unterschiedlichen physischen Geräten oder virtuellen Maschinen laufen oder als Betriebsumgebungen mit jeweils eigenen IP-Adressen eingerichtet sein.

Welche Vorteile bieten Blue-Green-Deployments?

• Sofortige Rollbacks. Da sich Staging- und Produktionsumgebungen nahezu identisch sind, lassen sich Fehler mit dem Blue-Green-Ansatz besser erkennen. Stellen Nutzer Probleme mit der neuen Anwendung in der grünen Umgebung fest, können Entwickler Anfragen sofort wieder an die ältere Version in der blauen Umgebung weiterleiten. So sind sofortige Rollbacks ohne Ausfallzeiten für Nutzer möglich.

• Nahtlose Upgrades. Blue-Green-Deployments automatisieren den Übergang vom Schreiben der Software bis zu ihrem Einsatz in der Produktion. Beim ersten Upgrade wird die grüne Umgebung für Tests genutzt und anschließend zur Produktionsumgebung für die neue Version. Die blaue Umgebung bleibt eine Zeit lang aktiv, falls ein Rollback nötig wird. Danach wird sie deaktiviert und beim nächsten Rollout für Staging-Tests verwendet.

• Keine Ausfallzeiten. Sobald Entwickler bereit sind, können sie neuen Code während des regulären Betriebs in die Produktion überführen. Sie müssen nicht auf ruhigere Zeiten wie späte Abende oder Wochenenden warten und keine Ausfallzeiten einplanen. Zusätzlich lässt sich die Staging-Umgebung für Tests der Notfallwiederherstellung oder als Backup nutzen.

Nachteile von Blue-Green-Deployments

In manchen Fällen birgt der Blue-Green-Ansatz Risiken, die das Deployment anfälliger für Fehler und Ausfälle machen können.

• Datenbanksynchronisierung: Die Verwaltung von Schemaänderungen kann schwierig sein. Bei einem Blue-Green-Deployment müssen Datenbank- und Datenänderungen zwischen der blauen und der grünen Umgebung synchronisiert werden. Eine fehlende Synchronisierung kann zu Inkonsistenzen führen.

• Erkennung von Fehlern bei QA/UAT: In großen Infrastrukturen kann es vorkommen, dass beim QA-Testen in Nicht-Produktionsumgebungen bestimmte Fehler übersehen werden. Dadurch bleiben potenzielle Probleme bis nach dem Deployment unentdeckt.

• Dashboard erforderlich: Da bei dieser Methode zwei Produktionsumgebungen mit unterschiedlichen Codeversionen gepflegt werden, ist es wichtig, den Status von Paketen und Code während des Deployments zu überwachen. Nur so lassen sich die Abläufe effektiv steuern und bei Bedarf Maßnahmen auslösen.

• Kostenauswirkungen: Für ein Blue-Green-Deployment sind zwei parallele Umgebungen erforderlich. Dadurch verdoppeln sich die Kosten für Betrieb und Wartung der Produktionsumgebung.

Blue-Green-Deployment und Application Load Balancing

Blue-Green-Deployments müssen sorgfältig umgesetzt werden, damit Nutzer beim Wechsel so wenig wie möglich beeinträchtigt werden. Eine Möglichkeit ist der Wechsel eines DNS-Eintrags. Dabei gibt es jedoch Einschränkungen, da die DNS-Propagation nicht sofort erfolgt.

Eine andere Möglichkeit besteht darin, mithilfe von Application Load Balancing den Traffic schrittweise in die grüne Umgebung zu leiten. So lässt sich der Nutzerverkehr präzise steuern. Load Balancer können bei Fehlern in der grünen Umgebung den Traffic umleiten und so konfiguriert werden, dass sie eine festgelegte Zeitspanne abwarten, bevor sie Nutzer abmelden oder deren Sitzungen in der blauen Umgebung beenden.

Insgesamt ermöglicht das ein nahtloseres Upgrade und weniger Unterbrechungen, als wenn Nutzer ihre Sitzungen vor der Umleitung des Traffics beenden müssen. Load Balancing kann den Prozess verlangsamen oder bei einer kleinen Zahl von Nutzern fehlschlagen. Die meisten Nutzer bemerken jedoch weder Ausfallzeiten noch Unterschiede.

Weitere Deployment-Strategien

• Blue-Green-Deployment: Blue-Green-Deployments sorgen für hohe Verfügbarkeit und ermöglichen einfache Rollbacks, falls kritische Fehler entdeckt werden. Dabei laufen zwei parallele Umgebungen: eine ist live, die andere steht bereit. So werden Ausfallzeiten der Anwendung minimiert.

• A/B-Deployment: Ähnlich wie beim Blue-Green-Deployment wird beim A/B-Deployment ein kleiner Teil des Traffics an einen separaten Server oder eine separate Umgebung geleitet. Diese Technik wird häufig eingesetzt, um die Nutzung von Funktionen zu bewerten und Nutzerfeedback zu einer neuen Version einzuholen.

• Canary-Deployment: Beim Canary-Deployment werden neue Funktionen schrittweise für eine Teilgruppe von Nutzern bereitgestellt, indem bestimmte Server verschiedenen Nutzergruppen zugewiesen werden. Dieser Ansatz eignet sich, um Funktionen schrittweise auszurollen und während des Releases Feedback zu sammeln. Rolling Deployment: Beim Rolling Deployment werden Server mit der alten Anwendungsversion nacheinander durch Server mit der neuen Version ersetzt. So lässt sich das Deployment bei Bedarf leichter pausieren.

Wie unterscheiden sich Blue-Green-Deployments von Canary-Deployments?

Im Gegensatz zu Blue-Green-Deployments benötigen Canary-Deployments keine separaten Umgebungen für Tests und Produktion. DevOps- oder Operations-Teams stellen die Änderung einer kleinen Nutzergruppe (dem „Canary“) bereit, testen das Release und entscheiden anschließend, ob es für alle Nutzer ausgerollt wird.

Da keine separaten Umgebungen genutzt werden, benötigen Canary-Deployments nur wenig zusätzliche Infrastruktur. Sie lassen sich mit einem freien Knoten oder Server einrichten – gerade genug, um einen kleinen Teil der Produktionsumgebung und eine geringe Menge an Traffic zu unterstützen.

Blue-Green-Deployments mit Infrastructure as Code (IaC)

Blue-Green-Deployments sind eine leistungsstarke Methode, um Software schnell bereitzustellen und gleichzeitig technische und geschäftliche Risiken zu minimieren. Dabei muss auch die Sicherheit sorgfältig berücksichtigt werden. Die komplexe Architektur von Anwendungen und ihren Umgebungen, der Einsatz von Webservern, Containern und Microservices sowie Tools zur Automatisierung von Builds, Tests und Deployments in der CI/CD-Pipeline bergen das Risiko von Fehlkonfigurationen, unsicheren Umgebungen und unerwarteten Problemen nach dem Wechsel.

Herkömmliche Application Security reicht nicht aus, um IaC-Infrastruktur zu schützen. Sie konzentriert sich auf Anwendungen nach dem Deployment. Dadurch können Fehler und Sicherheitslücken Endnutzer betreffen. Sicherheitsteams arbeiten unabhängig von Entwicklern. Wenn sie Probleme aufdecken, sind sie auf das Entwicklungsteam angewiesen, um Korrekturen vorzunehmen. Das führt zu Engpässen bei der Bereitstellung und zu unterschiedlichen Prioritäten von Entwicklern und Sicherheitsexperten. Außerdem ist Sicherheit eine externe Funktion des Entwicklungsprozesses und kein integrierter Bestandteil der CI/CD-Pipeline.

Blue-Green-Deployment und IaC-Tools

Zum Glück gibt es eine Lösung. Snyk Infrastructure as Code lässt sich nahtlos in die CI/CD-Pipeline integrieren und sichert Konfigurationen, bevor sie in die Produktion gelangen. Die Lösung stellt Entwickler in den Mittelpunkt und ermöglicht automatische Inline-Korrekturen im Code. Snyk IaC umfasst automatisierte Tests für Terraform-Dateien und -Pläne, AWS CloudFormation, Kubernetes-Konfigurationen und den Azure Resource Manager (ARM). Entwicklungsteams können IaC-Scans während der gesamten CI/CD-Pipeline durchführen, um Konfigurationsprobleme frühzeitig zu erkennen und zu beheben. Drift-Tests mit DriftCTL erkennen außerdem Änderungen an der Infrastruktur nach dem Deployment, die von Personen oder Tools außerhalb des regulären Ablaufs vorgenommen wurden. So übernehmen Entwickler Verantwortung für die Sicherheit von Build, Test und Deployment und können mit IaC-Tools die DevSecOps-Prinzipien bei Blue-Green-Deployments umsetzen.