Aufträge in Azure Container Apps

Mit Azure-Container-Apps-Aufträgen können Sie containerisierte Aufgaben ausführen, die für eine begrenzte Dauer ausgeführt und dann beendet werden. Sie können Aufträge verwenden, um Aufgaben wie Datenverarbeitung, maschinelles Lernen oder beliebige Szenarien auszuführen, die eine bedarfsgesteuerte Verarbeitung erfordern.

Container-Apps und -Aufträge werden in der gleichen Umgebung ausgeführt, sodass sie Funktionen wie Netzwerk und Protokollierung gemeinsam nutzen können.

Vergleichen von Container-Apps und -Aufträgen

In Azure Container Apps gibt es zwei Arten von Computeressourcen: Apps und Aufträge.

Apps sind Dienste, die kontinuierlich ausgeführt werden. Wenn für einen Container in einer App ein Fehler auftritt, wird er automatisch neu gestartet. Beispiele für Apps sind HTTP-APIs, Web-Apps und Hintergrunddienste, die kontinuierlich Eingaben verarbeiten.

Aufträge sind Aufgaben, die beginnen, für eine begrenzte Dauer ausgeführt und beendet werden. Bei jeder Ausführung eines Auftrags wird in der Regel eine einzelne Arbeitseinheit ausgeführt. Auftragsausführungen werden manuell, nach einem Zeitplan oder als Reaktion auf Ereignisse gestartet. Beispiele für Aufträge sind etwa Batchprozesse, die bei Bedarf ausgeführt werden, sowie geplante Aufgaben.

Beispielszenarien

In der folgenden Tabelle werden allgemeine Szenarien für Apps und Aufträge verglichen:

Behälter Computeressource Notizen
Ein HTTP-Server, der Webinhalte und API-Anforderungen bereitstellt Anwendung Konfigurieren Sie eine HTTP-Skalierungsregel.
Ein Prozess, der nachts Finanzberichte generiert Auftrag Verwenden Sie den Auftragstyp Zeitplan, und konfigurieren Sie einen Cron-Ausdruck.
Ein kontinuierlich ausgeführter Dienst, der Nachrichten aus einer Azure Service Bus-Warteschlange verarbeitet Anwendung Konfigurieren Sie eine benutzerdefinierte Skalierungsregel.
Ein Auftrag, der eine einzelne Nachricht oder einen kleinen Batch von Nachrichten aus einer Azure-Warteschlange verarbeitet und dann anhält Auftrag Verwenden Sie den Auftragstyp Ereignis, und konfigurieren Sie eine benutzerdefinierte Skalierungsregel, um Auftragsausführungen auszulösen, wenn Nachrichten in der Warteschlange vorhanden sind.
Eine Hintergrundaufgabe, die bei Bedarf ausgelöst wird und beendet, wenn sie abgeschlossen ist. Auftrag Verwenden Sie den Manuellen Auftragstyp, und starten Sie die Ausführung manuell oder programmgesteuert mithilfe einer API.
Ein selbst gehosteter GitHub Actions-Runner oder Azure Pipelines-Agent Auftrag Verwenden Sie den Auftragstyp Ereignis, und konfigurieren Sie eine GitHub Actions- oder Azure Pipelines-Skalierungsregel.
Eine Azure Functions-App Anwendung Stellen Sie Azure Functions in Container Apps bereit.
Eine ereignisgesteuerte App, die das Azure WebJobs SDK verwendet Anwendung Konfigurieren Sie eine Skalierungsregel für jede Ereignisquelle.

Konzepte

