Azure Container Apps erklärt: Umgebungen, Revisionen, Secrets

Sie spielen ein neues Image in Azure Container Apps ein, und für einen Moment laufen zwei Versionen der App nebeneinander: Die alte bekommt jeden Request, bis die neue bereit ist. Dann rotieren Sie einen API-Schlüssel, und die App nutzt weiter den alten. Beides folgt aus derselben Idee, der Revision.

Dieses Erklärvideo geht ein komplettes Deployment durch: was eine Container-Apps-Umgebung ist, wie Sie mit der CLI und mit YAML deployen, wie Einstellungen und Secrets in den Container gelangen, wie er ohne Passwort aus einer privaten Registry zieht und wie Sie prüfen, ob ein Deployment wirklich funktioniert. Ein Bild hilft dabei: Die Umgebung ist eine Stadt, jede Container App eine U-Bahn-Linie und jede Revision ein Zug, einmal gebaut aus einem Image und einem Satz Einstellungen, danach nie mehr verändert.

Das Wichtigste

• Die Umgebung ist die Grenze. Apps in einer Umgebung teilen ein virtuelles Netzwerk und standardmäßig einen Log-Analytics-Arbeitsbereich. Nutzen Sie getrennte Umgebungen für Entwicklung, Test und Produktion.
• Jede Änderung am Template baut eine neue Revision. Im Single-Revision-Modus (Standard) behält die alte Revision den gesamten Traffic, bis die neue bereitgestellt, hochskaliert und durch ihre Health-Probes gekommen ist.
• Secrets gehören zur App. Eine Secret-Änderung baut keine neue Revision; die laufenden Container behalten den Wert vom Start, bis die Revision neu startet.
• Mit Managed Identity ziehen, von außen nach innen prüfen. AcrPull auf Azure Container Registry, kein Passwort; danach show, Logs, Revisionen und Replikate.

Die Umgebung

Eine Umgebung ist die Grenze, in der Ihre Container Apps leben. Apps in derselben Umgebung teilen ein virtuelles Netzwerk und schreiben ihre Logs an denselben Ort, standardmäßig in einen Log-Analytics-Arbeitsbereich. Damit ist sie das natürliche Zuhause für Dienste, die zusammengehören, etwa eine API und den Hintergrund-Worker, der sie versorgt. Sie trennt auch Stufen: Entwicklung, Test und Produktion bekommen je eine eigene Umgebung, damit eine defekte Test-Revision nie die Produktion berührt.

Innerhalb der Umgebung entscheidet jede App, wer sie erreichen darf:

In beiden Fällen lauscht der Container auf seinem Target-Port, und Container Apps liefert ihn per HTTPS auf Port 443 aus.

az containerapp env create \
  --name aca-env-demo \
  --resource-group rg-aca-demo \
  --location centralus

Neue Umgebungen nutzen standardmäßig Workload-Profile mit einem Consumption-Profil, das auf null skaliert: Sie zahlen für das, was Ihre Apps nutzen.

Deployen und aktualisieren

Das schnellste erste Deployment ist az containerapp up: Ein Befehl kann die Umgebung und alles drumherum anlegen, das Image deployen und die Adresse der App ausgeben. Gut für einen ersten Versuch. Für echte Umgebungen legen Sie die Umgebung zuerst an und deployen mit az containerapp create hinein: dasselbe Image, derselbe Port, derselbe Ingress, aber nichts wird hinter Ihrem Rücken angelegt.

az containerapp create -n ai-api -g rg-aca-demo \
  --environment aca-env-demo \
  --image mcr.microsoft.com/k8se/quickstart:latest \
  --target-port 80 --ingress external

So oder so baut Container Apps die erste Revision: eine Momentaufnahme der App mit Image, Einstellungen und Skalierungsregeln. Eine Revision ändert sich nie. Version zwei entsteht als neue Revision neben der laufenden:

az containerapp update -n ai-api -g rg-aca-demo \
  --image myregistry.azurecr.io/ai-api:v2 \
  --revision-suffix v2

Single-Revision-Modus (Standard): Die alte Revision behält den gesamten Traffic, während die neue startet, hochskaliert und ihre Health-Probes besteht. Erst dann wechselt der Traffic, und die alte Revision wird heruntergefahren. Wird die neue Revision nie bereit, wechselt nichts, und die Nutzer bleiben auf der alten Version. Im Multiple-Revision-Modus entscheiden Sie selbst und können den Traffic aufteilen, zum Beispiel 90 % zu 10 %.

YAML im Team: Halten Sie die ganze App in einer YAML-Datei in der Versionsverwaltung und prüfen Sie Änderungen wie Code. Mit --yaml ist die Datei die ganze Wahrheit: Die CLI ignoriert jedes andere Flag in diesem Befehl.

properties:
  configuration:
    ingress: { external: true, targetPort: 8000 }
  template:
    containers:
    - name: ai-api
      image: myregistry.azurecr.io/ai-api:v2

Einstellungen und Secrets

Dasselbe Image soll in Test und Produktion laufen; was sich unterscheidet, ist die Konfiguration. Nicht sensible Einstellungen wie ein Log-Level oder ein Feature-Flag kommen in Umgebungsvariablen. --set-env-vars ergänzt oder ändert eine und lässt die übrigen stehen.

