Teilen über

AzureContainerApps@1 – Azure Container Apps Deploy v1 task

  • Artikel

Eine Azure DevOps-Aufgabe zum Erstellen und Bereitstellen von Azure-Container-Apps.

Syntax

# Azure Container Apps Deploy v1
# An Azure DevOps Task to build and deploy Azure Container Apps.
- task: AzureContainerApps@1
  inputs:
  # advanced
    #workingDirectory: # string. Alias: cwd. Working Directory. 
    #appSourcePath: # string. Application source path. 
    azureSubscription: # string. Alias: connectedServiceNameARM. Required. Azure Resource Manager connection. 
    #acrName: # string. Azure Container Registry name. 
    #acrUsername: # string. Azure Container Registry username. 
    #acrPassword: # string. Azure Container Registry password. 
    #dockerfilePath: # string. Dockerfile path. 
    #imageToBuild: # string. Docker image to build. 
    #imageToDeploy: # string. Docker image to deploy. 
    #containerAppName: # string. Azure Container App name. 
    #resourceGroup: # string. Azure resource group name. 
    #containerAppEnvironment: # string. Azure Container App environment. 
    #runtimeStack: # string. Application runtime stack. 
    #targetPort: # string. Application target port. 
    #location: # string. Location of the Container App. 
    #environmentVariables: # string. Environment variables. 
    #ingress: # string. Ingress setting. 
    #yamlConfigPath: # string. YAML configuration file path. 
    #disableTelemetry: # boolean. Disable telemetry.

Eingänge

workingDirectory - Arbeitsverzeichnis-
Eingabealias: cwd. string.

Aktuelles Arbeitsverzeichnis, in dem das Skript ausgeführt wird. Leer ist der Stamm des Repositorys (Build) oder Artefakte (Release), das $(System.DefaultWorkingDirectory) ist.


appSourcePath - Anwendungsquellpfad
string.

Absoluter Pfad für den Läufer des zu erstellenden Quellcodes. Wenn nicht angegeben, muss das Argument "imageToDeploy" angegeben werden, um sicherzustellen, dass die Container-App über ein Image verfügt, auf das verwiesen werden soll.

Beim Pushen eines neuen Images an ACR sind die acrName und appSourcePath Vorgangseingaben erforderlich.


azureSubscription - Azure Resource Manager-Verbindung
Eingabealias: connectedServiceNameARM. string. Erforderlich.

Geben Sie eine Azure Resource Manager-Dienstverbindung für die Bereitstellung an. Diese Dienstverbindung muss mit dem Azure-Abonnement des Benutzers verknüpft sein, in dem die Container-App erstellt/aktualisiert wird. Diese Dienstverbindung muss über die erforderlichen Berechtigungen verfügen, um diese Änderungen innerhalb des Abonnements vorzunehmen, z. B. mitwirkender Rolle.


acrName - Azure Container Registry name
string.

Der Name der Azure-Containerregistrierung, an die das ausgeführte Anwendungsimage übertragen wird.

Beim Pushen eines neuen Images an ACR sind die acrName und appSourcePath Vorgangseingaben erforderlich.


acrUsername - Benutzernamen der Azure-Containerregistrierung
string.

Der Benutzername, der zum Authentifizieren von Pushanforderungen an die bereitgestellte Azure Contrainer Registry verwendet wird. Wenn nicht angegeben, wird ein Zugriffstoken über "az acr login" generiert und für die Authentifizierung der Anforderungen "docker login" bereitgestellt.


kennwort für acrPassword - Azure Container Registry
string.

Das Kennwort zum Authentifizieren von Pushanforderungen an die bereitgestellte Azure Contrainer Registry. Wenn nicht angegeben, wird ein Zugriffstoken über "az acr login" generiert und für die Authentifizierung der Anforderungen "docker login" bereitgestellt.


dockerfilePath - Dockerfile-Pfad
string.

