Déploiement continu avec des conteneurs personnalisés dans Azure App Service

  • Article

Dans ce didacticiel, vous allez configurer le déploiement continu d’une image conteneur personnalisée à partir des référentiels Azure Container Registry managés ou du Docker Hub.

1. Accéder au centre de déploiement

Dans le portail Azure, accédez à la page de gestion de votre application App Service.

Dans le menu de gauche, cliquez sur Centre de déploiement>Paramètres.

2. Choisir une source de déploiement

Choisir la source de déploiement dépend de votre scénario :

  • Container Registry installe CI/CD entre votre registre de conteneurs et App Service.
  • L’option GitHub Actions est bien adaptée si vous conservez le code source de votre image conteneur dans GitHub. Déclenché par de nouvelles validations dans votre référentiel GitHub, l’action de déploiement peut exécuter docker build et docker push directement dans votre registre de conteneurs, puis mettre à jour votre application App Service pour exécuter la nouvelle image. Pour plus d’informations, consultez Fonctionnement de CI/CD avec GitHub Actions.
  • Pour configurer CI/CD avec Azure Pipelines, consultez Déployer un conteneur d’application Web Azure à partir d’Azure pipelines.

Notes

Pour une application Docker Compose, sélectionnez Container Registry.

Si vous choisissez GitHub Actions, cliquez sur Autoriser et suivez les invites d’autorisation. Si vous avez déjà autorisé GitHub, vous pouvez le déployer à partir d’un référentiel d’utilisateur différent en cliquant sur Modifier le compte.

Après avoir autorisé votre compte Azure auprès de GitHub, sélectionnez l’organisation, le référentiel et la branche à partir desquels vous allez effectuer le déploiement.

2. Configurer les paramètres du Registre

3. Configurer les paramètres du Registre

Remarque

Les conteneurs sidecar (préversion) remplaceront les applications multiconteneur (Docker Compose) dans App Service. Pour commencer, consultez Didacticiel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service (préversion).

Pour déployer une application multiconteneur (Docker Compose), sélectionnezDocker Compose dans Type de conteneur.

Si vous ne voyez pas la liste déroulante Type de conteneur, faites défiler la page jusqu’à Source, puis sélectionnezContainer Registry.

Dans Source du Registre, sélectionnez l’emplacement de votre registre de conteneurs. S’il ne s’agit ni de Azure Container Registry ni de Docker Hub, sélectionnezRegistre privé.

Notes

Si votre application multiconteneur (Docker Compose) utilise plusieurs images privées, assurez-vous que les images privées se trouvent dans le même registre privé et qu’elles sont accessibles avec les mêmes informations d’identification utilisateur. Si votre application multiconteneur utilise uniquement des images publiques, sélectionnezDocker Hub, même si certaines images ne se trouvent pas dans Docker Hub.

Suivez les étapes suivantes en sélectionnant l’onglet correspondant à votre choix.

La liste déroulante Registre affiche les registres dans le même abonnement que votre application. Sélectionnez le registre souhaité.

Remarque

Sélectionnez l’image et l’étiquette à déployer. Si vous le souhaitez, tapez la commande de démarrge dans le Fichier de démarrage.

Suivez l’étape suivante en fonction du type de conteneur :

  • Pour Docker Compose, sélectionnez le registre de vos images privées. Cliquez sur Choisir un fichier pour charger votre fichier Docker Compose ou collez simplement le contenu de votre fichier Docker Compose dans Configuration.
  • Pour Conteneur unique, sélectionnez l’image et l’étiquette à déployer. Si vous le souhaitez, tapez la commande de démarrge dans le Fichier de démarrage.

App Service ajoute la chaîne du Fichier de démarrage à la fin de la commande docker run (en tant que segment [COMMAND] [ARG...]) lors du démarrage de votre conteneur.

3. Activer CI/CD

4. Activer CI/CD

App Service prend en charge l’intégration de CI/CD avec Azure Container Registry et Docker Hub. Pour l’activer, sélectionnezActivé dans Déploiement continu.

Notes

Si vous sélectionnez GitHub Actions dans Source, vous n’avez pas cette option, car CI/CD est géré directement par GitHub Actions. Au lieu de cela, vous voyez la section Configuration du workflow, dans laquelle vous pouvez cliquersur Aperçu du fichier pour inspecter le fichier de workflow. Azure valide ce fichier dans le référentiel GitHub sélectionné afin de gérer les tâches de génération et de déploiement. Pour plus d’informations, consultez Fonctionnement de CI/CD avec GitHub Actions.

Quand vous activez cette option, App Service ajoute un webhook à votre référentiel dans Azure Container Registry ou Docker Hub. Votre référentiel publie sur ce webhook chaque fois que l’image sélectionnée est mise à jour avec docker push. Le webhook provoque le redémarrage et l’exécution de votre application App Service docker pull pour récupérer l’image mise à jour.

Remarque

Pour garantir le bon fonctionnement du webhook, il est essentiel d’activer l’option Informations d’identification de publication d’authentification de base dans votre application web. L’échec de cette opération peut entraîner une erreur 401 non autorisée pour le webhook. Pour vérifier si les Informations d’identification de publication d’authentification de base sont activées, procédez comme suit :

  • Accédez aux paramètres Configuration > Paramètres généraux de votre application web.
  • Recherchez la section Paramètre de plateforme, où vous trouverez l’option Informations d’identification de publication d’authentification de base.

Pour les autres registres privés, vous pouvez effectuer une publication manuelle sur le webhook ou en tant qu’étape dans un pipeline CI/CD. Dans URL du webhook, cliquez sur le bouton Copier pour accéder à l’URL du webhook.

Notes

