Blue/Green Deployment: Wenn Sie sofort umschalten und sofort zurückrollen müssen

Stellen Sie sich folgende Szene vor: Ihr Team hat gerade ein großes Redesign der Haupt-Landingpage abgeschlossen. Oder Sie haben eine Kernbibliothek ausgetauscht, die jeden Teil der Anwendung betrifft. Solche Änderungen lassen sich im Staging nur schwer perfekt testen, weil Staging-Daten und Nutzerverhalten nie genau der Produktion entsprechen. Sie könnten ein Rolling Update versuchen, aber wenn etwas schiefgeht, würde die Hälfte Ihrer Nutzer die kaputte Version sehen, während die andere Hälfte noch die alte sieht. Und ein Rollback? Das bedeutet, auf jedes einzelne Instanz zu warten, bis es nacheinander zurückgesetzt wird. Nicht gerade sofort.

Hier kommt Blue/Green Deployment ins Spiel. Es löst ein spezifisches Problem: Wie schalten Sie alle Nutzer gleichzeitig auf eine neue Version um, und wie schalten Sie sie genauso schnell zurück, wenn etwas schiefgeht?

Zwei identische Umgebungen, eine aktiv zur Zeit

Die Idee ist einfach. Sie betreiben zwei identische Umgebungen. Nennen Sie eine blau und die andere grün. Beide laufen mit der gleichen Infrastruktur, der gleichen Konfiguration und der gleichen Kapazität. Der einzige Unterschied ist, welche gerade Nutzer bedient.

Lassen Sie uns durchgehen, wie das in der Praxis funktioniert.

Das folgende Diagramm zeigt die beiden Zustände und die Übergänge zwischen ihnen.

flowchart TD BlueActive["Blau Aktiv (v1)"] -->|Deploy v2 auf Grün| GreenReady["Grün Bereit (v2)"] GreenReady -->|Umschalten| GreenActive["Grün Aktiv (v2)"] GreenActive -->|Rollback| BlueActive BlueActive -.->|Bereit für Rollback| BlueStandby["Blau Bereitschaft (v1)"] GreenActive -.->|Bereit für Rollback| GreenStandby["Grün Bereitschaft (v2)"]

Angenommen, Ihre Nutzer greifen derzeit auf die blaue Umgebung zu, die Version 1 Ihrer Anwendung ausführt. Die grüne Umgebung läuft ebenfalls, erhält aber keinen Nutzerverkehr. Vielleicht nutzt Ihr Team sie für interne Tests, oder sie bleibt einfach ungenutzt. Wenn es Zeit für die Veröffentlichung von Version 2 ist, deployen Sie die neue Version in der grünen Umgebung. Jetzt hat Grün Version 2, während Blau weiterhin Nutzer mit Version 1 bedient.

An diesem Punkt können Sie Version 2 in einer Umgebung testen, die identisch mit der Produktion ist. Führen Sie Health Checks durch. Überprüfen Sie die Funktionalität. Bitten Sie ein paar interne Personen, die neue Version auszuprobieren. Alles geschieht, ohne die echten Nutzer zu beeinträchtigen.

Sobald Sie überzeugt sind, führen Sie das Umschalten durch. Umschalten bedeutet, den Nutzerverkehr von Blau auf Grün umzuleiten. Sie könnten Ihre Load-Balancer-Konfiguration aktualisieren, DNS-Einträge ändern oder das Routing in einem Service Mesh anpassen. In Sekunden erreichen alle Nutzer Version 2. Es gibt keine Ausfallzeit, weil Grün bereits mit warmen Servern, offenen Datenbankverbindungen und vollständig initialisierter Anwendung lief.

Das Killer-Feature: Sofortiges Rollback

Der größte Vorteil von Blue/Green Deployment ist, wie schnell Sie ein Rollback durchführen können. Wenn Version 2 nach der Nutzung durch die Nutzer ein Problem aufweist, schalten Sie den Verkehr einfach zurück auf Blau. Die Nutzer sind sofort wieder auf Version 1. Kein Warten auf ein erneutes Deployment. Kein erneutes Ausführen einer Pipeline. Rollback ist nur eine Routing-Änderung.

