Container-Web-App benötigt Skalierung und sicheres Rollout? Container App erstellen

CloudTrips muss einen leichtgewichtigen Webcontainer hosten, seine Replikate mit der HTTP-Nachfrage skalieren und eine neue Version schrittweise veröffentlichen. Azure Container Apps bietet verwalteten Ingress, KEDA-basierte Skalierung und unveränderliche Revisionen, ohne dass CloudTrips Kubernetes betreiben muss.

Environment   → gemeinsame Netzwerk- und Betriebsgrenze
Container App → Anwendungsendpunkt und globale Konfiguration
Revision      → unveränderliche Version von Image, Ressourcen und Skalierungsregeln
Replica       → laufende Instanz einer Revision

Jede aktive Revision skaliert unabhängig. Revisionen steuern, welche Version Verkehr erhält; Replikate steuern, wie viele Kopien dieser Version laufen.

Erstelle die Container App

Suche nach Container Apps, wähle Create > Container App und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-containerapps-test-weu
Container app name: ca-cloudtrips-web02-test-weu
Region: West Europe
Deployment source: Container image
Container Apps environment: Create new
Environment name: cae-cloudtrips02-test-weu
Environment type: Consumption only
Use your own virtual network: No
Workload profile: Consumption (automatisch ausgewählt)

Wähle auf der Container-Konfigurationsseite eine öffentliche Registry und trage ein:

Image source: Docker Hub or other registries
Registry login server: mcr.microsoft.com
Image and tag: k8se/samples/test-app:fb699ef
Container name: web
CPU: 0.5
Memory: 1 Gi
Environment variable: REVISION_COMMIT_ID = fb699ef

Konfiguriere Ingress:

Ingress: Enabled
Ingress traffic: Accepting traffic from anywhere
Ingress type: HTTP
Transport: Auto
Target port: 80
Allow insecure connections: Disabled

Wähle Review + create > Create. Bei der Erstellung im Portal erzeugt Azure normalerweise ein zufälliges Suffix für die erste Revision, zum Beispiel --wxynloe. Das ist normal und kann später nicht umbenannt werden. Die Revision erhält später in dieser Reise das lesbare Label blue.

Das Consumption-Workload-Profil kann Replikate auf null skalieren und berechnet den tatsächlichen Ressourcenverbrauch. Bei aktiviertem Log Analytics kann die Umgebung zusätzlich Kosten für Logaufnahme verursachen.

Prüfe die erste Revision

Öffne die Container App und kopiere ihre Application Url. Ergänze /api/env und rufe sie auf:

curl --fail --show-error \
  'https://<CONTAINER_APP_FQDN>/api/env' \
  | jq -r '.env.REVISION_COMMIT_ID'

Erwartetes Ergebnis:

fb699ef

Dieser Microsoft-Beispielendpunkt liefert seine Umgebungsvariablen als JSON. Der Wert identifiziert die Container-Image-Version, die geantwortet hat.

Aktiviere mehrere Revisionen

Öffne Application > Revisions and replicas. Unter Deployment mode ersetzt der Standardmodus Single ohne Ausfallzeit, hält aber nur die neueste fehlerfreie Revision aktiv. Ändere Deployment mode auf Multiple und wende die Änderung an.

Multiple hält mehr als eine Revision aktiv und ermöglicht Traffic Splitting, direkte Revisionstests und sofortiges Rollback.

Erstelle die grüne Revision und Skalierungsregel

Wähle unter Revisions and replicas Create new revision und konfiguriere:

Based on revision: Select the current initial revision
Revision suffix: green

Wähle unter Container image die vorhandene Zeile web und danach Edit. Füge keinen zweiten Container hinzu. Ändere beide Versionswerte und speichere:

Registry login server: mcr.microsoft.com
Image: k8se/samples/test-app
Tag: c6f1515
Existing environment variable: REVISION_COMMIT_ID = c6f1515

