Freigeben über

AzureContainerApps@1: Azure Container Apps Deploy v1-Aufgabe

  • 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.

Eingaben

workingDirectory - Arbeitsverzeichnis
Eingabealias: cwd. string.

Aktuelles Arbeitsverzeichnis, in dem das Skript ausgeführt wird. „Leer“ ist der Stamm des Repositorys (Build) oder der Artefakte (Release), bei dem es sich um „$(System.DefaultWorkingDirectory)“ handelt.


appSourcePath - Anwendungsquellpfad
string.

Absoluter Pfad für den Runner des zu erstellenden Quellcodes. Falls 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 in ACR sind die acrName Aufgabeneingaben und appSourcePath 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. die Rolle Mitwirkender.


acrName - Azure Container Registry Name
string.

Der Name des Azure Container Registry, an den das ausgeführte Anwendungsimage gepusht wird.

Beim Pushen eines neuen Images in ACR sind die acrName Aufgabeneingaben und appSourcePath erforderlich.


acrUsername - Azure Container Registry Benutzername
string.

Der Benutzername, der zum Authentifizieren von Pushanforderungen bei der bereitgestellten Azure Contrainer Registry verwendet wird. Falls nicht angegeben, wird ein Zugriffstoken über "az acr login" generiert und für "docker login" bereitgestellt, um die Anforderungen zu authentifizieren.


acrPassword - kennwort Azure Container Registry
string.

Das Kennwort, das zum Authentifizieren von Pushanforderungen an die bereitgestellte Azure Contrainer Registry verwendet wird. Falls nicht angegeben, wird ein Zugriffstoken über "az acr login" generiert und für "docker login" bereitgestellt, um die Anforderungen zu authentifizieren.


dockerfilePath - Dockerfile-Pfad
string.

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


imageToBuild - Zu erstellende Docker-Image
string.

Der benutzerdefinierte Name des Images, das erstellt, per Push an ACR gepusht und von dieser Aufgabe in der Container-App bereitgestellt werden soll. Hinweis: Dieser Imagename sollte den ACR-Server enthalten. z. B. <acr-name>.azurecr.io/<repo>:<tag>. Wenn dieses Argument nicht angegeben wird, wird ein Standardimagename in Form von <acr-name>.azurecr.io/ado-task/container-app:<build-id>.<build-number>erstellt.


imageToDeploy - Docker-Image für die Bereitstellung
string.

Der Name des Images, das bereits an ACR gepusht wurde und von dieser Aufgabe in der Container-App bereitgestellt wird. Hinweis: Der Imagename 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 ermittelte) Wert verwendet. Wenn dieses Image in einem ACR-instance gefunden wird, für das die Authentifizierung zum Pullen erforderlich ist, kann das acrName Argument oder die acrUsername Argumente und acrPassword bereitgestellt werden, um Anforderungen an die ACR-instance zu authentifizieren.


containerAppName - Name der Azure Container-App
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 - Name der Azure-Ressourcengruppe
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 <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. Falls 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, an dem die Container-App lauscht. Falls nicht angegeben, lautet dieser Wert "80" für Python-Anwendungen 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, um vorhandene Werte zu löschen. Präfixwert mit "secretref:", um auf ein Geheimnis zu verweisen.


ingress - Eingangseinstellung
string.

Mögliche Optionen: extern, intern, deaktiviert. Wenn auf external festgelegt ist (Standardwert, falls beim Erstellen einer Container-App nicht angegeben), ist die Container-App je nach konfiguriertem Endpunkt der App-Umgebung über das Internet oder ein VNET sichtbar. Wenn auf internalfestgelegt ist, ist die Container-App nur in der App-Umgebung sichtbar. Wenn auf disabledfestgelegt ist, wird der Eingangseingang für diese Container-App deaktiviert und verfügt nicht über einen HTTP- oder TCP-Endpunkt.


yamlConfigPath - YAML-Konfigurationsdateipfad
string.