Eine Container Apps-Umgebung ist eine sichere Grenze, die Container-Apps und Aufträge umgibt. Im Folgenden sind einige wichtige Konzepte aufgeführt:

  • Job: Ein Auftrag definiert die Standardkonfiguration, die für jede Auftragsausführung verwendet wird. Die Konfiguration enthält das zu verwendende Containerimage, die zuzuordnenden Ressourcen und den auszuführenden Befehl.
  • Auftragsausführung: Bei einer Auftragsausführung handelt es sich um eine einzelne Ausführung eines Auftrags, der manuell, in einem Zeitplan oder als Reaktion auf ein Ereignis ausgelöst wird.
  • Auftragsreplikat: Eine typische Auftragsausführung führt ein Replikat aus, das durch die Konfiguration des Auftrags definiert ist. In erweiterten Szenarien kann eine Auftragsausführung mehrere Replikate ausführen.

Diagramm, das eine Übersicht über Container-Apps-Aufträge bereitstellt.

Berechtigungen

Um einen Container-App-Job zu starten, benötigt Ihr Benutzerkonto oder Service Principal die entsprechenden Berechtigungen. Betrachten Sie folgende Rollen:

  • Container-Apps Jobs-Mitwirkender: Ermöglicht Berechtigungen zur Erstellung und Verwaltung von Jobs.
  • Container-Apps Jobs-Operator: Ermöglicht das Lesen, Starten und Beenden von Jobs.
  • Monitoring Reader (optional): Ermöglicht das Anzeigen von Überwachungsdaten für Aufträge.

Sowohl die Rolle Container Apps Jobs Contributor als auch die Rolle Container Apps Jobs Operator enthalten die Microsoft.App/jobs/*/action Platzhalterberechtigung. Dieses Platzhalterzeichen entspricht Microsoft.App/jobs/listSecrets/action, sodass beide Rollen die Berechtigung gewähren, die geheimen Werte des Jobs im Klartext zu lesen.

Wenn keine der beiden Rollen mit dem gewünschten Zugang übereinstimmt, erstelle eine benutzerdefinierte Rolle , die nur die benötigten Aktionen auflistet. Zum Beispiel ermöglichen die folgenden Aktionen einem Benutzer das Ansehen, Starten und Stoppen von Jobs, ohne die Microsoft.App/jobs/*/action Wildcard zu verwenden. Da dieser Regelsatz enthält Microsoft.App/jobs/start/action, gewähren Sie ihn nur Identitäten, denen Sie vertrauen, dass sie die Geheimnisse des Jobs und verwaltete Identitäten verwenden, die so konfiguriert sind, dass sie für seine Container verfügbar sind:

  • Microsoft.App/jobs/read
  • Microsoft.App/jobs/start/action
  • Microsoft.App/jobs/stop/action
  • Microsoft.App/jobs/stop/execution/action
  • Microsoft.App/jobs/executions/read
  • Microsoft.App/jobs/execution/read
  • Microsoft.App/managedEnvironments/read