Relativer Pfad (_without Dateipräfixe (siehe die folgenden Beispiele) zur Dockerfile-Datei in der bereitgestellten Anwendungsquelle, die verwendet werden soll, um das Image zu erstellen, das dann an ACR übertragen und in der Container-App bereitgestellt wird. Wenn nicht angegeben, überprüft diese Aufgabe, ob eine Datei mit dem Namen "Dockerfile" im Stammverzeichnis der bereitgestellten Anwendungsquelle vorhanden ist und diese zum Erstellen des Images verwendet wird. Andernfalls wird der Oryx++-Generator verwendet, um das Image zu erstellen.


imageToBuild - Docker-Image zum Erstellen von
string.

Der benutzerdefinierte Name des zu erstellenden Images, pusht an ACR und wird von dieser Aufgabe an die Container-App bereitgestellt. Hinweis: Dieser Bildname sollte den ACR-Server enthalten; z.B. <acr-name>.azurecr.io/<repo>:<tag>. Wenn dieses Argument nicht angegeben wird, wird ein Standardbildname in Form von <acr-name>.azurecr.io/ado-task/container-app:<build-id>.<build-number>erstellt.


imageToDeploy - Docker-Image zum Bereitstellen von
string.

Der Name des Images, das bereits an ACR verschoben wurde und von dieser Aufgabe in der Container-App bereitgestellt wird. Hinweis: Der Bildname sollte den ACR-Server enthalten; z.B. <acr-name>.azurecr.io/<repo>:<tag>. Wenn dieses Argument nicht angegeben wird, wird der für das Argument "imageToBuild" angegebene (oder festgelegte) Wert verwendet. Wenn dieses Bild in einer ACR-Instanz gefunden wird, für die eine Authentifizierung zum Abrufen erforderlich ist, kann das argument acrName oder die argumente acrUsername und acrPassword bereitgestellt werden, um Anforderungen an die ACR-Instanz zu authentifizieren.


containerAppName - Azure Container App-Name
string.

Der Name der Azure-Container-App, die erstellt oder aktualisiert wird. Wenn nicht angegeben, wird dieser Wert in Form von ado-task-app-<build-id>-<build-number>angegeben.


resourceGroup - Azure-Ressourcengruppenname
string.

Die vorhandene Ressourcengruppe, in der die Azure-Container-App erstellt wird (oder derzeit vorhanden ist). Wenn nicht angegeben, wird dieser Wert in Form von <container-app-name>-rgangegeben.


containerAppEnvironment - Azure Container App-Umgebung
string.

Der Name der Azure-Container-App-Umgebung, die mit der Anwendung verwendet werden soll. Wenn nicht angegeben, wird eine vorhandene Umgebung in der Ressourcengruppe der Container-App verwendet, andernfalls wird eine Umgebung im Format von <container-app-name>-enverstellt.


runtimeStack - Anwendungslaufzeitstapel
string.

Der Plattformversionsstapel, der im endgültig ausgeführten Anwendungsimage verwendet wird, das in der Container-App bereitgestellt wird. Der Wert sollte in der Formation <platform>:<version>angegeben werden. Wenn nicht angegeben, wird dieser Wert von Oryx basierend auf dem Inhalt der bereitgestellten Anwendung bestimmt. Weitere Informationen zu unterstützten Laufzeitstapeln für Oryx finden Sie in diesem Dokument.


targetPort - Anwendungszielport
string.

Der Zielport, auf den die Container-App lauscht. Wenn nicht angegeben, lautet dieser Wert für Python-Anwendungen "80" und "8080" für alle anderen unterstützten Plattformen.


location - Speicherort der Container-App-
string.

Der Speicherort, an dem die Container-App (und andere erstellte Ressourcen) bereitgestellt werden.


environmentVariables - Umgebungsvariablen
string.

Eine Liste der Umgebungsvariablen für den Container. Leerzeichentrennte Werte im Format "key=value". Leere Zeichenfolge zum Löschen vorhandener Werte. Präfixwert mit "secretref:", um auf einen geheimen Schlüssel zu verweisen.


ingress - Einstellung "Eingangseinstellung"
string.

Mögliche Optionen: extern, intern, deaktiviert. Bei Festlegung auf external (Standardwert, wenn beim Erstellen einer Container-App nicht angegeben), wird die Container-App je nach konfiguriertem App-Umgebungsendpunkt im Internet oder in einem VNET angezeigt. Wenn dieser Wert auf internalfestgelegt ist, wird die Container-App nur in der App-Umgebung angezeigt. Wenn dieser Wert auf disabledfestgelegt ist, wird der Ingress für diese Container-App deaktiviert und verfügt nicht über einen HTTP- oder TCP-Endpunkt.


yamlConfigPath - YAML-Konfigurationsdateipfad
string.

Vollständiger Pfad (im ausgeführten Azure Pipelines-Agent) zur YAML-Datei, in der die Konfiguration der Container-App beschrieben wird.

Die resourceGroup-Eigenschaft in der YAML-Konfigurationsdatei wird nicht verwendet; der Wert hierfür stammt entweder aus dem argument resourceGroup, das dem Vorgang bereitgestellt wird, oder dem Standardnamen der Ressourcengruppe, der vom Vorgang generiert wird. Alle anderen Eigenschaften, die in der YAML-Konfigurationsdatei bereitgestellt werden, überschreiben die Werte, die als Argumente für diese Aufgabe bereitgestellt werden; Wenn z. B. das argument containerAppName der Aufgabe bereitgestellt wird und die name-Eigenschaft in der YAML-Konfigurationsdatei festgelegt ist, wird die name-Eigenschaft in der YAML-Datei beim Erstellen oder Aktualisieren der Container-App verwendet.

Bild- und Anwendungsquellenargumente (z. B., appSourcePath, imageToDeploy) werden weiterhin verwendet, um zuerst ein Image zu erstellen und/oder zu pushen, das von der Container-App verwendet wird; in diesem Fall muss die bereitgestellte YAML-Konfigurationsdatei je nach Szenario auf das durch imageToDeploy angegebene Bild (oder imageToBuild) verweisen.

Beim Erstellen einer neuen Container-App werden alle in der YAML-Konfigurationsdatei aufgeführten Eigenschaften (mit Ausnahme resourceGroup wie oben erwähnt) festgelegt, wenn die Container-App erstellt wird. Beim Aktualisieren einer vorhandenen Container-App werden nur die in der Datei aufgeführten Eigenschaften in der Container-App aktualisiert.

Derzeit unterstützt die YAML-Datei das Einrichten der verwalteten Identitätsauthentifizierung für die verwendete Containerregistrierung nicht; weitere Informationen zu diesem Problem finden Sie dieses GitHub-Problem.

In Fällen, in denen das argument yamlConfigPath angegeben wird, wird die YAML-Datei an den entsprechenden az containerapp-Befehl übergeben, entweder create oder update je nach Szenario. Weitere Informationen zum beabsichtigten Verhalten, wenn die YAML-Konfigurationsdatei bereitgestellt wird, finden Sie in den Dokumenten, die mit den entsprechenden Befehlen verknüpft sind.

Weitere Informationen zur Struktur der YAML-Konfigurationsdatei finden Sie auf dieser Website.


disableTelemetry - Telemetrie- deaktivieren
boolean.

Wenn dieser Wert auf "true" festgelegt ist, werden keine Telemetriedaten von dieser Azure DevOps-Aufgabe erfasst. Wenn dieser Wert auf "false" festgelegt ist oder dieses Argument nicht angegeben wird, werden Telemetriedaten an Microsoft gesendet, um das Build- und Bereitstellungsszenario für die Container-App zu erhalten, das von dieser Azure DevOps-Aufgabe verwendet wird.


Aufgabensteuerungsoptionen

Alle Aufgaben verfügen zusätzlich zu ihren Aufgabeneingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerelementoptionen und allgemeinen Aufgabeneigenschaften.

Ausgabevariablen

Nichts.

Bemerkungen

Mit dieser Azure Pipelines-Aufgabe können Benutzer ihre Anwendungsquelle ganz einfach in einer Azure-Container-App in ihrem Azure Pipelines-Workflow bereitstellen, indem sie entweder ein zuvor erstelltes Image, eine Dockerfile-Datei, aus der ein Image erstellt werden kann, oder einen Generator verwenden, um ein runnables Anwendungsimage für den Benutzer zu erstellen.

Die Aufgabe weist die folgenden beiden Verwendungsmuster auf.

  • Pushen eines Bilds an ACR- – beim Pushen eines neuen Bilds an ACR sind die eingaben acrName und appSourcePath Aufgaben erforderlich.
  • Bereitstellen eines zuvor verschobenen Images – bei der Bereitstellung eines zuvor verschobenen Images ist die imageToDeploy Aufgabeneingabe erforderlich. Wenn dieses Bild in einer ACR-Instanz gefunden wird, für die eine Authentifizierung zum Abrufen erforderlich ist, kann das argument acrName oder die argumente acrUsername und acrPassword bereitgestellt werden, um Anforderungen an die ACR-Instanz zu authentifizieren.

Anmerkung

Obwohl keine Vorgangseingabe in den Metadaten dieses Vorgangs offiziell als "erforderlich" gekennzeichnet ist, müssen einige Eingaben bereitgestellt werden, damit diese Aufgabe erfolgreich mit einem der beiden Hauptverwendungsmuster ausgeführt werden kann.

Wenn keine Dockerfile-Datei in der bereitgestellten Anwendungsquelle gefunden oder bereitgestellt wird, werden die folgenden Schritte von dieser Aufgabe ausgeführt:

  • Verwendet den Oryx++-Generator, um die Anwendungsquelle mithilfe von Oryx- zu erstellen, um ein runnables Anwendungsimage zu erstellen
  • Pushes this runnable application image to the provided Azure Container Registry
  • Erstellt oder aktualisiert eine Container-App basierend auf diesem Image.

Wenn eine Dockerfile-Datei in der Anwendungsquelle gefunden oder ermittelt wird, wird der Generator nicht verwendet, und das Image wird mit einem Aufruf von docker build erstellt oder aktualisiert, und die Container-App wird basierend auf diesem Image erstellt oder aktualisiert.

Wenn ein zuvor erstelltes Image bereits an die ACR-Instanz übertragen wurde und an diese Aufgabe bereitgestellt wird, ist keine Anwendungsquelle erforderlich, und das Image wird beim Erstellen oder Aktualisieren der Container-App verwendet.

Ausführen dieser Aufgabe auf von Microsoft gehosteten Agents

Wenn Sie diese Aufgabe auf einem von Microsoft gehosteten Agentausführen, stellen Sie möglicherweise fest, dass diese Aufgabe nicht erfolgreich mit den folgenden Betriebssystemen ausgeführt werden kann:

  • macOS
    • Die von Microsoft bereitgestellten macOS-Läufer werden nicht mit Docker installiert (weitere Informationen hier); Daher kann diese Aufgabe keine docker Befehle ausführen, z. B. das Pushen der integrierten runnablen Anwendungsimages an ACR.
  • Fenster
    • Die Windows-Runners, die von Microsoft bereitgestellt werden, sind mit Docker installiert, aber standardmäßig können Linux-basierte Images nicht heruntergezogen werden; Daher kann diese Aufgabe den Oryx-Generator nicht herunterziehen, um runnierbare Anwendungsimages aus der bereitgestellten Anwendungsquelle zu erstellen.

Weitere Informationen finden Sie im folgenden abschnitt Docker Voraussetzungen.

Daten-/Telemetriesammlungshinweis

Standardmäßig sammelt diese Azure DevOps-Aufgabe die folgenden Daten für Microsoft:

  • Das Container-App-Build- und Bereitstellungsszenario für den Benutzer
    • d. h.verwendet, den Oryx++-Generator verwendet, eine bereitgestellte/gefundene Dockerfile-Datei verwendet oder ein zuvor integriertes Image bereitgestellt hat
    • Hinweis: Der Bildname wird nicht gesammelt.
  • Die Verarbeitungszeit des Vorgangs in Millisekunden
  • Das Ergebnis des Vorgangs
    • d. h., erfolgreich oder fehlgeschlagen
  • Wenn der Oryx++-Generator verwendet wird, werden Ereignisse und Metriken im Zusammenhang mit dem Erstellen der bereitgestellten Anwendung mithilfe von Oryx

Wenn Sie die Datensammlung deaktivieren möchten, legen Sie das argument disableTelemetry auf truefest.

Voraussetzungen

Vor dem Ausführen dieser Aufgabe sind Azure-Ressourcen und eine Azure DevOps-Dienstverbindung abhängig von den für diese Aufgabe bereitgestellten Argumenten entweder erforderlich oder optional.

Azure DevOps Service-Verbindung

Für die Bereitstellung in Azure muss ein Azure-Abonnement mit Team Foundation Server oder Mit Azure Pipelines über die Registerkarte "Dienste" im Abschnitt "Einstellungen" verknüpft sein. Fügen Sie das Azure-Abonnement hinzu, das in der Definition "Build" oder "Release Management" verwendet werden soll, indem Sie den Bildschirm "Kontoverwaltung" öffnen (Zahnradsymbol oben rechts auf dem Bildschirm), und klicken Sie dann auf die Registerkarte "Dienste".

Erstellen Sie den ARM--Dienstendpunkt, und verwenden Sie den "Azure Resource Manager" Endpunkttyp; weitere Informationen zum Erstellen von Dienstverbindungen finden Sie in diesem Dokument.

Azure CLI

Diese Aufgabe erfordert, dass die Azure CLI auf dem Azure Pipelines-Agent installiert ist, um eine Vielzahl von Befehlen während der gesamten Ausführung der Aufgabe auszuführen. Weitere Informationen zum Installieren der Azure CLI auf dem Agent finden Sie in diesem Dokument. Wenn ein Agent bereits auf dem Computer ausgeführt wird, auf dem die Azure CLI installiert ist, stellen Sie sicher, dass Sie den Agent neu starten, damit alle relevanten Umgebungsvariablen aktualisiert werden.

Hafenarbeiter

Diese Aufgabe erfordert, dass Docker im Azure Pipelines-Agent installiert ist, um Images an die bereitgestellte Azure-Containerregistrierung zu übertragen. Weitere Informationen zum Installieren von Docker auf dem Agent finden Sie in diesem Dokument.

Darüber hinaus treten benutzer, die diese Aufgabe mit einem Windows-Agent ausführen, möglicherweise ein Problem auf, bei dem linux-basierte Images nicht abgerufen werden können; um dies zu beheben, suchen Sie die DockerCli.exe Datei auf Ihrem Agent (in der Regel im ordner Program Files\Docker\Docker), und führen Sie

& `.\DockerCli.exe` -SwitchDaemon

Wenn Docker nicht auf dem Agent installiert ist, der diese Aufgabe ausführt, sind die folgenden Szenarien weiterhin aktiviert:

  • Bereitstellen eines zuvor erstellten -Images für das argument imageToDeploy, mit dem die Container-App bereitgestellt wird

Wenn Docker sich auf dem Agent befindet, aber nicht mit Linux-basierten Images arbeiten kann, sind die folgenden Szenarien weiterhin aktiviert:

  • Bereitstellen eines zuvor erstellten -Images für das argument imageToDeploy, mit dem die Container-App bereitgestellt wird
  • Bereitstellen einer Dockerfile als Teil Ihrer Anwendungsquelle, die mit der Container-App erstellt und bereitgestellt wird
    • Hinweis: Die Dockerfile kann keine Linux-basierten Imageebenen haben.

Pack CLI

Das Pack CLI- wird vom Cloud Native Buildpacks-Projekt verwaltet und wird von dieser Aufgabe verwendet, um runnable Anwendungsimages für den Benutzer zu erstellen, wenn der Anwendungsquellcode bereitgestellt wird und keine zusätzliche Dockerfile bereitgestellt oder gefunden wird. Ein Builder- wurde von Oryx erstellt, um den für diese Aufgabe bereitgestellten Anwendungsquellcode zu übernehmen und ein Image zu erstellen, das dann an eine Imageregistrierung übertragen und in einer Container-App zum Erstellen und Ausführen der Anwendung verwendet werden kann.

Eine stabile Version der Pack CLI wird auf dem Azure Pipelines-Agent installiert, der die Aufgabe ausführt, und abhängig vom Basisbetriebssystem dieses Agents werden verschiedene Tools verwendet, um die Installation zu unterstützen:

  • Unter Windows-Läufern:
    • Eine Reihe von PowerShell-Befehlen wird ausgeführt, um Folgendes auszuführen:
      • Erstellt einen pack Ordner im temporären Ordner des Agents, wenn der ordner "pack" noch nicht vorhanden ist.
      • Lädt die CLI-.zip des Pakets in diesen pack Ordner herunter.
      • Entpackt den Inhalt aus diesem .zip und platziert sie im Ordner pack
      • Löscht die .zip
  • Unter Nicht-Windows-Läufern:
    • curl wird verwendet, um die .tgz mit der ausführbaren Datei pack abzurufen.
    • tar werden verwendet, um die .tgz zu entzippen und die pack ausführbare Datei in /usr/local/bin

Azure Container Registry

Eine Azure Container Registry- muss vorhanden sein, dass der Benutzer Containerimages per Push übertragen kann. Diese Aufgabe nutzt die Azure-Containerregistrierung, um entweder ein integriertes Runnable-Anwendungsimage zu übertragen und/oder eine Container-App bereitzustellen.

Der Name der Azure-Containerregistrierung ist über das Argument acrName erforderlich.

Der Benutzer kann auch Werte für die argumente acrUsername und acrPassword bereitstellen, die Aufrufe an die Azure Container Registry-Instanz authentifizieren. wenn nicht angegeben, wird ein Zugriffstoken über die Azure CLI generiert, die stattdessen die Anrufe authentifiziert.

Azure Container-App-Umgebung

Eine Azure Container App-Umgebung wird empfohlen, zuvor vom Benutzer erstellt worden zu sein, um die Leistung der Aufgabe zu verbessern. Wenn zuvor keine Umgebung erstellt wurde oder eine Umgebung in der Ressourcengruppe, die zum Hosten der erstellten Container-App verwendet wird, nicht gefunden werden kann, wird eine Umgebung als Teil des Befehls az containerapp up erstellt, was zusätzliche Zeit in Anspruch nehmen kann.

Beispiele

In den folgenden Beispielen wird die Verwendung der AzureContainerApps in verschiedenen Szenarien beschrieben.

Minimal – Buildanwendungsimage für Container-App

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rgerstellt. Die Container-App basiert auf einem Image, das aus dem bereitgestellten appSourcePath erstellt und an die bereitgestellte ACR-Instanz übertragen wurde. Ein Zugriffstoken wird generiert, um den Push an die bereitgestellte ACR-Instanz zu authentifizieren.

Minimal – Zuvor veröffentlichtes Image für Container-App verwenden

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    imageToDeploy: mcr.microsoft.com/<existing-image>:latest

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg erstellt, in der kein neues Imageerstellt wird, aber ein vorhandenes Image mit dem Namen mcr.microsoft.com/<existing-image>:latest wird für die Container-App verwendet.

Minimal – Verwenden der YAML-Konfigurationsdatei mit zuvor veröffentlichtem Image für Container-App

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    yamlConfigPath: simple-image-container-app.yaml

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg erstellt, in der kein neues Imageerstellt wird, aber ein vorhandenes Image mit dem Namen mcr.microsoft.com/<existing-image>:latest wird für die Container-App verwendet. Zusätzliche Eigenschaften zur Container-App werden aus der datei simple-image-container-app.yaml abgerufen und überschreiben alle zusätzlichen Werte, die der Aufgabe als Argumente bereitgestellt wurden, ohne resourceGroup.

Die simple-image-container-app.yaml Datei weist die folgende Struktur auf:

properties:
  managedEnvironmentId: /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.App/managedEnvironments/CONTAINER_APP_ENVIRONMENT
  configuration:
    ingress:
      external: true
      allowInsecure: false
      targetPort: 80
  template:
    containers:
      - image: mcr.microsoft.com/<existing-image>:latest
        name: mysampleimagecontainer

Die Werte für SUBSCRIPTION_ID, RESOURCE_GROUP und CONTAINER_APP_ENVIRONMENT müssen aktualisiert werden, um auf die vollständige Ressourcen-ID der vorhandenen vorhandenen Container-App-Umgebung zu verweisen, die von der Container-App verwendet wird.

Verwenden von ACR-Anmeldeinformationen zur Authentifizierung

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    acrUsername: $(ACR_USERNAME_SECRET)
    acrPassword: $(ACR_PASSWORD_SECRET)

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rgerstellt. Die Container-App basiert auf einem Image, das aus dem bereitgestellten appSourcePath erstellt und an die bereitgestellte ACR-Instanz übertragen wurde. Die bereitgestellten ACR-Anmeldeinformationen werden verwendet, um Aufrufe an die ACR-Instanz zu authentifizieren.

Bereitgestellter Container-App-Name

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    containerAppName: 'my-test-container-app'

Dadurch wird eine neue Container-App namens my-test-container-app in einem neuen Ressourcengruppennamen my-test-container-app-rgerstellt.

Bereitgestellte Ressourcengruppe

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    resourceGroup: 'my-test-rg'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer Ressourcengruppe namens my-test-rgerstellt. Wenn die ressourcengruppe my-test-rg nicht vorhanden ist, wird sie als Teil dieses Vorgangs erstellt.

Container-App-Name und Ressourcengruppe bereitgestellt

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    containerAppName: 'my-test-container-app'
    resourceGroup: 'my-test-rg'

Dadurch wird eine neue Container-App namens my-test-container-app in einer Ressourcengruppe namens my-test-rgerstellt. Wenn die ressourcengruppe my-test-rg nicht vorhanden ist, wird sie als Teil dieses Vorgangs erstellt.

Bereitgestellte Container-App-Umgebung

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    containerAppEnvironment: 'my-test-container-app-env'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg mit einer neuen Container-App-Umgebung namens my-test-container-app-enverstellt.

Bereitgestellter Laufzeitstapel

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    runtimeStack: 'dotnetcore:7.0'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg erstellt, in der das ausgeführte Anwendungsimage den .NET 7-Laufzeitstapel verwendet.

Dockerfile bereitgestellt

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    dockerfilePath: 'test.Dockerfile'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg erstellt, in der das runnable Anwendungsimage aus der test.Dockerfile Datei erstellt wurde, die im angegebenen Anwendungsquellpfadverzeichnis gefunden wurde.

Hinweis: Für Werte, die für dockerfilePathbereitgestellt werden, sollten keine Dateipräfixe eingeschlossen werden (z. B., ./test.Dockerfile sollten wie test.Dockerfileübergeben werden). Die bereitgestellten argumente appSourcePath und dockerfilePath werden innerhalb des Vorgangs verkettet.

Bild zum Erstellen bereitgestellt

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    appSourcePath: '$(System.DefaultWorkingDirectory)'
    acrName: 'mytestacr'
    imageToBuild: 'mytestacr.azurecr.io/app:latest'

Dadurch wird eine neue Container-App namens ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe mit dem Namen <container-app-name>-rg erstellt und an A mytestacr.azurecr.io/app:latestCR übertragen.

Anforderungen

Anforderung Beschreibung
Pipelinetypen YAML, Classic Build, Classic Release
Läuft auf Agent, DeploymentGroup
Anforderungen Nichts
Funktionen Dieser Vorgang erfüllt keine Anforderungen für nachfolgende Vorgänge im Auftrag.
Befehlseinschränkungen Jegliche
Settable-Variablen Jegliche
Agentversion 2.144.0 oder höher
Vorgangskategorie Aufstellen

Siehe auch