Aktualisieren und Bereitstellen von Änderungen in Azure-Container-Apps
Die Änderungsverwaltung kann schwierig sein, wenn Sie containerisierte Anwendungen in der Cloud entwickeln. Letztendlich benötigen Sie die Unterstützung, um Änderungen nachzuverfolgen, die Betriebszeit sicherzustellen und Mechanismen zum Behandeln von reibungslosen Rollbacks zu haben.
Die Änderungsverwaltung in Azure Container-Apps wird durch Überarbeitungen unterstützt, die eine Momentaufnahme jeder Version Ihrer Container-App sind.
Zu den wichtigsten Merkmalen von Überarbeitungen gehören:
Unveränderlich: Nach der Einrichtung wird eine Überarbeitung nicht mehr verändert Standard.
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 neu Standard statisch sind, können Sich Änderungen des Anwendungsbereichs auf alle Überarbeitungen auswirken, während Überarbeitungsumfangänderungen eine neue Revision 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. Diese Funktion ist besonders nützlich, wenn Sie verschiedene Versionen Ihrer App gleichzeitig verwalten müssen.
Lebenszyklus
Jede Überarbeitung wird spezifischen Zuständen unterzogen, die durch ihren Status und ihre Verfügbarkeit beeinflusst werden. Während des Lebenszyklus durchläuft eine Container-App verschiedene Bereitstellungs-, Ausführungs- und inaktiven Status.
Bereitstellungsstatus
Wenn Sie eine neue Revision 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 keine neuen Replikate bereitstellen. Die Container-App kann neue Replikate erstellen, wenn Skalierungsregeln ausgelöst werden. |
| Wird aktiviert | Null ausgeführte Replikate, ein Replikat, das bereitgestellt wird. |
| Fehler bei der Aktivierung | Das erste Replikat konnte nicht bereitgestellt werden. |
| Skalierung/Verarbeitung | Die Skalierung in oder aus dem Vorgang tritt auf. 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. |
| Heruntergestuft | Mindestens ein Replikat in der Überarbeitung befindet sich in einem fehlerhaften Zustand. Zeigen Sie die Statusdetails für bestimmte Probleme an. |
| Fehler | Kritische Fehler verursachten einen Fehler bei Überarbeitungen. Der Ausführungszustand enthält Details. Häufige Ursachen sind: •Beendigung • Exit-Code 137 |
Inaktiver Status
Überarbeitungen können auch in einen inaktiven Zustand eintreten. Diese Überarbeitungen besitzen keine Bereitstellungs- oder Ausführungszustände. Azure Container Apps Standard enthält jedoch eine Liste dieser Überarbeitungen, wobei bis zu 100 inaktive Einträge enthalten sind. Sie können jederzeit eine Überarbeitung aktivieren.
Ändern des Grenzwerts für inaktive Überarbeitungen
Sie können den --max-inactive-revisions Parameter mit den containerapp create Befehlen oder containerapp update Befehlen verwenden, um die Anzahl der inaktiven Überarbeitungen zu steuern, die von Container-Apps nachverfolgt werden.
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 wie durch die Skalierungsregel definiert ausgeführt werden, wird der Datenverkehr von der alten Version auf die neue umgeleitet. Wenn ein Update fehlschlägt, verweist der Datenverkehr erneut Standard auf die alte Revision. Alte Überarbeitungen werden automatisch aufgehoben. | Ja |
| Mehrere | Sie können mehrere aktive Überarbeitungen haben, den Datenverkehr zwischen Überarbeitungen teilen und auswählen, wann alte Überarbeitungen aufgehoben werden sollen. Diese Steuerungsebene ist hilfreich, um mehrere Versionen einer App, blaugrüner Tests oder die vollständige Kontrolle über App-Updates zu testen. Weitere Informationen finden Sie unter "Datenverkehrsteilung" . |
Beschriftungen
Bei Container-Apps mit externem HTTP-Datenverkehr wird der direkte Datenverkehr zu bestimmten Überarbeitungen bezeichnet. 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:
- Bestehen aus alphanumerischen Zeichen oder Gedankenstrichen (
-) - Beginnen mit einem alphabetischen Zeichen
- Beenden mit einem alphanumerischen Zeichen
Bezeichnungen dürfen nicht:
- Zwei aufeinander folgende Striche aufweisen (
--) - Mehr als 64 Zeichen
Sie können Bezeichnungen über die Seite Revisionsverwaltung Ihrer Container-App im Azure-Portal verwalten.
Die Bezeichnungs-URL ist im Bereich "Überarbeitungsdetails" verfügbar.
Bereitstellung ohne Ausfallzeit
Im Einzelrevisionsmodus stellt Container-Apps sicher, dass ihre App beim Erstellen einer neuen Überarbeitung keine Ausfallzeiten erlebt. 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 wurde erfolgreich bereitgestellt.
- Die Revision wurde so skaliert, dass sie mit der anzahl der vorherigen Revisionen übereinstimmt (die min. und die maximale Replikatanzahl der neuen Revision wird berücksichtigt).
- Alle Replikate haben ihre Start- und Bereitschaftssonden bestanden.
Im Mehrversionsmodus können Sie steuern, wann Überarbeitungen aktiviert oder deaktiviert werden und welche Überarbeitungen datenverkehrseingangsgesteuert 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 Einzelrevisionsmodus der Standard ist, möchten Sie manchmal die vollständige Kontrolle darüber haben, wie Ihre Überarbeitungen verwaltet werden.
Mit mehreren Überarbeitungsmodus 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 ist.
Trennung von Datenverkehr
Das folgende Diagramm zeigt eine Container-App mit zwei Revisionen.
In diesem Szenario wird davon ausgegangen, dass sich die Container-App im folgenden Zustand befindet:
- Ingress ist aktiviert und stellt die Container-App über HTTP oder TCP zur Verfügung.
- 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, sollten Sie möglicherweise eine Überarbeitung für Anforderungen für eine bestimmte URL zur Verfügung stellen. Mit mehreren Überarbeitungsmodus können Sie alle Anforderungen senden, die an Ihre Aufgaben gesendet werden Standard an die neueste Revision, während Anforderungen für eine ältere Überarbeitung über Bezeichnungen für den direkten Zugriff verfügbar sind.
Aktivierungszustand
Im Mehrversionsmodus können Sie Überarbeitungen nach Bedarf aktivieren oder deaktivieren. Aktive Überarbeitungen sind betriebsbereit und können Anforderungen verarbeiten, während inaktive Überarbeitungen wieder Standard ruhen.
Container-Apps berechnen keine inaktiven Überarbeitungen. Es gibt jedoch eine Obergrenze für die Gesamtzahl der verfügbaren Überarbeitungen, wobei die ältesten gelöscht werden, sobald Sie die Anzahl von 100 überschreiten.
Ä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
- Eingehende Konfiguration, 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 ihre Benennungskonventionen oder Versionsverwaltungsstrategie besser anzupassen.
Namenssuffix
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 Revisionssuffix "first-revision" entscheiden, wird der vollständige Revisionsname zu "album-api-first-revision".
Ein Revisionssuffixname muss:
- Bestehen aus nur alphanumerischen Zeichen oder Gedankenstrichen (
-) - Beginnen mit einem alphabetischen Zeichen
- Beenden mit einem alphanumerischen Zeichen
Namen dürfen nicht haben:
- Zwei aufeinander folgende Striche (
--) - Mehr als 64 Zeichen
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, ein Update oder ein neues Feature zu starten, können Sie eine neue Revision erstellen, ohne dass sich die aktuelle Liveversion auswirkt. Dieser Ansatz sorgt für einen reibungslosen Übergang und minimiert Unterbrechungen für Endbenutzer.
Zurücksetzen auf frühere Versionen
Manchmal müssen Sie schnell zu einer früheren, stabilen Version Ihrer App rückgängig machen. Sie können bei Bedarf ein Rollback zu einer vorherigen Überarbeitung Ihrer Container-App ausfü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 blaugrüne 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 Phase in einer neuen Revision ausführen. Sobald Sie sich auf die Stabilität und Leistung der neuen Version verlassen haben, können Sie den Datenverkehr vollständig in die grüne Umgebung wechseln.