Bearbeite die vorhandene Variable, statt ein Duplikat anzulegen. Die erste Revision bleibt unverändert, da Revisionen unveränderlich sind. Setze unter Scale:

Minimum replicas: 0
Maximum replicas: 5

Füge unter Scale hinzu:

Rule name: http-requests
Type: HTTP Scaling
Concurrent requests: 10

Erstelle die Revision und warte, bis sie Healthy und Active ist.

Die HTTP-Regel bewertet die letzten gleichzeitigen Anfragen. Übersteigt die Nachfrage zehn gleichzeitige Anfragen pro Replikat, kann Container Apps bis zu fünf Replikate hinzufügen und ohne Nachfrage auf null zurückkehren. Eine Änderung der Skalierung ist revisionsbezogen und erzeugt deshalb eine neue unveränderliche Revision, statt Blue zu verändern.

Teste Green ohne Produktionsverkehr

Weise der ursprünglichen Revision unter Revisions and replicas das Label blue und der neuen Revision green zu. Ein Label bietet eine stabile URL, die genau eine Revision anspricht, unabhängig von Produktionsgewichtungen.

Öffne die Details der grünen Revision, kopiere ihre Label-URL, ergänze /api/env und teste sie:

curl --fail --show-error \
  'https://<GREEN_LABEL_FQDN>/api/env' \
  | jq -r '.env.REVISION_COMMIT_ID'

Erwartetes Ergebnis:

c6f1515

Das ist ein Smoke-Test: Green wird validiert, bevor gewöhnliche Benutzer diese Version erhalten.

Teile den Produktionsverkehr

Lasse unter Revisions and replicas beide Revisionen aktiv und setze:

Blue revision traffic: 80%
Green revision traffic: 20%
Total: 100%

Speichere die Traffic-Konfiguration. Der Ingress-Proxy verteilt nun jede neue Anfrage nach diesen Gewichtungen. Sende mehrere unabhängige Anfragen an die normale Anwendungs-URL:

for request in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
  curl --silent --header 'Connection: close' \
    'https://<CONTAINER_APP_FQDN>/api/env' \
    | jq -r '.env.REVISION_COMMIT_ID'
done

Die meisten Antworten sollten fb699ef und einige c6f1515 zeigen. Die Prozentwerte sind Wahrscheinlichkeiten über Anfragen; zwanzig Aufrufe müssen nicht exakt sechzehn blaue und vier grüne Antworten ergeben.

Teste die HTTP-Skalierung

Sende vorübergehend parallele Anfragen an die Anwendungs-URL:

for batch in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
  seq 1 50 | xargs -P 50 -I{} \
    curl --silent --output /dev/null \
    'https://<CONTAINER_APP_FQDN>/api/env'
done

Öffne währenddessen Replicas der grünen Revision. Skalierung ist metrikbasiert und nicht sofortig; schnelle Anfragen können enden, bevor alle fünf Replikate benötigt werden. Entscheidend ist, dass die gesunde Revision ohne manuelles VM-Management Replikate ergänzen und später wieder reduzieren kann.

Schließe das Rollout ab

Nachdem Green Smoke- und Traffic-Test bestanden hat, ändere die Gewichtungen:

Blue revision traffic: 0%
Green revision traffic: 100%

Speichere und rufe /api/env erneut auf. Es sollte konsistent c6f1515 zurückgeben. Halte Blue kurz für sofortiges Rollback aktiv oder deaktiviere es nach dem Rollback-Zeitraum. Inaktive Revisionen führen keine Replikate aus und erhalten keinen Verkehr.

Bereinigen

Lösche die eigenständige Ressourcengruppe und damit App, Revisionen, Environment und Monitoring-Ressourcen:

az group delete \
  --name rg-cloudtrips-containerapps-test-weu \
  --yes

Bestätige die Löschung:

az group exists --name rg-cloudtrips-containerapps-test-weu

Erwartetes Ergebnis: false.