Vergleichen Sie das mit einem Rolling Update. Wenn Sie ein Rolling Update zurückrollen müssen, müssen Sie den Prozess Instanz für Instanz umkehren. Jede benötigt Zeit zum Neustarten und Wiederverbinden. Während dieses Fensters könnten einige Nutzer immer noch die kaputte Version sehen. Bei Blue/Green läuft die alte Version noch und ist bereit zu bedienen. Sie legen den Schalter um, und es ist erledigt.

Der Kosten-Nutzen-Abwägung

Blue/Green Deployment hat einen klaren Nachteil: Kosten. Sie müssen zwei vollständige Umgebungen gleichzeitig betreiben. Wenn Ihre Produktionslast 10 Server erfordert, bedeutet Blue/Green, dass Sie während der Übergangszeit 20 Server betreiben. Sie zahlen für die doppelte Kapazität.

Einige Teams reduzieren diese Kosten, indem sie die untätige Umgebung herunterskalieren. Zum Beispiel könnte Grün mit nur 2 Servern laufen, während es keinen Verkehr bedient, und dann kurz vor dem Umschalten auf 10 Server hochskalieren. Dieser Ansatz erfordert Automatisierung für die Skalierung und ist immer noch teurer als ein Rolling Update. Aber für risikoreiche Änderungen könnten die Kosten die Sicherheit wert sein.

Wann Blue/Green verwenden

Diese Strategie passt zu Änderungen, bei denen das Risiko hoch ist und das Rollback sofort erfolgen muss. Denken Sie an:

  • Große UI-Redesigns, die die Interaktion der Nutzer mit Ihrem Produkt beeinflussen
  • Austausch von Kernabhängigkeiten oder Bibliotheken
  • Datenbankschema-Änderungen, die schwer rückgängig zu machen sind
  • Compliance- oder regulatorische Updates, bei denen ein sauberes Umschalten erforderlich ist

Aber nicht jede Änderung benötigt zwei vollständige Umgebungen. Wenn Sie einen kleinen Bugfix deployen, der gründlich getestet wurde, ist ein Rolling Update effizienter und günstiger. Die Frage ist: Wie viel Risiko sind Sie bereit zu akzeptieren, und wie schnell müssen Sie sich erholen, wenn etwas schiefgeht?

Eine praktische Checkliste

Bevor Sie Blue/Green Deployment implementieren, stellen Sie sicher, dass diese Punkte erfüllt sind:

  • Identische Umgebungen. Beide Umgebungen müssen die gleiche Infrastruktur, Konfiguration und Kapazität ausführen. Unterschiede zwischen ihnen machen den Zweck zunichte.
  • Zustandslose oder sitzungsbewusste Anwendungen. Wenn Ihre App Sitzungsdaten lokal speichert, verlieren Nutzer ihre Sitzungen beim Umschalten. Verwenden Sie externe Sitzungsspeicher wie Redis oder entwerfen Sie für Zustandslosigkeit.
  • Automatisiertes Umschalten. Manuelles Umschalten ist fehleranfällig. Automatisieren Sie den Verkehrswechsel, sodass er Sekunden dauert, nicht Minuten des Herumklickens.
  • Health Checks in der neuen Umgebung. Deployen und schalten Sie nicht einfach um. Überprüfen Sie, ob die neue Version Health Checks besteht, bevor Sie Verkehr dorthin leiten.
  • Überwachung während und nach dem Umschalten. Beobachten Sie Fehlerraten, Latenz und Geschäftsmetriken sofort nach dem Wechsel. Wenn etwas falsch aussieht, rollen Sie schnell zurück.

Die konkrete Erkenntnis

Blue/Green Deployment gibt Ihnen die Fähigkeit, alle Nutzer sofort auf eine neue Version umzuschalten und sie genauso schnell zurückzuschalten. Die Kosten sind der Betrieb von zwei Umgebungen, aber der Lohn ist ein Sicherheitsnetz für risikoreiche Änderungen. Wenn Ihr Team große Releases durchführt und Sie sich um die Wiederherstellungszeit sorgen, ist Blue/Green die Investition wert. Für kleinere Änderungen bleiben Sie bei Rolling Updates. Die richtige Strategie hängt vom Risiko ab, nicht davon, welche beeindruckender klingt.