Strategien für Blau-Grün-Bereitstellungen in Azure Spring Apps
Hinweis
Die Pläne Basic, Standard und Enterprise gelten ab Mitte März 2025 als veraltet und werden über einen Zeitraum von 3 Jahren eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie in der Ankündigung zur Einstellung von Azure Spring Apps.
Der Standardverbrauchs- und dedizierte Plan wird ab dem 30. September 2024 als veraltet gekennzeichnet und nach sechs Monaten vollständig eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie unter Migrieren vom Standardverbrauchs- und dedizierten Plan von Azure Spring Apps zu Azure Container Apps.
Dieser Artikel gilt für: ✔️ Basic/Standard ✔️ Enterprise
In diesem Artikel wird die Unterstützung für Blau-Grün-Bereitstellungen in Azure Spring Apps beschrieben.
Azure Spring Apps (Standard-Plan und höher) erlaubt zwei Bereitstellungen für jede App, von denen nur eine Produktionsdatenverkehr empfängt. Dieses Muster wird häufig als Blau-Grün-Bereitstellung bezeichnet. Die Unterstützung von Azure Spring Apps für Blau-Grün-Bereitstellungen, zusammen mit einer CD-Pipeline (Continuous Delivery) und rigorosen automatisierten Tests, ermöglicht das agile Bereitstellen von Anwendungen mit hohem Vertrauen.
Abwechseln der Bereitstellungen
Die einfachste Möglichkeit, eine Blau-Grün-Bereitstellung mit Azure Spring Apps zu implementieren, besteht darin, zwei feste Bereitstellungen zu erstellen und immer die Bereitstellung bereitzustellen, die keinen Produktionsdatenverkehr empfängt. Mit dem Azure Spring Apps-Task für Azure Pipelines können Sie die Bereitstellung auf diese Weise ausführen, indem Sie nur das UseStagingDeployment-Flag auf true festlegen.
So funktioniert der Ansatz für das Abwechseln der Bereitstellungen in der Praxis:
Angenommen, Ihre Anwendung verfügt über zwei Bereitstellungen: deployment1 und deployment2. Derzeit deployment1 ist als Produktionsbereitstellung festgelegt und führt Version v3 der Anwendung aus.
Dadurch wird deployment2 zur Stagingbereitstellung. Wenn also die CD-Pipeline (Continuous Delivery) bereit für die Ausführung ist, stellt sie die nächste Version der App (Version v4) in der Stagingbereitstellung deployment2 bereit.
Nachdem v4 in deployment2 gestartet wurde, können Sie automatisierte und manuelle Tests über einen privaten Testendpunkt ausführen, um sicherzustellen, dass v4 alle Erwartungen erfüllt.
Wenn Sie v4 vertrauen, können Sie deployment2 als Produktionsbereitstellung festlegen, sodass diese den gesamten Produktionsdatenverkehr empfängt. v3 wird weiterhin in deployment1 ausgeführt, falls Sie ein kritisches Problem feststellen, für das ein Rollback erforderlich ist.
Nun ist deployment1 die Stagingbereitstellung. Daher wird die nächste Ausführung der Bereitstellungspipeline in deployment1 bereitgestellt.
Sie können jetzt V5 für den privaten Testendpunkt von deployment1 testen.
Nachdem v5 alle Ihre Erwartungen erfüllt, legen Sie deployment1 erneut als Produktionsbereitstellung fest, damit v5 den gesamten Produktionsdatenverkehr empfängt.
Nachteile des Ansatzes abwechselnder Bereitstellungen
Der Ansatz für abwechselnde Bereitstellungen ist einfach und schnell, da die Erstellung neuer Bereitstellungen nicht erforderlich ist. Es gibt jedoch mehrere Nachteile, wie in den folgenden Abschnitten beschrieben.
Persistente Stagingbereitstellung
Die Stagingbereitstellung wird immer ausgeführt und verbraucht daher Ressourcen der Azure Spring Apps-Instanz. Dies verdoppelt effektiv die Ressourcenanforderungen jeder Anwendung unter Azure Spring Apps.
Die Genehmigungsracebedingung
Angenommen, in der Anwendung oben erfordert die Releasepipeline eine manuelle Genehmigung, bevor jede neue Version der Anwendung Produktionsdatenverkehr empfangen kann. Dadurch entsteht das Risiko, dass, während eine Version (v6) auf die manuelle Genehmigung für die Stagingbereitstellung wartet, die Bereitstellungspipeline erneut ausgeführt wird und sie mit einer neueren Version (v7) überschreibt. Wenn dann die Genehmigung für v6 erteilt wird, legt die Pipeline, die v6 bereitgestellt hat, die Stagingbereitstellung als Produktionsumgebung fest. Aber jetzt wird die nicht genehmigte v7, nicht die genehmigte v6, für diese Bereitstellung bereitgestellt und empfängt Datenverkehr.
Möglicherweise können Sie die Racebedingung verhindern, indem Sie sicherstellen, dass der Bereitstellungsfluss für eine Version erst gestartet werden kann, wenn der Bereitstellungsfluss für alle vorherigen Versionen abgeschlossen oder abgebrochen wurde. Eine weitere Möglichkeit, die Genehmigungsracebedingung zu verhindern, besteht darin, den unten beschriebenen Ansatz „Benannte Bereitstellungen“ zu verwenden.
Benannte Bereitstellungen
Beim Ansatz mit benannten Bereitstellungen wird für jede neue Version der bereitgestellten Anwendung eine neue Bereitstellung erstellt. Nachdem die Anwendung auf ihre maßgeschneiderte Bereitstellung getestet wurde, wird diese Bereitstellung als Produktionsbereitstellung festgelegt. Die Bereitstellung, die die vorherige Version enthält, kann so lange beibehalten werden, bis sichergestellt ist, dass kein Rollback erforderlich ist.
In der folgenden Abbildung wird Version v5 in der Bereitstellung deployment-v5 ausgeführt. Der Bereitstellungsname enthält jetzt die Version, weil die Bereitstellung speziell für diese Version erstellt wurde. Es gibt am Anfang keine andere Bereitstellung. Um nun Version v6 bereitzustellen, erstellt die Bereitstellungspipeline eine neue Bereitstellung deployment-v6 und stellt dort App-Version v6 bereit.
Es besteht kein Risiko, dass eine andere Version parallel bereitgestellt wird. Erstens erlaubt Azure Spring Apps nicht die Erstellung einer dritten Bereitstellung, wenn bereits zwei Bereitstellungen vorhanden sind. Zweitens, selbst wenn es möglich wäre, mehr als zwei Bereitstellungen zu verwenden, wird jede Bereitstellung durch die Version der Anwendung identifiziert, die sie enthält. Daher würde die Pipeline, die die Bereitstellung von v6 orchestriert, nur versuchen, deployment-v6 als Produktionsbereitstellung festzulegen.
Nachdem die für die neue Version erstellte Bereitstellung Produktionsdatenverkehr empfängt, müssen Sie die Bereitstellung mit der vorherigen Version entfernen, um Platz für zukünftige Bereitstellungen zu schaffen. Möglicherweise möchten Sie die Entfernung um einige Minuten oder Stunden aufschieben, damit Sie ein Rollback auf die vorherige Version ausführen können, wenn Sie ein kritisches Problem in der neuen Version feststellen.
Nachteile beim Ansatz benannter Bereitstellungen
Der Ansatz benannter Bereitstellungen hat die folgenden Vorteile:
- Er verhindert die Racebedingung für die Genehmigung.
- Er reduziert den Ressourcenverbrauch, indem die Stagingbereitstellung gelöscht wird, wenn sie nicht verwendet wird.
Es gibt jedoch auch Nachteile, wie im folgenden Abschnitt beschrieben.
Fehler der Bereitstellungspipeline
Zwischen dem Start einer Bereitstellung und dem Löschen der Stagingbereitstellung schlagen alle weiteren Versuche, die Bereitstellungspipeline auszuführen, fehl. Die Pipeline versucht, eine neue Bereitstellung zu erstellen. Dies führt zu einem Fehler, da pro Anwendung in Azure Spring Apps nur zwei Bereitstellungen zulässig sind.
Daher muss die Bereitstellungsorchestrierung entweder über die Möglichkeit verfügen, einen fehlgeschlagenen Bereitstellungsprozess zu einem späteren Zeitpunkt zu wiederholen, oder sie muss sicherstellen, dass die Bereitstellungsabläufe für jede Version in der Warteschlange bleiben, bis der Ablauf für alle vorherigen Versionen abgeschlossen ist.