Vermeiden Sie Wildcard-Muster wie Microsoft.App/jobs/*/action in einer benutzerdefinierten Rollendefinition. Diese Wildcard gewährt jede aktuelle und zukünftige Operation, die dem Muster entspricht, einschließlich listSecrets.

Warnung

Die Erlaubnis, einen Job zu beginnen, kann Zugang zu den Geheimnissen dieses Jobs gewähren, auch wenn die Rolle die Aktion listSecrets nicht beinhaltet. Die Jobs - Start REST API akzeptiert eine optionale Ausführungsvorlage, die die Haupt- und Init-Container-Images, Befehle und Umgebungsvariablen überschreiben kann. Ein Nutzer, der Microsoft.App/jobs/start/action besitzt und den Namen eines Geheimnisses kennt, kann von einem Container seiner Wahl aus auf dieses Geheimnis verweisen und dessen Wert in dem Container lesen. Der Container kann auch jede verwaltete Identität verwenden, die so konfiguriert ist, dass sie ihm zur Verfügung steht. Erteilen Sie nur Identitäten, denen Sie vertrauen, die Berechtigung, einen Job zu starten und die Geheimnisse des Jobs sowie verfügbare verwaltete Identitäten zu verwenden.

Weitere Informationen finden Sie unter Berechtigungen zum Verwalten von Geheimnissen und rollenbasierte Azure-Zugriffssteuerung.

Arten von Auftragstriggern

Der Triggertyp eines Auftrags bestimmt, wie der Auftrag gestartet wird. Folgende Triggertypen sind verfügbar:

  • Manuell: Manuelle Aufträge werden bei Bedarf ausgelöst.
  • Zeitplan: Geplante Aufträge werden zu bestimmten Zeiten ausgelöst und können wiederholt ausgeführt werden.
  • Ereignis: Ereignisgesteuerte Aufträge werden durch Ereignisse ausgelöst, z. B. eine Nachricht, die in einer Warteschlange eintrifft.

Manuelle Aufträge

Manuelle Aufträge werden bei Bedarf über die Azure CLI, das Azure-Portal oder eine Anforderung an die Azure Resource Manager-API ausgelöst.

Beispiele für manuelle Aufträge:

  • Eine einmalige Verarbeitungsaufgabe wie das Migrieren von Daten von einem System zu einem anderen.
  • Eine E-Commerce-Website, die als Container-App ausgeführt wird, startet eine Auftragsausführung zum Verarbeiten des Inventars, wenn eine Bestellung aufgegeben wird.

Verwenden Sie zum Erstellen eines manuellen Auftrags den Auftragstyp Manual.

Verwenden Sie den az containerapp job create Befehl, um einen manuellen Auftrag mithilfe der Azure CLI zu erstellen. Im folgenden Beispiel wird ein manueller Auftrag namens my-job in einer Ressourcengruppe namens my-resource-group und in einer Container Apps-Umgebung namens my-environment erstellt:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Manual" \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \
    --replica-completion-count 1 \ 
    --parallelism 1 \ 
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi"

Das mcr.microsoft.com/k8se/quickstart-jobs:latest-Image ist ein öffentliches Beispiel für ein Container-Image, das einen Job ausführt, der ein paar Sekunden wartet, eine Nachricht auf der Konsole ausgibt und dann anhält. Informationen zum Authentifizieren und Verwenden eines privaten Containerimages finden Sie unter "Container".

Mit dem vorherigen Befehl wird nur der Auftrag erstellt. Informationen zum Starten einer Auftragsausführung finden Sie unter Starten einer Auftragsausführung bei Bedarf.

Geplante Aufträge

Verwenden Sie zum Erstellen eines geplanten Auftrags den Auftragstyp Schedule.

Container Apps-Aufträge verwenden Cron-Ausdrücke, um Zeitpläne zu definieren. Sie unterstützen das Standard-Cron-Ausdrucksformat mit fünf Feldern für Minute, Stunde, Tag des Monats, Monats und Wochentags. Hier sind einige Beispiele für Cron-Ausdrücke:

Ausdruck BESCHREIBUNG
*/5 * * * * Wird alle 5 Minuten ausgeführt.
0 */2 * * * Wird alle zwei Stunden ausgeführt.
0 0 * * * Wird täglich um Mitternacht ausgeführt.
0 0 * * 0 Wird jeden Sonntag um Mitternacht ausgeführt.
0 0 1 * * Wird am ersten Tag jedes Monats um Mitternacht ausgeführt.

Cron-Ausdrücke in geplanten Aufträgen werden in koordinierter Weltzeit (Coordinated Universal Time, UTC) ausgewertet.

Verwenden Sie den az containerapp job create Befehl, um einen geplanten Auftrag mithilfe der Azure CLI zu erstellen. Im folgenden Beispiel wird ein geplanter Auftrag namens my-job in einer Ressourcengruppe namens my-resource-group und in einer Container Apps-Umgebung namens my-environment erstellt:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \ 
    --parallelism 1 \
    --replica-completion-count 1 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --cron-expression "*/1 * * * *"

