Partage via

AzureContainerApps@0 - Tâche De déploiement d’Azure Container Apps v0

  • Article

Une tâche Azure DevOps pour créer et déployer Azure Container Apps.

Syntax

# Azure Container Apps Deploy v0
# An Azure DevOps Task to build and deploy Azure Container Apps.
- task: AzureContainerApps@0
  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.

Entrées

workingDirectory - Répertoire de travail
Alias d’entrée : cwd. string.

Répertoire de travail actuel où le script est exécuté. Empty est la racine du référentiel (build) ou des artefacts (mise en production), à savoir $(System.DefaultWorkingDirectory).


appSourcePath - Chemin d’accès source de l’application
string.

Chemin d’accès absolu sur l’exécuteur du code d’application source à générer. S’il n’est pas fourni, l’argument « imageToDeploy » doit être fourni pour garantir que l’application conteneur dispose d’une image à référencer.

Lorsque vous envoyez une nouvelle image à ACR, les entrées de acrName tâche et appSourcePath sont requises.


azureSubscription - Connexion Azure Resource Manager
Alias d’entrée : connectedServiceNameARM. string. Obligatoire.

Spécifiez une connexion de service Azure Resource Manager pour le déploiement. Cette connexion de service doit être liée à l’abonnement Azure de l’utilisateur où l’application conteneur sera créée/mise à jour. Cette connexion de service doit disposer des autorisations appropriées pour apporter ces modifications au sein de l’abonnement, par exemple le rôle Contributeur.


acrName - Azure Container Registry nom
string.

Nom de l’Azure Container Registry vers laquelle l’image d’application exécutable sera envoyée.

Lorsque vous envoyez une nouvelle image à ACR, les entrées de acrName tâche et appSourcePath sont requises.


acrUsername - nom d’utilisateur Azure Container Registry
string.

Nom d’utilisateur utilisé pour authentifier les demandes push auprès d’Azure Contrainer Registry fourni. S’il n’est pas fourni, un jeton d’accès est généré via « az acr login » et fourni à « docker login » pour authentifier les demandes.


acrPassword - mot de passe Azure Container Registry
string.

Mot de passe utilisé pour authentifier les demandes push auprès d’Azure Contrainer Registry fourni. S’il n’est pas fourni, un jeton d’accès est généré via « az acr login » et fourni à « docker login » pour authentifier les demandes.


dockerfilePath - Chemin d’accès dockerfile
string.

