Choisir un workflow de génération et de déploiement de conteneur

Azure Developer CLI (azd) peut générer, publier et déployer des images conteneur sur plusieurs services d’hébergement Azure. Un flux de travail de conteneur combine une cible d’hébergement avec un emplacement de build et une approche de publication. La meilleure combinaison dépend de votre application, de l’outil disponible de votre équipe et de la façon dont vous promouvez les images entre les environnements.

Utilisez cet article pour faire correspondre ces choix à vos besoins. Il compare les décisions suivantes :

  • Quel service Azure héberge votre conteneur.
  • Que azd l’image soit générée localement, la génère à distance dans Azure Container Registry (ACR) ou utilise une image existante.
  • Si azd publie et déploie l’image ensemble ou en deux étapes distinctes.

L’article compare ces services d’hébergement à usage général :

Commencez par comparer les cibles d’hébergement et les options de génération d’image. Une fois ces choix compris, utilisez-les pour identifier un flux de travail candidat dans la section Comparer les flux de travail de déploiement de conteneurs .

Comparer les cibles d’hébergement de conteneurs

La propriété host dans azure.yaml identifie le service Azure vers lequel azd déploie votre conteneur. Choisissez l’hôte indépendamment de l’emplacement de génération de l’image.

Valeur de l’hôte cible d’hébergement Azure Flux de travail de conteneur Considérations
containerapp Jobs Azure Container Apps et Container Apps Générez à partir d’un projet et d’un fichier Dockerfile, ou déployez une image prédéfinie. Prend en charge les variables d’environnement au niveau du service et les stratégies de déploiement spécifiques à Container Apps. Utilisez la même valeur d’hôte pour les tâches Container Apps.
appservice Application web Linux pour conteneurs sur Azure App Service Générez à partir d’un projet et d’un fichier Dockerfile, ou déployez une image prédéfinie. Votre infrastructure doit provisionner un site prêt pour les conteneurs Linux et configurer l’accès d’identité managée à ACR. azd deploy met à jour uniquement la référence d’image.
aks Azure Kubernetes Service Générez une image et déployez des manifestes Kubernetes, des graphiques Helm ou des configurations Kustomize. Fournit le plus de contrôle, mais vous oblige à gérer le cluster et la configuration Kubernetes. L’utilisation de Helm ou de Kustomize avec azd exige l’activation des flags de fonctionnalité alpha.

Les hôtes azure.ai.agent et ai.endpoint prennent également en charge la configuration de Docker pour les scénarios spécialisés Microsoft Foundry. Pour ces charges de travail, consultez Déployer vers les points de terminaison en ligne de Microsoft Foundry et l’extension d’agent Microsoft Foundry.

Comparer les options de génération d’images

La définition de service détermine si azd une image est générée ou commence par une image existante.