Das mcr.microsoft.com/k8se/quickstart-jobs:latest-Image ist ein öffentliches Beispiel für ein Container-Image, das einen Job ausführt, der ein paar Sekunden wartet, eine Nachricht auf der Konsole ausgibt und dann anhält. Informationen zum Authentifizieren und Verwenden eines privaten Containerimages finden Sie unter "Container".

Mit dem Cron-Ausdruck */1 * * * * wird der Auftrag im Minutentakt ausgeführt.

Ereignisgesteuerte Aufträge

Ereignisse von unterstützten benutzerdefinierten Skalierern lösen ereignisgesteuerte Jobs aus. Beispiele für ereignisgesteuerte Aufträge:

  • Ein Auftrag, der ausgeführt wird, wenn eine neue Nachricht zu einer Warteschlange wie Azure Service Bus, Kafka oder RabbitMQ hinzugefügt wird.
  • Ein selbstgehosteter GitHub Actions-Runner oder Azure DevOps-Agent, der ausgeführt wird, wenn in einem Workflow oder einer Pipeline ein neuer Auftrag einer Warteschlange hinzugefügt wird.

Container-Apps und ereignisgesteuerte Aufträge verwenden Skalierer vom Typ KEDA. Beide werten Skalierungsregeln gemäß einem Abfrageintervall aus, um die Menge der Ereignisse für eine Ereignisquelle zu messen, aber die Verwendung der Ergebnisse unterscheidet sich jeweils.

In einer App verarbeitet jedes Replikat fortlaufend Ereignisse, und eine Skalierungsregel bestimmt die Anzahl der Replikate, die zur Erfüllung der Anforderungen ausgeführt werden sollen. Bei ereignisgesteuerten Aufträgen verarbeitet jede Auftragsausführung üblicherweise ein einzelnes Ereignis, und eine Skalierungsregel bestimmt die Anzahl auszuführender Auftragsausführungen.

Verwenden Sie Aufträge, wenn jedes Ereignis eine neue Instanz des Containers mit dedizierten Ressourcen erfordert oder lange Zeit ausgeführt werden muss. Das Konzept ereignisgesteuerter Aufträge ist vergleichbar mit KEDA-Skalierungsaufträgen.

Verwenden Sie zum Erstellen eines ereignisgesteuerten Auftrags den Auftragstyp Event.

Verwenden Sie den az containerapp job create Befehl, um einen ereignisgesteuerten Auftrag mithilfe der Azure CLI zu erstellen. Im folgenden Beispiel wird ein ereignisgesteuerter Auftrag namens my-job in einer Ressourcengruppe namens my-resource-group und in einer Container Apps-Umgebung namens my-environment erstellt:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Event" \
    --replica-timeout 1800 \
    --image "docker.io/myuser/my-event-driven-job:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --min-executions "0" \
    --max-executions "10" \
    --scale-rule-name "queue" \
    --scale-rule-type "azure-queue" \
    --scale-rule-metadata "accountName=mystorage" "queueName=myqueue" "queueLength=1" \
    --scale-rule-auth "connection=connection-string-secret" \
    --secrets "connection-string-secret=<QUEUE_CONNECTION_STRING>"

In dem Beispiel wird eine Azure Storage-Warteschlangenskalierungsregel konfiguriert.

Ein vollständiges Tutorial finden Sie unter Tutorial: Bereitstellen eines ereignisgesteuerten Auftrags mit Azure Container Apps.

Starten einer Auftragsausführung bei Bedarf

Für alle Auftragstypen kann eine Auftragsausführung bei Bedarf gestartet werden.

Verwenden Sie den az containerapp job start Befehl, um eine Auftragsausführung mithilfe der Azure CLI zu starten. Im folgenden Beispiel wird die Ausführung eines Auftrags namens my-job in einer Ressourcengruppe namens my-resource-group gestartet:

az containerapp job start --name "my-job" --resource-group "my-resource-group"