Chemin d’accès relatif (_without préfixes de fichier (voir les exemples suivants) au Dockerfile dans la source d’application fournie qui doit être utilisé pour générer l’image qui est ensuite envoyée à ACR et déployée sur l’application conteneur. Si elle n’est pas fournie, cette tâche case activée s’il existe un fichier nommé « Dockerfile » à la racine de la source d’application fournie et l’utiliser pour générer l’image. Sinon, le Générateur Oryx++ sera utilisé pour créer l’image.


imageToBuild - Image Docker à générer
string.

Nom personnalisé de l’image qui doit être générée, envoyée à ACR et déployée dans l’application conteneur par cette tâche. Remarque : ce nom d’image doit inclure le serveur ACR ; par exemple, <acr-name>.azurecr.io/<repo>:<tag>. Si cet argument n’est pas fourni, un nom d’image par défaut est construit sous la forme .<acr-name>.azurecr.io/ado-task/container-app:<build-id>.<build-number>


imageToDeploy - Image Docker à déployer
string.

Nom de l’image qui a déjà été envoyée à ACR et qui sera déployée dans l’application conteneur par cette tâche. Remarque : le nom de l’image doit inclure le serveur ACR ; par exemple, <acr-name>.azurecr.io/<repo>:<tag>. Si cet argument n’est pas fourni, la valeur fournie (ou déterminée) pour l’argument « imageToBuild » sera utilisée. Si cette image se trouve dans un instance ACR qui nécessite une authentification pour l’extraction, l’argument acrName ou les acrUsername arguments et acrPassword peuvent être fournis pour authentifier les demandes adressées au instance ACR.


containerAppName - Nom de l’application conteneur Azure
string.

Nom de l’application conteneur Azure qui sera créée ou mise à jour. Si elle n’est pas fournie, cette valeur se présente sous la forme .ado-task-app-<build-id>-<build-number>


resourceGroup - Nom du groupe de ressources Azure
string.

Groupe de ressources dans lequel l’application de conteneur Azure sera créée (ou dans lequel il existe actuellement). Si elle n’est pas fournie, cette valeur se présente sous la forme .<container-app-name>-rg


containerAppEnvironment - Environnement Azure Container App
string.

Nom de l’environnement Azure Container App à utiliser avec l’application. S’il n’est pas fourni, un environnement existant dans le groupe de ressources de l’application conteneur sera utilisé. Sinon, un environnement sera créé au format <container-app-name>-env.


runtimeStack - Pile du runtime d’application
string.

Pile de versions de plateforme utilisée dans l’image d’application exécutable finale déployée sur l’application conteneur. La valeur doit être fournie dans la formation <platform>:<version>. Si elle n’est pas fournie, cette valeur est déterminée par Oryx en fonction du contenu de l’application fournie. Reportez-vous à ce document pour plus d’informations sur les piles d’exécution prises en charge pour Oryx.


targetPort - Port cible de l’application
string.

Port cible sur lequel l’application conteneur va écouter. Si elle n’est pas fournie, cette valeur est « 80 » pour les applications Python et « 8080 » pour toutes les autres plateformes prises en charge.


location - Emplacement de l’application conteneur
string.

Emplacement dans lequel l’application conteneur (et d’autres ressources créées) sera déployée.


environmentVariables - Variables d’environnement
string.

Liste de variables d’environnement pour le conteneur. Valeurs séparées par l’espace au format « key=value ». Chaîne vide pour effacer les valeurs existantes. Préfixez la valeur avec « secretref : » pour référencer un secret.


ingress - Paramètre d’entrée
string.

Options possibles : externe, interne, désactivée. Si la valeur est définie external sur (valeur par défaut si elle n’est pas fournie lors de la création d’une application conteneur), l’application conteneur est visible à partir d’Internet ou d’un réseau virtuel, en fonction du point de terminaison de l’environnement d’application configuré. Si la valeur est définie internalsur , l’application conteneur est visible à partir de l’environnement d’application uniquement. Si la valeur est définie sur disabled, l’entrée est désactivée pour cette application conteneur et n’a pas de point de terminaison HTTP ou TCP.


yamlConfigPath - Chemin du fichier de configuration YAML
string.

Chemin complet (sur l’agent Azure Pipelines en cours d’exécution) vers le fichier YAML détaillant la configuration de l’application conteneur.

La resourceGroup propriété dans le fichier de configuration YAML ne sera pas utilisée ; la valeur de celle-ci provient de l’argument resourceGroup fourni à la tâche ou du nom du groupe de ressources par défaut généré par la tâche. Toutes les autres propriétés fournies dans le fichier de configuration YAML remplacent les valeurs fournies en tant qu’arguments pour cette tâche ; par exemple, si l’argument containerAppName est fourni à la tâche et que la name propriété est définie dans le fichier de configuration YAML, la name propriété dans le fichier YAML sera utilisée lors de la création ou de la mise à jour de l’application conteneur.

Les arguments source de l’image et de l’application (par exemple, appSourcePath, imageToDeploy) seront toujours utilisés pour générer et/ou envoyer (push) une image utilisée par l’application conteneur ; dans ce cas, le fichier de configuration YAML fourni devra référencer l’image spécifiée par imageToDeploy (ou imageToBuild, selon votre scénario).

Lors de la création d’une application conteneur, toutes les propriétés répertoriées dans le fichier de configuration YAML (sauf resourceGroup comme mentionné ci-dessus) sont définies lors de la création de l’application conteneur. Lors de la mise à jour d’une application conteneur existante, seules les propriétés répertoriées dans le fichier sont mises à jour sur l’application conteneur.

Actuellement, le fichier YAML ne prend pas en charge la configuration de l’authentification d’identité managée pour le registre de conteneurs utilisé ; Pour plus d’informations sur ce problème, consultez ce problème GitHub.

Dans les cas où l’argument yamlConfigPath est fourni, le fichier YAML est passé à la commande correspondante az containerapp , soit create ouupdate selon votre scénario. Pour plus d’informations sur le comportement prévu lorsque le fichier de configuration YAML est fourni, consultez les documents liés pour les commandes correspondantes.

Pour plus d’informations sur la structure du fichier de configuration YAML, visitez ce site.


disableTelemetry - Désactiver la télémétrie
boolean.

Si la valeur est « true », cette tâche Azure DevOps ne collecte aucune télémétrie. Si la valeur est « false », ou si cet argument n’est pas fourni, les données de télémétrie sont envoyées à Microsoft concernant le scénario de génération et de déploiement d’application conteneur ciblé par cette tâche Azure DevOps.


Options de contrôle de la tâche

Toutes les tâches ont des options de contrôle en plus de leurs entrées de tâches. Pour plus d’informations, consultez Options de contrôle et propriétés de tâche courantes.

Variables de sortie

Aucun.

Notes

Cette tâche Azure Pipelines permet aux utilisateurs de déployer facilement leur source d’application sur une application conteneur Azure dans leur flux de travail Azure Pipelines en fournissant une image créée précédemment, un Dockerfile à partir duquel une image peut être générée ou en utilisant un générateur pour créer une image d’application exécutable pour l’utilisateur.

La tâche présente les deux modèles d’utilisation suivants.

  • Envoi push d’une image vers ACR : lors de l’envoi push d’une nouvelle image vers ACR, les acrName entrées de tâche et appSourcePath sont requises.
  • Déploiement d’une image précédemment poussée : lors du déploiement d’une image précédemment poussée, l’entrée de tâche imageToDeploy est requise. Si cette image se trouve dans un instance ACR qui nécessite une authentification pour l’extraction, l’argument acrName ou les acrUsername arguments et acrPassword peuvent être fournis pour authentifier les demandes adressées au instance ACR.

Notes

Bien qu’aucune entrée de tâche ne soit officiellement marquée comme « obligatoire » dans les métadonnées de cette tâche, certaines entrées devront être fournies pour que cette tâche s’exécute correctement à l’aide de l’un des deux main pattenrs d’utilisation.

Si aucun dockerfile n’est trouvé ou fourni dans la source d’application fournie, cette tâche effectue les étapes suivantes :

  • Utilise Le Générateur Oryx++ pour générer la source de l’application à l’aide d’Oryx pour produire une image d’application exécutable
  • Envoie (push) cette image d’application exécutable vers le Azure Container Registry fourni
  • Crée ou met à jour une application conteneur basée sur cette image

Si un dockerfile est trouvé ou découvert dans la source de l’application, le générateur ne sera pas utilisé et l’image sera générée avec un appel à docker build et l’application conteneur sera créée ou mise à jour en fonction de cette image.

Si une image créée précédemment a déjà été envoyée à l’instance ACR et qu’elle est fournie à cette tâche, aucune source d’application n’est requise et l’image sera utilisée lors de la création ou de la mise à jour de l’application conteneur.

Exécution de cette tâche sur des agents hébergés par Microsoft

Si vous exécutez cette tâche sur un agent hébergé par Microsoft, vous constaterez peut-être que cette tâche ne peut pas s’exécuter correctement avec les systèmes d’exploitation suivants :

  • macOS
    • Les exécuteurs macOS fournis par Microsoft ne sont pas installés avec Docker (plus d’informations ici) ; par conséquent, cette tâche n’est pas en mesure d’exécuter docker des commandes, telles que l’envoi (push) des images d’application exécutables générées vers ACR.
  • Windows
    • Les exécuteurs Windows fournis par Microsoft sont fournis avec Docker installé, mais par défaut, les images basées sur Linux ne peuvent pas être extraites vers le bas ; par conséquent, cette tâche ne peut pas extraire le générateur Oryx pour créer des images d’application exécutables à partir de la source d’application fournie.

Pour plus d’informations, consultez la section relative aux prérequis Docker ci-dessous.

Avis de collecte de données/télémétrie

Par défaut, cette tâche Azure DevOps collecte les données suivantes pour Microsoft :

  • Scénario de génération et de déploiement d’application conteneur ciblé par l’utilisateur
    • c’est-à-dire, utilisé le Générateur Oryx++, utilisé un Fichier Dockerfile fourni/trouvé, ou fourni une image précédemment générée
    • Remarque : le nom de l’image n’est pas collecté
  • Durée de traitement de la tâche, en millisecondes
  • Résultat de la tâche
    • c’est-à-dire réussi ou échoué
  • Si le Générateur Oryx++ est utilisé, événements et métriques relatifs à la génération de l’application fournie à l’aide d’Oryx

Si vous souhaitez désactiver la collecte de données, définissez l’argument disableTelemetry sur true.

Prérequis

Avant d’exécuter cette tâche, les ressources Azure et une connexion au service Azure DevOps sont requises ou facultatives en fonction des arguments fournis à cette tâche.

Connexion au service Azure DevOps

Pour effectuer un déploiement sur Azure, un abonnement Azure doit être lié à Team Foundation Server ou à Azure Pipelines à l’aide de l’onglet Services de la section Paramètres. Ajoutez l’abonnement Azure à utiliser dans la définition Générer ou Release Management en ouvrant l’écran Administration de compte (icône d’engrenage en haut à droite de l’écran), puis cliquez sur l’onglet Services.

Créez le point de terminaison de service ARM et utilisez le type de point de terminaison « Azure Resource Manager ». Pour plus d’informations sur la création de connexions de service, suivez ce document.

Azure CLI

Cette tâche nécessite qu’Azure CLI soit installé sur l’agent Azure Pipelines pour exécuter diverses commandes tout au long de l’exécution de la tâche. Pour plus d’informations sur l’installation d’Azure CLI sur l’agent, consultez ce document. Si un agent est déjà en cours d’exécution sur l’ordinateur sur lequel Azure CLI est installé, veillez à redémarrer l’agent afin que toutes les variables d’environnement pertinentes soient mises à jour.

Docker

Cette tâche nécessite que Docker soit installé sur l’agent Azure Pipelines pour envoyer des images au Azure Container Registry fourni. Pour plus d’informations sur l’installation de Docker sur l’agent, consultez ce document.

En outre, les utilisateurs qui exécutent cette tâche avec un agent Windows peuvent rencontrer un problème de ne pas pouvoir extraire des images linux ; pour résoudre ce problème, visitez ce site ou trouvez le DockerCli.exe fichier sur votre agent (généralement dans le Program Files\Docker\Docker dossier) et exécutez

& `.\DockerCli.exe` -SwitchDaemon

Si Docker n’est pas installé sur l’agent exécutant cette tâche, le ou les scénarios suivants sont toujours activés :

  • Fourniture d’une image précédemment générée à l’argument imageToDeploy avec lequel l’application conteneur déploie

Si Docker se trouve sur l’agent, mais ne peut pas fonctionner avec des images Linux, les scénarios suivants sont toujours activés :

  • Fourniture d’une image précédemment générée à l’argument imageToDeploy avec lequel l’application conteneur déploie
  • Fournir un Dockerfile dans le cadre de votre source d’application qui sera généré et déployé avec l’application conteneur
    • Remarque : le ne peut pas avoir de Dockerfile couches d’image linux

pack CLI

L’interface CLI de pack est gérée par le projet Cloud Native Buildpacks et est utilisée par cette tâche pour créer des images d’application exécutables pour l’utilisateur lorsque le code source de l’application est fourni et qu’aucun fichier Dockerfile supplémentaire n’est fourni ou trouvé. Un générateur a été créé par Oryx pour prendre en charge le code source de l’application fourni à cette tâche et produire une image qui pouvait ensuite être envoyée à un registre d’images et utilisée dans une application conteneur pour générer et exécuter l’application.

Une version stable de l’interface CLI du pack est installée sur l’agent Azure Pipelines exécutant la tâche. En fonction du système d’exploitation de base de cet agent, différents outils seront utilisés pour faciliter l’installation :

  • Sur les exécuteurs Windows :
    • Un ensemble de commandes PowerShell est exécuté pour effectuer les opérations suivantes :
      • Crée un pack dossier dans le dossier temporaire de l’agent, si le pack dossier n’existe pas encore
      • Télécharge l’interface CLI .zip du pack dans ce pack dossier
      • Décompresse le contenu de ce .zip fichier et le place dans le pack dossier
      • Supprime le .zip
  • Sur les exécuteurs non Windows :
    • curlsera utilisé pour extraire le .tgz contenant l’exécutable pack
    • tar sera utilisé pour décompresser et .tgz placer l’exécutable pack dans /usr/local/bin

Azure Container Registry

Un Azure Container Registry doit exister vers lequel l’utilisateur peut envoyer (push) des images conteneur. Cette tâche tire parti de la Azure Container Registry pour envoyer (push) une image d’application exécutable générée vers et/ou déployer une application conteneur à partir de.

Le nom du Azure Container Registry est requis via l’argument acrName .

L’utilisateur peut également fournir des valeurs pour les acrUsername arguments et acrPassword qui authentifient les appels à l’Azure Container Registry instance ; s’il n’est pas fourni, un jeton d’accès est généré via Azure CLI qui authentifiera les appels à la place.

Environnement Azure Container App

Un environnement Azure Container App est recommandé d’avoir été créé précédemment par l’utilisateur pour améliorer les performances de la tâche. Si aucun environnement n’a été créé auparavant ou si un environnement est introuvable dans le groupe de ressources utilisé pour héberger l’application conteneur créée, un environnement est créé par dans le cadre de la az containerapp up commande, ce qui peut prendre du temps.

Exemples

Les exemples suivants décrivent comment utiliser le AzureContainerApps dans différents scénarios.

Minimal - Générer une image d’application pour l’application conteneur

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg. L’application conteneur sera basée sur une image qui a été créée à partir du fourni appSourcePath et envoyée à la instance ACR fournie. Un jeton d’accès sera généré pour authentifier le push sur le instance ACR fourni.

Minimal - Utiliser une image publiée précédemment pour Container App

steps:
- task: AzureContainerApps@0
  displayName: Build and deploy Container App
  inputs:
    connectedServiceNameARM: 'azure-subscription-service-connection'
    imageToDeploy: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg où aucune nouvelle image n’est générée, mais une image existante nommée mcr.microsoft.com/azuredocs/containerapps-helloworld:latest sera utilisée pour l’application conteneur.

Minimal - Utiliser le fichier de configuration YAML avec une image publiée précédemment pour Container App

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg où aucune nouvelle image n’est générée, mais une image existante nommée mcr.microsoft.com/azuredocs/containerapps-helloworld:latest sera utilisée pour l’application conteneur. Les propriétés supplémentaires relatives à l’application conteneur sont extraites du simple-image-container-app.yaml fichier et remplacent toutes les valeurs supplémentaires qui auraient été fournies à la tâche en tant qu’arguments à l’exclusion resourceGroupde .

Le simple-image-container-app.yaml fichier a la structure suivante :

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

Les valeurs de SUBSCRIPTION_IDet RESOURCE_GROUPCONTAINER_APP_ENVIRONMENT doivent être mises à jour pour pointer vers l’ID de ressource complet de l’environnement Container App existant que l’application conteneur utilisera.

Utilisation des informations d’identification ACR pour l’authentification

steps:
- task: AzureContainerApps@0
  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)

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg. L’application conteneur sera basée sur une image qui a été créée à partir du fourni appSourcePath et envoyée à la instance ACR fournie. Les informations d’identification ACR fournies seront utilisées pour authentifier les appels à l’instance ACR.