Sensible Werte wie ein API-Schlüssel werden Secrets. Ein Secret gehört zur App, nicht zu einer Revision, und wird verschlüsselt gespeichert. Eine Umgebungsvariable verweist mit secretref: und dem Namen des Secrets darauf, und der Name muss exakt passen, auch in der Groß- und Kleinschreibung:

az containerapp secret set -n ai-api -g rg-aca-demo \
  --secrets embeddings-api-key=<value>
az containerapp update -n ai-api -g rg-aca-demo \
  --set-env-vars \
  EMBEDDINGS_API_KEY=secretref:embeddings-api-key

In YAML heißt es secretRef, und die Datei enthält nur den Namen, nie den Wert:

properties:
  template:
    containers:
    - name: ai-api
      env:
      - name: LOG_LEVEL
        value: info
      - name: EMBEDDINGS_API_KEY
        secretRef: embeddings-api-key

Der Code weiß von alledem nichts. Er liest einfach eine Umgebungsvariable:

import os
key = os.environ["EMBEDDINGS_API_KEY"]

Die zwei Teile einer Container App. Das ist die Idee hinter der Frage vom Anfang:

Wenn Sie also ein Secret aktualisieren, erscheint keine neue Revision. Die laufenden Container haben ihre Secrets beim Start gelesen und behalten den alten Wert. Um den neuen zu übernehmen, starten Sie die Revision neu oder deployen eine neue:

az containerapp revision restart -n ai-api \
  -g rg-aca-demo --revision ai-api--v2

Liegt das Secret in Azure Key Vault, referenzieren Sie es stattdessen über eine Managed Identity. Verweisen Sie auf das Secret ohne Version, holt Container Apps eine neue Version innerhalb von 30 Minuten und startet die aktiven Revisionen neu, die es verwenden.

Aus einer privaten Registry ziehen

Produktions-Images liegen meist in einer privaten Registry wie Azure Container Registry, also braucht die App die Berechtigung zum Pull. Benutzername und Passwort funktionieren mit fast jeder Registry, sind aber ein weiteres Secret, das Sie in jeder App speichern und rotieren müssen. Mit Azure Container Registry ist eine Managed Identity der bessere Weg: Die App bekommt eine eigene Identität in Microsoft Entra ID, die Registry vertraut dieser Identität, und nirgends existiert ein Passwort.

az containerapp create -n ai-api -g rg-aca-demo \
  --environment aca-env-demo \
  --image myregistry.azurecr.io/ai-api:v1 \
  --registry-server myregistry.azurecr.io \
  --registry-identity system \
  --ingress external --target-port 8000

Die CLI nutzt die Identität der App und weist, wo sie kann, die Rolle AcrPull auf der Registry zu. AcrPull ist das Minimum: Die Identität kann Images ziehen, aber nie pushen. Ziehen mehrere Apps aus derselben Registry, empfiehlt Microsoft eine benutzerseitig zugewiesene Identität: Sie existiert vor der App, und viele Apps können sie teilen.

Tags: Container Apps fragt die Registry bei jedem Containerstart nach dem Image. Wandert ein Tag wie latest, kann ein Neustart oder ein Scale-out unbemerkt anderen Code ausführen; geben Sie deshalb jedem Release einen eigenen Tag. Nach jeder Änderung an der Registry deployen Sie eine Revision und sehen zu, wie sie startet, bevor Sie ihr vertrauen.

Prüfen, ob es funktioniert

Ein Befehl ohne Fehler ist noch keine funktionierende App. Prüfen Sie von außen nach innen:

1. Die App. az containerapp show liefert die Konfiguration. Fragen Sie den Ingress nach der Adresse ab, prüfen Sie, ob er extern ist, wenn Aufrufer von außen kommen sollen, und rufen Sie einen Health-Endpunkt auf.
2. Konsolenlogs sind das, was Ihr Container schreibt: eine fehlende Variable, ein Absturz, ein falscher Port. Standardmäßig zeigt logs show die letzten 20 Zeilen eines Replikats der neuesten Revision; --follow streamt sie live.
3. Systemlogs (--type system) schreibt die Plattform: Image-Pulls, Probes, Neustarts. Ist der Container nie gestartet, schauen Sie dort.
4. Revisionen. revision list zeigt, welche Revisionen aktiv sind, und ihren Laufzustand: Running, Activating, Degraded oder Failed. Nach jedem Update sollte eine neue erscheinen.
5. Replikate sind die laufenden Kopien einer Revision. Eine leere Liste ist nicht immer ein Absturz: Standardmäßig skaliert eine App zwischen null und zehn Replikaten, ohne Traffic hat sie also einfach keins. Der nächste Request startet eines und wartet darauf; stört dieser Kaltstart, setzen Sie die minimale Replikatzahl auf eins.

az containerapp show -n ai-api -g rg-aca-demo \
  --query properties.configuration.ingress.fqdn
az containerapp logs show -n ai-api -g rg-aca-demo \
  --follow --tail 30
az containerapp logs show -n ai-api -g rg-aca-demo \
  --type system
az containerapp revision list -n ai-api -g rg-aca-demo
az containerapp replica list -n ai-api -g rg-aca-demo

Fünf schnelle Lösungen

Weiterlesen

• Microsoft-Learn-Modul: Deploy containers to Azure Container Apps
• Revisionen in Azure Container Apps
• Secrets in Azure Container Apps verwalten
• Image-Pull mit einer Managed Identity