Aktualisieren und Bereitstellen von Änderungen in Azure Container Apps
Change Management kann schwierig sein, wenn Sie containerisierte Anwendungen in der Cloud entwickeln. Letztendlich benötigen Sie die Unterstützung, um Änderungen nachzuverfolgen, die Uptime sicherzustellen und Mechanismen zum Behandeln von reibungslosen Rollbacks zu haben.
Change Management in Azure Container Apps wird durch Überarbeitungen unterstützt, bei denen es sich um eine Momentaufnahme jeder Version Ihrer Container-App handelt.
Zu den wichtigsten Merkmalen von Überarbeitungen gehören:
Unveränderlich: Nach der Einrichtung bleibt eine Überarbeitung unveränderlich.
Versionsverwaltung: Überarbeitungen dienen als Datensatz der Versionen der Container-App und erfassen den Zustand in verschiedenen Phasen.
Automatisch bereitgestellt: Wenn Sie eine Container-App zum ersten Mal bereitstellen, wird automatisch eine anfängliche Überarbeitung erstellt.
Bereichsänderungen: Während Überarbeitungen statisch bleiben, können Änderungen im Anwendungsbereich sich auf alle Überarbeitungen auswirken, während Änderungen im Revisionsbereich eine neue Überarbeitung erstellen.
Historischer Datensatz: Standardmäßig haben Sie Zugriff auf 100 inaktive Überarbeitungen, aber Sie können diesen Schwellenwert manuell anpassen.
Mehrere Überarbeitungen: Sie können mehrere Überarbeitungen gleichzeitig ausführen. Dieses Feature ist besonders nützlich, wenn Sie verschiedene Versionen Ihrer App gleichzeitig verwalten müssen.
Lebenszyklus
Jede Überarbeitung durchläuft spezifische Zustände, die von ihrem Status und ihrer Verfügbarkeit abhängen. Während des Lebenszyklus durchläuft eine Container-App verschiedene Bereitstellungszustände, Ausführungszustände und einen inaktiven Zustand.
Bereitstellungsstatus
Wenn Sie eine neue Überarbeitung erstellen, wird die Container-App Start- und Bereitschaftsprüfungen unterzogen. Während dieser Phase dient der Bereitstellungsstatus als Leitfaden zum Nachverfolgen des Fortschritts der Container-App.
| Status | Beschreibung |
|---|---|
| Bereitstellung | Die Überarbeitung befindet sich im Überprüfungsprozess. |
| Bereitgestellt | Die Überarbeitung hat alle Prüfungen erfolgreich bestanden. |
| Fehler bei der Bereitstellung. | Bei der Überarbeitung sind während der Überprüfung Probleme aufgetreten. |
Ausführungsstatus
Nachdem eine Container-App erfolgreich bereitgestellt wurde, wechselt eine Überarbeitung in die Betriebsphase. Der Ausführungsstatus unterstützt beim Überwachen der Integrität und Funktionalität einer Container-App.
| Status | Beschreibung |
|---|---|
| Bereitstellung | Die Überarbeitung befindet sich im Überprüfungsprozess. |
| Skalieren auf 0 | Null ausgeführte Replikate, und es werden keine neuen Replikate bereitgestellt. Die Container-App kann neue Replikate erstellen, wenn Skalierungsregeln ausgelöst werden. |
| Wird aktiviert | Null ausgeführte Replikate, es wird ein Replikat bereitgestellt. |
| Fehler bei der Aktivierung | Das erste Replikat konnte nicht bereitgestellt werden. |
| Skalierung/Verarbeitung | Das Abskalieren und Aufskalieren wird durchgeführt. Mindestens ein Replikat wird ausgeführt, während andere Replikate bereitgestellt werden. |
| Wird ausgeführt | Mindestens ein Replikat wird ausgeführt. Es gibt keine Probleme, die gemeldet werden müssen. |
| Wird ausgeführt (max.) | Die maximale Anzahl von Replikaten (gemäß den Skalierungsregeln der Überarbeitung) wird ausgeführt. Es gibt keine Probleme, die gemeldet werden müssen. |
| Aufheben der Bereitstellung | Die Überarbeitung wechselt von „aktiv“ zu „inaktiv“ und entfernt alle von ihr erstellten Ressourcen. |
| Beeinträchtigt | Mindestens ein Replikat in der Überarbeitung befindet sich in einem fehlerhaften Zustand. Zeigen Sie die Details des Ausführungsstatus für bestimmte Probleme an. |
| Fehler | Kritische Fehler führen dazu, dass Überarbeitungen fehlschlagen. Der Ausführungsstatus bietet Details. Häufige Ursachen sind: • Beendigung • Exitcode 137 |
Inaktiver Status
Überarbeitungen können auch in einen inaktiven Zustand eintreten. Diese Überarbeitungen weisen keine Bereitstellungs- oder Ausführungsstatus auf. Azure Container Apps verwaltet jedoch eine Liste dieser Überarbeitungen, die bis zu 100 inaktive Einträge enthält. Sie können jederzeit eine Überarbeitung aktivieren.
Ändern des Grenzwerts für inaktive Überarbeitungen (Vorschau)
Sie können den --max-inactive-revisions-Parameter mit den Befehlen containerapp create oder containerapp update verwenden, um die Anzahl der inaktiven Überarbeitungen zu steuern, die von Container-Apps nachverfolgt werden.
Stellen Sie zunächst sicher, dass Sie die Container-Apps-Erweiterung mit aktivierten Vorschaufeatures für die Azure CLI installiert haben:
az extension add --name containerapp --upgrade --allow-preview true
In diesem Beispiel wird veranschaulicht, wie Sie eine neue Container-App erstellen, die 50 inaktive Überarbeitungen nachverfolgt:
az containerapp create --max-inactive-revisions 50
Revisionsmodi
Azure Container-Apps unterstützen zwei Überarbeitungsmodi. Die Wahl des Modus bestimmt, wie viele Überarbeitungen Ihrer App gleichzeitig aktiv sind.
| Revisionsmodi | Beschreibung | Standard |
|---|---|---|
| Single | Neue Überarbeitungen werden automatisch bereitgestellt, aktiviert und auf die gewünschte Größe skaliert. Sobald alle Replikate gemäß der Skalierungsregel ausgeführt werden, wird der Datenverkehr von der alten Version auf die neue umgeleitet. Wenn ein Update fehlschlägt, wird der Datenverkehr weiterhin auf die alte Überarbeitung verwiesen. Die Bereitstellung alter Überarbeitungen wird automatisch aufgehoben. | Ja |
| Mehrere | Sie können mehrere aktive Überarbeitungen haben, den Datenverkehr zwischen Überarbeitungen aufteilen und auswählen, wann die Bereitstellung alter Überarbeitungen aufgehoben werden soll. Diese Steuerungsebene ist hilfreich, um mehrere Versionen einer App zu testen, Blau-Grün-Tests durchzuführen oder die vollständige Kontrolle über App-Updates zu übernehmen. Weitere Informationen finden Sie unter Datenverkehrsaufteilung. |
Beschriftungen
Für Container-Apps mit externem HTTP-Datenverkehr leiten Bezeichnungen den Datenverkehr zu bestimmten Revisionen weiter. Eine Bezeichnung stellt eine eindeutige URL bereit, mit der Sie den Datenverkehr an die Revision weiterleiten können, der die Bezeichnung zugewiesen ist.
Um den Datenverkehr zu einer anderen Revision weiterzuleiten, können Sie die Bezeichnung einer Revision auf eine andere übertragen.
- Bezeichnungen behalten dieselbe URL bei, wenn sie von einer Revision auf eine andere übertragen werden.
- Eine Bezeichnung kann nur auf jeweils eine Revision angewendet werden.
- Für Revisionen mit Bezeichnungen ist keine Zuordnung für die Aufteilung von Datenverkehr erforderlich.
- Bezeichnungen sind am nützlichsten, wenn sich die App im Modus für mehrere Revisionen befindet.
- Sie können Bezeichnungen, die Aufteilung von Datenverkehr oder beides aktivieren.
Bezeichnungen sind nützlich für das Testen neuer Revisionen. Wenn Sie einer Gruppe von Testbenutzer*innen beispielsweise Zugriff gewähren möchten, können Sie ihnen die URL der Bezeichnung mitteilen. Wenn Sie die Benutzer*innen dann einer anderen Revision zuweisen möchten, können Sie die Bezeichnung in diese Revision verschieben.
Bezeichnungen funktionieren unabhängig von der Aufteilung von Datenverkehr. Bei der Aufteilung von Datenverkehr wird Datenverkehr, der zur Anwendungs-URL der Container-App fließt, basierend auf dem Prozentanteil des Datenverkehrs zu Revisionen weitergeleitet. Wenn der Datenverkehr zur URL einer Bezeichnung weitergeleitet wird, wird er zu einer bestimmten Revision weitergeleitet.
Der Name einer Bezeichnung:
- aus kleingeschriebenen alphanumerischen Zeichen oder Bindestrichen (
-) bestehen - mit einem alphabetischen Zeichen beginnen
- mit einem alphabetischen Zeichen enden
Bezeichnungen dürfen nicht:
- zwei aufeinander folgende Bindestriche (
--) enthalten - aus mehr als 64 Zeichen bestehen
Sie können Bezeichnungen über die Seite Revisionsverwaltung Ihrer Container-App im Azure-Portal verwalten.
Sie finden die Bezeichnungs-URL im Detailbereich der Überarbeitung.
Bereitstellung ohne Ausfallzeit
Im Modus für einzelne Überarbeitungen stellt Container Apps sicher, dass es bei Ihrer App beim Erstellen einer neuen Überarbeitung zu keiner Downtime kommt. Die vorhandene aktive Revision wird erst deaktiviert, wenn die neue Revision bereit ist.
Wenn eingehender Datenverkehr aktiviert ist, empfängt die vorhandene Revision weiterhin 100 % des Datenverkehrs, bis die neue Revision bereit ist.
Eine neue Überarbeitung gilt als bereit, wenn:
- Die Überarbeitung erfolgreich bereitgestellt wurde
- Die Überarbeitung so hochskaliert wurde, dass sie mit der Anzahl der Replikate vorheriger Überarbeitungen übereinstimmt (die minimale und die maximale Replikatanzahl der neuen Überarbeitung wird berücksichtigt)
- Alle Replikate haben ihre Start- und Bereitschaftstests bestanden
Im Modus für mehrere Überarbeitungen können Sie steuern, wann Überarbeitungen aktiviert oder deaktiviert werden und welche Überarbeitungen eingehenden Datenverkehr empfangen. Wenn eine Regel für die Aufteilung von Datenverkehr konfiguriert und dabei latestRevision auf true festgelegt ist, wechselt der Datenverkehr erst dann zur neuesten Revision, wenn diese bereit ist.
Arbeiten mit mehreren Überarbeitungen
Während der Modus für einzelne Überarbeitungen die Standardeinstellung ist, möchten Sie manchmal vielleicht die vollständige Kontrolle darüber haben, wie Ihre Überarbeitungen verwaltet werden.
Mit dem Modus für mehrere Überarbeitungen haben Sie die Flexibilität, Ihre Überarbeitung manuell zu verwalten. Mit dem Modus für mehrere Überarbeitungen können Sie z. B. genau entscheiden, wie viel Datenverkehr jeder Überarbeitung zugeordnet wird.
Trennung von Datenverkehr
Das folgende Diagramm zeigt eine Container-App mit zwei Revisionen.
In diesem Szenario wird vorausgesetzt, dass sich die Container-App im folgenden Zustand befindet:
- Eingang ist aktiviert, wodurch die Container-App über HTTP oder TCP verfügbar wird.
- Die erste Revision wurde als Revision 1 bereitgestellt.
- Nachdem der Container aktualisiert wurde, wurde eine neue Revision als Revision 2aktiviert.
- Die Regeln für die Datenverkehrsaufteilung sind so konfiguriert, dass Revision 1 80 % der Anforderungen und Revision 2 die restlichen 20 % erhält.
Direkter Zugriff auf Überarbeitungen
Anstatt eine Routingregel zum Umleiten des Datenverkehrs zu einer Überarbeitung zu verwenden, möchten Sie manchmal vielleicht eine Überarbeitung für Anforderungen für eine bestimmte URL zur Verfügung stellen. Mit dem Modus für mehrere Überarbeitungen können Sie alle Anforderungen an Ihre Domäne an die neueste Überarbeitung senden, während Anforderungen für eine ältere Überarbeitung über Bezeichnungen für den direkten Zugriff verfügbar sind.
Aktivierungszustand
Im Modus für mehrere Überarbeitungen können Sie Überarbeitungen nach Bedarf aktivieren oder deaktivieren. Aktive Überarbeitungen sind betriebsbereit und können Anforderungen verarbeiten, während inaktive Überarbeitungen ruhen.
Container Apps berechnet keine inaktiven Überarbeitungen. Es gibt jedoch eine Obergrenze für die Gesamtzahl der verfügbaren Überarbeitungen, wobei die ältesten gelöscht werden, sobald die Anzahl von 100 überschritten wird.
Änderungstypen
Änderungen an einer Container-App fallen in eine von zwei Kategorien: Änderungen auf Revisions- oder Anwendungsebene. Änderungen auf Revisionsebene lösen bei der App-Bereitstellung eine neue Revision aus, während Änderungen auf Anwendungsebene dies nicht tun.
Änderungen im Revisionsbereich
Wenn eine Container-App mit einer Änderung auf Revisionsebene aktualisiert wird, wird eine neue Revision erstellt. Die Änderungen sind auf die Revision beschränkt, in der sie bereitgestellt werden, und wirken sich nicht auf andere Revisionen aus.
Bei Änderungen auf Revisionsebene handelt es sich um alle Änderungen an den Parametern im properties.template-Abschnitt der Ressourcenvorlage der Container-App.
Diese Parameter umfassen:
- Revisionssuffix
- Containerkonfiguration und -images
- Skalierungsregeln für die Containeranwendung
Änderungen im Anwendungsbereich
Bei Bereitstellung einer Container-App mit Änderungen auf Anwendungsebene:
- Die Änderungen werden global auf alle Revisionen angewendet.
- Es wird keine neue Revision erstellt.
Bei Änderungen auf Anwendungsebene handelt es sich um alle Änderungen an den Parametern im properties.configuration-Abschnitt der Ressourcenvorlage der Container-App.
Diese Parameter umfassen:
- Geheimniswerte (Revisionen müssen neu gestartet werden, bevor ein Container neue Geheimniswerte erkennt.)
- Revisionsmodus
- Eingangskonfiguration einschließlich:
- Aktivieren oder Deaktivieren von Eingehend
- Regeln für die Aufteilung von Datenverkehr
- Beschriftungen
- Anmeldeinformationen für private Containerregistrierungen
- Dapr-Einstellungen
Anpassen von Überarbeitungen
Sie können den Überarbeitungsnamen und die Bezeichnungen anpassen, um sie besser an Ihren Namenskonventionen oder Ihrer Versionsstrategie auszurichten.
Namensuffix
Jeder Überarbeitung in Container Apps wird ein eindeutiger Bezeichner zugewiesen. Während Namen automatisch generiert werden, können Sie den Überarbeitungsnamen personalisieren.
Das typische Format für einen Überarbeitungsnamen lautet:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Wenn Sie beispielsweise über eine Container-App mit dem Namen album-api verfügen und sich für das Überarbeitungssuffix first-revision entscheiden, wird der vollständige Überarbeitungssname zu album-api-first-revision.
Ein Überarbeitungssuffixname muss:
- aus kleingeschriebenen alphanumerischen Zeichen oder Bindestrichen (
-) bestehen - mit einem alphabetischen Zeichen beginnen
- mit einem alphabetischen Zeichen enden
Namen dürfen nicht:
- zwei aufeinander folgende Bindestriche (
--) enthalten - aus mehr als 64 Zeichen bestehen
Sie können das Revisionssuffix in der ARM-Vorlage, über die az containerapp create- und az containerapp update-Befehle der Azure CLI oder beim Erstellen einer Revision über das Azure-Portal festlegen.
Anwendungsfälle
Im Folgenden finden Sie häufige Anwendungsfälle für die Verwendung von Überarbeitungen in Container-Apps. Diese Liste ist keine vollständige Liste des Zwecks oder der Funktionen der Verwendung von Container Apps-Überarbeitungen.
Releaseverwaltung
Überarbeitungen optimieren den Prozess der Einführung neuer Versionen Ihrer App. Wenn Sie bereit sind, das Roll-out für ein Update oder ein neues Feature durchzuführen, können Sie eine neue Überarbeitung erstellen, ohne dass sich dies auf die aktuelle Liveversion auswirkt. Dieser Ansatz sorgt für einen reibungslosen Übergang und minimiert Störungen für Endbenutzer.
Zurücksetzen auf vorherige Versionen
Manchmal müssen Sie schnell auf eine frühere, stabile Version Ihrer App zurücksetzen. Sie können bei Bedarf ein Rollback auf eine vorherige Überarbeitung Ihrer Container-App durchführen.
A/B-Tests
Wenn Sie unterschiedliche Versionen Ihrer App testen möchten, können Überarbeitungen A/B-Tests unterstützen. Sie können eine Teilmenge Ihrer Benutzer an eine neue Überarbeitung weiterleiten, Feedback sammeln und fundierte Entscheidungen basierend auf realen Daten treffen.
Blaugrün-Bereitstellungen
Überarbeitungen unterstützen die Blau-Grün-Bereitstellungsstrategie. Wenn Sie zwei parallele Überarbeitungen haben (blau für die Liveversion und grün für die neue Version), können Sie schrittweise eine neue Überarbeitung einführen. Sobald Sie von der Stabilität und Leistung der neuen Version überzeugt sind, können Sie den Datenverkehr vollständig in die grüne Umgebung umleiten.