Beim Starten einer Auftragsausführung können Sie die Konfiguration des Auftrags außer Kraft setzen. Sie können beispielsweise eine Umgebungsvariable oder den Startbefehl außer Kraft setzen, um denselben Auftrag mit verschiedenen Eingaben auszuführen. Die außer Kraft gesetzte Konfiguration wird nur für die aktuelle Ausführung verwendet und ändert nicht die Konfiguration des Auftrags.

Wenn Sie eine Konfiguration außer Kraft setzen, wird die gesamte Vorlagenkonfiguration des Auftrags durch die neue Konfiguration ersetzt. Stellen Sie sicher, dass die neue Konfiguration alle erforderlichen Einstellungen enthält.

Warnung

Eine Identität, die einen Job starten kann, kann eine Ausführungsvorlage verwenden, um auf Jobgeheimnisse zu referenzieren, deren Namen sie kennt, und verwaltete Identitäten verwenden, die für den Container verfügbar sind. Weitere Informationen finden Sie unter Berechtigungen.

Um die Konfiguration des Auftrags beim Starten einer Ausführung außer Kraft zu setzen, verwenden Sie den az containerapp job start Befehl, und übergeben Sie eine YAML-Datei, die die Vorlage für die Ausführung enthält. Im folgenden Beispiel wird die Ausführung eines Auftrags namens my-job in einer Ressourcengruppe namens my-resource-group gestartet.

Rufen Sie die aktuelle Konfiguration des Auftrags mit az containerapp job show ab und speichern Sie die Vorlage in einer Datei mit dem Namen my-job-template.yaml.

az containerapp job show --name "my-job" --resource-group "my-resource-group" --query "properties.template" --output yaml > my-job-template.yaml

Die Option --query "properties.template" gibt nur die Vorlagenkonfiguration des Auftrags zurück.

Bearbeiten Sie die Datei my-job-template.yaml, um die Konfiguration des Auftrags außer Kraft zu setzen. Um beispielsweise die Umgebungsvariablen außer Kraft zu setzen, ändern Sie den Abschnitt env:

containers:
- name: print-hello
  image: ubuntu
  resources:
    cpu: 1
    memory: 2Gi
  env:
  - name: MY_NAME
    value: Azure Container Apps jobs
  args:
  - /bin/bash
  - -c
  - echo "Hello, $MY_NAME!"

Starten Sie den Auftrag mithilfe der Vorlage:

az containerapp job start --name "my-job" --resource-group "my-resource-group" \
    --yaml my-job-template.yaml

Abrufen des Auftragsausführungsverlaufs

Jeder Container Apps-Auftrag verfügt über einen Verlauf mit den letzten Auftragsausführungen.

Verwenden Sie den az containerapp job execution list Befehl, um die Status der Auftragsausführungen mithilfe der Azure CLI abzurufen. Im folgenden Beispiel wird der Status der letzten Ausführung eines Auftrags namens my-job in einer Ressourcengruppe namens my-resource-group zurückgegeben:

az containerapp job execution list --name "my-job" --resource-group "my-resource-group"

Der Ausführungsverlauf für geplante und ereignisbasierte Aufträge ist auf die letzten 100 erfolgreichen und fehlerhaften Auftragsausführungen beschränkt.

Wenn Sie alle Ausführungen eines Auftrags auflisten oder eine detaillierte Ausgabe von einem Auftrag erhalten möchten, fragen Sie den für Ihre Container Apps-Umgebung konfigurierten Protokollanbieter ab.

Erweiterte Auftragskonfiguration

Container Apps-Aufträge unterstützen erweiterte Konfigurationsoptionen wie Containereinstellungen, Wiederholungen, Timeouts und Parallelität.

Containereinstellungen