Option de création Configuration nécessaire Où la compilation est exécutée Moteur de conteneur local Idéal pour
Compilation locale project et, éventuellement, docker Votre environnement de développement ou votre exécuteur CI Obligatoire Itérations de développement rapides et environnements de génération qui fournissent déjà Docker ou Podman.
Build distante ACR project et docker.remoteBuild: true Azure Container Registry (Service d'enregistrement de conteneurs Azure) Pas nécessaire, sauf si azd bascule après l’échec d’une build distante Des compilations et des environnements cohérents dans le cloud, sans moteur de conteneurs local. Le flux de travail de génération à distance documenté cible Azure Container Apps.
Image existante gérée par azd image Pas de build source Peut être nécessaire pour les opérations de cycle de vie des images Images qui existent déjà localement ou dans un registre et qui azd peuvent extraire, baliser et envoyer (push).
Transfert direct d’image distante image et docker.imagePassthrough: true Pas de build Non requis Images distantes entièrement qualifiées que la ressource hôte doit utiliser telles quelles.

Gardez ces différences conceptuelles à l’esprit lorsque vous lisez les articles de configuration par option :

  • Une image prédéfinie utilise la propriété image au lieu de project, et azd peut toujours la récupérer, la taguer et la pousser.
  • Une génération à distance ACR se rabat sur une génération locale avec Docker ou Podman lorsque la génération à distance échoue et qu’un moteur de conteneurs pris en charge est disponible.
  • Le transfert direct d’image nécessite une référence complète d’image distante incluant un registre, ne peut pas être combiné avec remoteBuild et ne prend pas en charge les options azd publish --to ou azd publish --from-package, car azd ne gère pas l’image.

Pour obtenir la configuration complète de chaque option, consultez la prise en charge des builds distantes avec Azure Container Registry, Utiliser des registres de conteneurs tiers, des déploiements de conteneurs App Service avec Azure CLI développeur et le docker schéma.

Comparer les flux de travail de déploiement de conteneurs

Après avoir comparé les cibles d’hébergement dans Comparer les cibles d’hébergement de conteneur et les options de génération dans Comparer les options de génération d’image, utilisez le tableau suivant pour identifier les flux de travail les plus probables pour vos besoins.

Si vous devez le faire Commencez par Pourquoi
Déployer une application conteneurisée sur une plateforme serverless Azure Container Apps avec génération locale Ce flux de travail génère et déploie un projet dockerfile dans un flux de travail de développement.
Générer sans installer Docker ou Podman localement Azure Container Apps avec une build à distance ACR ACR génère l’image à partir de votre projet et de votre Dockerfile dans Azure.
Déployer une image produite par un autre système de génération Azure Container Apps ou App Service avec une image prédéfinie La image propriété identifie l’image existante au lieu du code source à générer.
Réutiliser une image distante sans la télécharger, l’étiqueter ou la pousser Azure Container Apps avec transfert direct d’images de conteneur azd transmet directement la référence complète de l’image à la ressource hôte.
Héberger une application web traditionnelle en tant que conteneur Linux Application web pour conteneurs sur Azure App Service App Service fournit une plateforme d’hébergement web intégrée tandis que votre infrastructure contrôle la configuration du site prêt pour le conteneur.
Contrôler les manifestes Kubernetes et la configuration du cluster Azure Kubernetes Service (AKS) azd peut générer et publier l’image, puis déployer des manifestes Kubernetes, des graphiques Helm ou des configurations Kustomize.
Créer une seule fois et promouvoir la même image à travers les environnements azd publish, suivi de azd deploy --from-package La publication et le déploiement sont séparés, de sorte que chaque environnement reçoit la même image.

Chaque ligne combine les choix d’hébergement de Comparer les cibles d’hébergement de conteneurs et les choix de génération d’image de Comparer les options de génération d’image comme point de départ. Configurez votre choix dans azure.yaml, et laissez vos fichiers Bicep ou Terraform provisionner les ressources d’hébergement et de Registre correspondantes.

Une définition de service minimale définit le host, la source de construction et le Dockerfile :

services:
  api:
    project: ./src/api
    language: docker
    host: containerapp
    docker:
      path: ./Dockerfile

Pour adapter cette définition à un autre hôte, modifiez la host valeur et suivez le contrat de configuration par hôte :

Comparer les commandes de publication et de déploiement

Après avoir choisi un hôte et une option de génération, sélectionnez s’il faut combiner ou séparer la publication et le déploiement d’images.

Command Actions d’image action sur une ressource Azure À utiliser quand
azd up Générer et envoyer (push) Provisionner et déployer Vous souhaitez créer ou mettre à jour l’environnement complet et déployer l’application dans un flux de travail.
azd deploy Générer et envoyer (push) Déployer L’infrastructure existe déjà et vous souhaitez déployer des modifications d’application.
azd publish Générer et envoyer (push) None Vous souhaitez créer un artefact de Registre sans le déployer. azd publish prend en charge les services Container Apps et AKS.
azd publish --from-package <image> Pousser une image locale existante None Un autre processus a généré l’image et vous souhaitez azd la publier.
azd deploy --from-package <image> None Déployer Vous souhaitez déployer une image spécifique sans la reconstruire.

Par exemple, publiez une image avec version et déployez cette même image dans un autre environnement :

azd publish api --to myregistry.azurecr.io/my-api:v1.0.0
azd env select production
azd deploy api --from-package myregistry.azurecr.io/my-api:v1.0.0

Ce flux de travail empêche les différences qui peuvent se produire lorsque vous régénérez une image pour chaque environnement. Pour un workflow complet de promotion, consultez les workflows de publication d’Azure Developer CLI.

Contenu connexe

  • Dernière mise à jour :