La prise en charge des applications multiconteneurs (Docker Compose) est limitée :

  • Pour Azure Container Registry, App Service crée un webhook dans le registre sélectionné et définit ce dernier comme étendue. Un docker push vers n’importe quel référentiel du registre (y compris ceux qui ne sont pas référencés par votre fichier Docker Compose) déclenche le redémarrage de l’application. Vous souhaiterez peut-être modifier le webhook pour l’adapter à une étendue plus étroite.
  • Docker Hub ne prend pas en charge les webhooks au niveau du Registre. Vous devez ajouter les webhooks manuellement aux images spécifiées dans votre fichier Docker Compose.

4. Enregistrez vos paramètres

5. Enregistrez vos paramètres

Cliquez surEnregistrer.

Fonctionnement de CI/CD avec GitHub Actions

Si vous choisissez GitHub Actions dans Source (voir Choisir une source de déploiement), App Service configure CI/CD comme suit :

  • Dépose un fichier de workflow GitHub Actions dans votre référentiel GitHub pour gérer les tâches de génération et de déploiement vers App Service.
  • Ajoute les informations d’identification de votre registre privé en tant que secrets GitHub. Le fichier de workflow généré exécute l’action Azure/docker-login pour se connecter à votre registre privé, puis exécute docker push pour le déploiement.
  • Ajoute le profil de publication de votre application en tant que secret GitHub. Le fichier de flux de travail généré utilise ce secret pour s’authentifier auprès d’App Service, puis exécute l’action Azure/webapps-deploy pour configurer l’image mise à jour, ce qui déclenche un redémarrage de l’application en vue de l’extraction de l’image mise à jour.
  • Capture des informations à partir des journaux d’exécution de workflow et les affiche sous l’onglet Journaux dans le Centre de déploiement de votre application.

Vous pouvez personnaliser le fournisseur de build GitHub Actions comme suit :

  • Personnalisez le fichier de workflow après qu’il a été généré dans votre référentiel GitHub. Pour plus d’informations, consultez Syntaxe de workflow pour GitHub Actions. Assurez-vous simplement que le workflow se termine par l’action Azure/webapps-deploy pour déclencher le redémarrage de l’application.
  • Si la branche sélectionnée est protégée, vous pouvez toujours prévisualiser le fichier de workflow sans enregistrer la configuration, puis l’ajouter manuellement, ainsi que les secrets GitHub requis, dans votre référentiel. Cette méthode ne permet pas l’intégration des journaux avec le portail Azure.
  • Au lieu d’un profil de publication, effectuez le déploiement à l’aide d’un principal de service dans Microsoft Entra ID.

S’authentifier avec un principal de service

Cette configuration facultative remplace l’authentification par défaut par les profils de publication dans le fichier de workflow généré.

Générez un principal de service à l’aide de la commande az ad sp create-for-rbac dans Azure CLI. Dans l'exemple suivant, remplacez <subscription-id>, <group-name>, et <app-name> par vos propres valeurs. Enregistrez l’intégralité de la sortie JSON pour l’étape suivante, y compris le niveau supérieur {}.

az ad sp create-for-rbac --name "myAppDeployAuth" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
                            --json-auth

Important

Pour des raisons de sécurité, accordez l’accès minimal requis au principal du service. L’étendue dans l’exemple précédent est limitée à l’application App Service spécifique, et non à l’ensemble du groupe de ressources.

Dans GitHub, accédez à votre référentiel, sélectionnezParamètres > Secrets > Ajouter un nouveau secret. Collez l’intégralité de la sortie JSON de la commande Azure CLI dans le champ de valeur du secret. Nommez le secret comme AZURE_CREDENTIALS.

Dans le fichier de workflow généré par le Centre de déploiement, modifiez l’étape azure/webapps-deploy avec du code similaire à l’exemple suivant :

- name: Sign in to Azure 
# Use the GitHub secret you added
- uses: azure/login@v1
    with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy to Azure Web App
# Remove publish-profile
- uses: azure/webapps-deploy@v2
    with:
    app-name: '<app-name>'
    slot-name: 'production'
    images: '<registry-server>/${{ secrets.AzureAppService_ContainerUsername_... }}/<image>:${{ github.sha }}'
    - name: Sign out of Azure
    run: |
    az logout

Automatiser avec CLI

Pour configurer le registre de conteneurs et l’image Docker, exécutezaz webapp config container set.

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name '<image>:<tag>' --docker-registry-server-url 'https://<registry-name>.azurecr.io' --docker-registry-server-user '<username>' --docker-registry-server-password '<password>'

Pour configurer une application multiconteneur (Docker Compose), préparez un fichier Docker Compose localement, puis exécutezaz webapp config container set avec le paramètre --multicontainer-config-file. Si votre fichier Docker Compose contient des images privées, ajoutez--docker-registry-server-* des paramètres, comme indiqué dans l’exemple précédent.

az webapp config container set --resource-group <group-name> --name <app-name> --multicontainer-config-file <docker-compose-file>

Pour configurer CI/CD à partir du registre de conteneurs sur votre application, exécutezla commande az webapp deployment container config avec le paramètre --enable-cd. La commande génère l’URL du webhook, mais vous devez créer manuellement le webhook dans votre registre séparément. L’exemple suivant active CI/CD sur votre application, puis utilise l’URL du webhook dans la sortie pour créer le webhook dans Azure Container Registry.

ci_cd_url=$(az webapp deployment container config --name <app-name> --resource-group <group-name> --enable-cd true --query CI_CD_URL --output tsv)

az acr webhook create --name <webhook-name> --registry <registry-name> --resource-group <group-name> --actions push --uri $ci_cd_url --scope '<image>:<tag>'

Plus de ressources