Vollständiger Pfad (auf dem ausführenden Azure Pipelines-Agent) zur YAML-Datei, die die Konfiguration der Container-App detailliert enthält.

Die resourceGroup -Eigenschaft in der YAML-Konfigurationsdatei wird nicht verwendet. Der Wert dafür stammt entweder aus dem für den resourceGroup Task bereitgestellten Argument oder vom Standardressourcengruppennamen, der von der Aufgabe generiert wird. Alle anderen In der YAML-Konfigurationsdatei bereitgestellten Eigenschaften überschreiben die als Argumente für diese Aufgabe bereitgestellten Werte. Wenn das Argument beispielsweise für die containerAppName 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. , imageToDeploy) werden weiterhin verwendet, appSourcePathum zuerst ein von der Container-App verwendetes Image zu erstellen und/oder zu pushen. In diesem Fall muss die angegebene YAML-Konfigurationsdatei auf das von imageToDeploy (oderimageToBuild) angegebene Image verweisen, je nach Szenario.

Beim Erstellen einer neuen Container-App werden alle In der YAML-Konfigurationsdatei aufgeführten Eigenschaften (außer 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 für die Container-App aktualisiert.

Derzeit unterstützt die YAML-Datei das Einrichten der Authentifizierung mit verwalteter Identität für die verwendete Containerregistrierung nicht. Weitere Informationen zu diesem Problem finden Sie in diesem GitHub-Problem.

In Fällen, in denen das yamlConfigPath Argument angegeben wird, wird die YAML-Datei an den entsprechenden az containerapp Befehl entweder oder übergeben.createupdate abhängig von Ihrem Szenario. Weitere Informationen zum beabsichtigten Verhalten, wenn die YAML-Konfigurationsdatei bereitgestellt wird, finden Sie in den Dokumenten, die für die entsprechenden Befehle verknüpft sind.

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


disableTelemetry - Deaktivieren von Telemetriedaten
boolean.

Wenn auf "true" festgelegt ist, werden von dieser Azure DevOps-Aufgabe keine Telemetriedaten erfasst. Wenn sie auf "false" festgelegt ist oder dieses Argument nicht angegeben wird, werden Telemetriedaten zum Erstellen und Bereitstellen der Container-App an Microsoft gesendet, das für diese Azure DevOps-Aufgabe vorgesehen ist.


Optionen für die Vorgangskontrolle

Alle Vorgänge verfügen zusätzlich zu ihren Eingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerungsoptionen und allgemeine Aufgabeneigenschaften.

Ausgabevariablen

Keine.

Hinweise

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

Die Aufgabe weist die folgenden zwei Verwendungsmuster auf.

  • Pushen eines Bilds in ACR : Beim Pushen eines neuen Images in ACR sind die acrName Aufgabeneingaben und appSourcePath erforderlich.
  • Bereitstellen eines zuvor gepushten Images : Beim Bereitstellen eines zuvor gepushten Images ist die imageToDeploy Aufgabeneingabe erforderlich. Wenn dieses Image in einem ACR-instance gefunden wird, für das die Authentifizierung zum Pullen erforderlich ist, kann das acrName Argument oder die acrUsername Argumente und acrPassword bereitgestellt werden, um Anforderungen an die ACR-instance zu authentifizieren.

Hinweis

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

Wenn in der bereitgestellten Anwendungsquelle kein Dockerfile 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 ausführungsfähiges Anwendungsimage zu erstellen.
  • Pusht dieses ausführungsfähige Anwendungsimage in die bereitgestellte 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 docker build von erstellt und die Container-App wird basierend auf diesem Image erstellt oder aktualisiert.

Wenn ein zuvor erstelltes Image bereits an die ACR-instance gepusht wurde und für 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 Agent ausführen, stellen Sie möglicherweise fest, dass diese Aufgabe mit den folgenden Betriebssystemen nicht erfolgreich ausgeführt werden kann:

  • macOS
    • Die von Microsoft bereitgestellten macOS-Runner werden nicht mit Docker installiert (weitere Informationen finden Sie hier); Daher kann diese Aufgabe keine docker Befehle ausführen, z. B. das Pushen der erstellten ausgeführten Anwendungsimages an ACR.
  • Windows
    • Auf den von Microsoft bereitgestellten Windows-Runnern ist Docker installiert, aber standardmäßig können Linux-basierte Images nicht heruntergefahren werden. Daher ist diese Aufgabe nicht in der Lage, den Oryx-Generator zu pullen, um aus der bereitgestellten Anwendungsquelle ausführende Anwendungsimages zu erstellen.

Weitere Informationen finden Sie im folgenden Abschnitt für Docker-Voraussetzungen .

Daten-/Telemetriesammlungshinweis

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

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

Wenn Sie die Datensammlung deaktivieren möchten, legen Sie das disableTelemetry Argument auf fest true.

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 Azure Pipelines über die Registerkarte Dienste im Abschnitt "Einstellungen" verknüpft werden. Fügen Sie das Azure-Abonnement hinzu, das in der Definition Erstellen 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 Endpunkttyp "Azure Resource Manager". 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 während der gesamten Ausführung der Aufgabe eine Vielzahl von Befehlen auszuführen. Weitere Informationen zum Installieren der Azure CLI auf dem Agent finden Sie in diesem Dokument. Wenn bereits ein Agent 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.

Docker

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

Darüber hinaus tritt bei Benutzern, die diese Aufgabe mit einem Windows-Agent ausführen, möglicherweise ein Problem auf, dass linuxbasierte Images nicht abgerufen werden können. Um dies zu beheben, besuchen Sie diese Website , oder suchen Sie die DockerCli.exe Datei auf Ihrem Agent (in der Program Files\Docker\Docker Regel im Ordner), und führen Sie aus.

& `.\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 imageToDeploy Argument, mit dem die Container-App bereitgestellt wird

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

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

pack CLI

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

Auf dem Azure Pipelines-Agent, der die Aufgabe ausführt, wird eine stabile Version der Pack-CLI installiert, und abhängig vom Basisbetriebssystem dieses Agents werden verschiedene Tools zur Unterstützung der Installation verwendet:

  • Unter Windows-Runnern:
    • Eine Reihe von PowerShell-Befehlen wird ausgeführt, um die folgenden Aktionen auszuführen:
      • Erstellt einen pack Ordner im temporären Ordner des Agents, wenn der pack Ordner noch nicht vorhanden ist.
      • Lädt die Pack-CLI .zip in diesen Ordner herunter pack .
      • Entpackt den Inhalt aus diesem .zip und platziert sie im pack Ordner.
      • Löscht die .zip
  • Bei Nicht-Windows-Runnern:
    • curl wird verwendet, um den pulldown zu verwenden, der .tgz die pack ausführbare Datei enthält.
    • tar wird verwendet, um das .tgz zu entzippen und die pack ausführbare Datei in zu platzieren. /usr/local/bin

Azure Container Registry

Es muss eine Azure Container Registry vorhanden sein, an die der Benutzer Containerimages pushen kann. Diese Aufgabe nutzt die Azure Container Registry, um entweder ein erstelltes ausgeführtes Anwendungsimage per Push in eine Container-App zu übertragen und/oder eine Container-App bereitzustellen.

Der Name des Azure Container Registry wird über das acrName Argument benötigt.

Der Benutzer kann auch Werte für die acrUsername Argumente und acrPassword angeben, die Aufrufe des Azure Container Registry instance authentifizieren. Wenn dies nicht angegeben ist, wird über die Azure CLI ein Zugriffstoken generiert, das die Aufrufe stattdessen authentifiziert.

Azure Container App-Umgebung

Es wird empfohlen, dass der Benutzer zuvor eine Azure Container App-Umgebung erstellt hat, um die Leistung der Aufgabe zu verbessern. Wenn zuvor keine Umgebung erstellt wurde oder keine Umgebung in der Ressourcengruppe gefunden werden kann, die zum Hosten der erstellten Container-App verwendet wird, wird von als Teil des az containerapp up Befehls eine Umgebung erstellt, was möglicherweise zusätzliche Zeit in Anspruch nehmen kann.

Beispiele

In den folgenden Beispielen wird beschrieben, wie sie AzureContainerApps in verschiedenen Szenarien verwendet wird.

Minimal: Erstellen eines Anwendungsimages 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-instance gepusht wurde. Ein Zugriffstoken wird generiert, um den Pushvorgang an die bereitgestellte ACR-instance zu authentifizieren.

Minimal: Verwenden eines zuvor veröffentlichten Images für Container-App

steps:
- task: AzureContainerApps@1
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    imageToDeploy: mcr.microsoft.com/azuredocs/containerapps-helloworld: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 Image erstellt wird, aber ein vorhandenes Image namens mcr.microsoft.com/azuredocs/containerapps-helloworld:latest für die Container-App verwendet wird.

Minimal: Verwenden der YAML-Konfigurationsdatei mit dem zuvor veröffentlichten 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 Image erstellt wird, aber ein vorhandenes Image namens mcr.microsoft.com/azuredocs/containerapps-helloworld:latest für die Container-App verwendet wird. Zusätzliche Eigenschaften zur Container-App werden aus der simple-image-container-app.yaml Datei abgerufen und überschreiben alle zusätzlichen Werte, die der Aufgabe als Argumente mit Ausnahme resourceGroupvon bereitgestellt wurden.

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

properties:
  managedEnvironmentId: /subscriptions/SUBSCRIPTION_ID/resourceGroup/RESOURCE_GROUP/providers/Microsoft.App/managedEnvironments/CONTAINER_APP_ENVIRONMENT
  configuration:
    ingress:
      external: true
      allowInsecure: false
      targetPort: 80
  template:
    containers:
      - image: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest
        name: mysampleimagecontainer

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

Verwenden von ACR-Anmeldeinformationen zum Authentifizieren

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-instance gepusht wurde. Die bereitgestellten ACR-Anmeldeinformationen werden verwendet, um Aufrufe der ACR-instance zu authentifizieren.

Container-App-Name angegeben

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 my-test-rg Ressourcengruppe nicht vorhanden ist, wird sie als Teil dieser Aufgabe 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 my-test-rg Ressourcengruppe nicht vorhanden ist, wird sie als Teil dieser Aufgabe 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 ausführende Anwendungsimage den .NET 7-Laufzeitstapel verwendet.

Bereitgestellte Dockerfile

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 mit dem Namen ado-task-app-<build-id>-<build-number> in einer neuen Ressourcengruppe namens <container-app-name>-rg erstellt, in der das ausführungsfähige Anwendungsimage aus der test.Dockerfile Datei im angegebenen Quellpfadverzeichnis der Anwendung erstellt wurde.

Hinweis: Für werte, die für dockerfilePathbereitgestellt werden, sollten keine Dateipräfixe eingeschlossen werden (z../test.Dockerfile B. sollten nur test.Dockerfileals übergeben werden). Die bereitgestellten appSourcePath Argumente und dockerfilePath werden innerhalb der Aufgabe verkettet.

Bereitgestelltes Image zum Erstellen

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 namens <container-app-name>-rg erstellt, in der das an ACR erstellte und gepushte Image namens heißt mytestacr.azurecr.io/app:latest.

Anforderungen

Anforderung BESCHREIBUNG
Pipelinetypen YAML, Klassischer Build, klassische Version
Wird ausgeführt auf Agent, DeploymentGroup
Forderungen Keine
Capabilities Diese Aufgabe erfüllt keine Anforderungen an nachfolgende Aufgaben im Auftrag.
Befehlseinschränkungen Any
Einstellbare Variablen Any
Agent-Version 2.144.0 oder höher
Aufgabenkategorie Bereitstellen

Weitere Informationen