Nom de l’application conteneur fourni

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

Cela crée une application conteneur nommée my-test-container-app dans un nouveau nom my-test-container-app-rgde groupe de ressources .

Groupe de ressources fourni

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un groupe de ressources nommé my-test-rg. Si le my-test-rg groupe de ressources n’existe pas, il sera créé dans le cadre de cette tâche.

Nom de l’application conteneur et groupe de ressources fournis

steps:
- task: AzureContainerApps@0
  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'

Cela crée une application conteneur nommée my-test-container-app dans un groupe de ressources nommé my-test-rg. Si le my-test-rg groupe de ressources n’existe pas, il sera créé dans le cadre de cette tâche.

Environnement d’application conteneur fourni

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg avec un nouvel environnement Container App nommé my-test-container-app-env.

Pile d’exécution fournie

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg où l’image d’application exécutable utilise la pile d’exécution .NET 7.

Dockerfile fourni

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg où l’image d’application exécutable a été créée à partir du fichier trouvé dans le test.Dockerfile répertoire de chemin d’accès source de l’application fourni.

Remarque : pour les valeurs fournies à dockerfilePath, aucun préfixe de fichier ne doit être inclus (par exemple, ./test.Dockerfile doit être passé en tant que juste test.Dockerfile). Les arguments et dockerfilePath fournis appSourcePath seront concaténés à l’intérieur de la tâche.

Image à générer fournie

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

Cela crée une application conteneur nommée ado-task-app-<build-id>-<build-number> dans un nouveau groupe de ressources nommé <container-app-name>-rg où l’image générée et envoyée à ACR est nommée mytestacr.azurecr.io/app:latest.

Configuration requise

Condition requise Description
Types de pipelines YAML, build classique, version classique
S’exécute sur Agent, DeploymentGroup
Demandes None
Capabilities Cette tâche ne répond à aucune demande pour les tâches suivantes dans le travail.
Restrictions de commandes Quelconque
Variables settables Quelconque
Version de l’agent 2.144.0 ou version ultérieure
Catégorie de la tâche Déployer

Voir aussi