Containereinstellungen definieren die Container, die in den einzelnen Replikaten einer Auftragsausführung ausgeführt werden sollen. Sie umfassen Umgebungsvariablen, Geheimnisse und Ressourcenlimits. Weitere Informationen finden Sie unter Container. Das Ausführen mehrerer Container in einem einzelnen Auftrag ist ein erweitertes Szenario. Die meisten Aufträge führen einen einzelnen Container aus.

Auftragseinstellungen

Die folgende Tabelle enthält die konfigurierbaren Auftragseinstellungen:

Einstellung „Azure-Ressourcen-Manager“-Eigenschaft CLI-Parameter BESCHREIBUNG
Auftragstyp triggerType --trigger-type Der Auftragstyp (Manual, Scheduleoder Event).
Replikattimeout replicaTimeout --replica-timeout Die maximale Wartezeit bis zum Abschluss eines Replikats (in Sekunden).
Abrufintervall pollingInterval --polling-interval Die Zeit in Sekunden, die zwischen dem Abruf von Ereignissen gewartet wird. Der Standardwert ist 30 Sekunden.
Wiederholungslimit für ein Replikat replicaRetryLimit --replica-retry-limit Die maximale Anzahl von Wiederholungsversuchen für ein fehlerhaftes Replikat. Wenn ein Replikat ohne Wiederholung als fehlerhaft eingestuft werden soll, legen Sie den Wert auf 0 fest. Die replicaTimeout Konfiguration hat Vorrang, wenn sie ausläuft, bevor alle Wiederholungsversuche stattfinden.
Parallelität parallelism --parallelism Die Anzahl von Replikaten, die pro Ausführung ausgeführt werden sollen. Für die meisten Aufträge legen Sie den Wert auf 1 fest.
Anzahl abgeschlossener Replikate replicaCompletionCount --replica-completion-count Die Anzahl von Replikaten, die erfolgreich abgeschlossen werden müssen, damit die Ausführung erfolgreich ist. Die meisten sind gleich oder kleiner als die Parallelität. Für die meisten Aufträge legen Sie den Wert auf 1 fest.

Lang andauernde Aufgaben

Hinweis

Die Wartung der Plattform, einschließlich routinemäßiger Sicherheitsupdates und -upgrades, kann langjährige Job-Replikationen unterbrechen. Setze das Wiederholungslimit für Replikate auf mindestens 1 und lege deine Workload für At-least-once-Verarbeitung so aus, dass Wiederholungsversuche die Arbeit sicher abschließen können.

Beispiel

Im folgenden Beispiel wird ein Auftrag mit erweiterten Konfigurationsoptionen erstellt:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 --replica-retry-limit 3 --replica-completion-count 5 --parallelism 5 \
    --image "myregistry.azurecr.io/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --command "/startup.sh" \
    --env-vars "MY_ENV_VAR=my-value" \
    --cron-expression "0 0 * * *"  \
    --registry-server "myregistry.azurecr.io" \
    --registry-username "myregistry" \
    --registry-password "myregistrypassword"

Jobnetzwerk und App-zu-App-Kommunikation

Wenn ein Job-Pod startet, ist sichergestellt, dass Sidecar-Container (z. B. der Envoy-Proxy) bereit sind, bevor der primäre Job-Container mit der Ausführung beginnt. Dadurch wird sichergestellt, dass App-zu-App-Aufrufe, die der Job beim Start ausführt, ohne Verbindungsfehler erfolgreich sind.

Hinweis

Wenn Ihr Job beim Start Aufrufe an andere Container-Apps ausführt, müssen Sie keine Wiederholungslogik für die anfängliche Sidecar-Bereitschaft hinzufügen. Die Plattform behandelt dies automatisch.

Auftragseinschränkungen

Die folgenden Features werden nicht unterstützt:

  • Dapr
  • Eingang und verwandte Features wie benutzerdefinierte Domänen und SSL-Zertifikate

Nächster Schritt

Job in Azure-Container-Apps erstellen

  • Last updated on