Déploiement continu vers Azure App Service

Remarque

Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.

Exemple : myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour les ressources App Service.

Azure App Service permet un déploiement continu à partir des dépôts GitHub, Bitbucket et Azure Repos en extrayant les dernières mises à jour.

Préparer votre dépôt

Pour obtenir des builds automatiques auprès du serveur de builds Azure App Service, vérifiez que la racine de votre référentiel contient les fichiers appropriés de votre projet.

Runtime	Fichiers du répertoire racine
ASP.NET (Windows uniquement)	*.sln, *.csproj ou default.aspx
ASP.NET Core	*.sln ou *.csproj
PHP	index.php
Ruby (Linux uniquement)	Gemfile
Node.JS	server.js, app.js ou package.json avec un script de démarrage
Python	*.py, requirements.txt ou runtime.txt
HTML	default.htm, default.html, default.asp, index.htm, index.html ou iisstart.htm
WebJobs	<job_name>/run.<extension> sous App_Data/jobs/continuous pour WebJobs continus ou App_Data/jobs/triggered pour WebJobs déclenchées. Pour plus d’informations, consultez la documentation Kudu relative aux WebJobs.
Fonctions	Consultez Déploiement continu pour Azure Functions.

Pour personnaliser votre déploiement, vous pouvez inclure un fichier .deployment dans la racine du dépôt. Pour plus d’informations, consultez Personnaliser les déploiements et Personnaliser un script de déploiement.

Notes

Si vous utilisez dans Visual Studio, laissez Visual Studio vous créer un référentiel. Votre projet sera immédiatement prêt pour le déploiement via Git.

Configurer la source de déploiement

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

2. Dans le volet gauche, sélectionnez Centre de déploiement. Sélectionnez ensuite Paramètres.

3. Dans la zone Source, sélectionnez l’une des options CI/CD :

   

Sélectionnez l’onglet qui correspond à votre fournisseur de build pour continuer.

GitHub

4. GitHub Actions correspond au fournisseur de build par défaut. Pour changer le fournisseur, sélectionnez Changer de fournisseur >Service de build App Service>OK.

5. La première fois que vous effectuez un déploiement à partir de GitHub, sélectionnez Autoriser et suivez les invites d’autorisation. Si vous souhaitez effectuer un déploiement à partir d’un autre dépôt d’utilisateur, sélectionnez Changer de compte.

6. Après avoir autorisé votre compte Azure auprès de GitHub, sélectionnez l’organisation, le dépôt et la branche souhaités.

   Si vous ne trouvez pas d’organisation ni de dépôt, vous avez peut-être besoin d’activer des autorisations supplémentaires sur GitHub. Pour plus d’informations, consultez Gestion de l’accès aux dépôts de votre organisation.

7. Sous Type d’authentification, sélectionnez Identité affectée par l’utilisateur pour une meilleure sécurité. Pour plus d’informations, consultez les Questions fréquentes (FAQ).

   Remarque

   Si votre compte Azure dispose des autorisations requises pour l’option Identité affectée par l’utilisateur, Azure crée une identité managée affectée par l’utilisateur pour vous. Si ce n’est pas le cas, collaborez avec votre administrateur Azure pour créer une identité avec le rôle requis sur votre application, puis sélectionnez-la ici dans la liste déroulante.

8. (Facultatif) Pour afficher le fichier avant d’enregistrer vos modifications, sélectionnez Aperçu du fichier. App Service sélectionne un modèle de workflow en fonction du paramètre de pile de langage de votre application, et le commite dans votre dépôt GitHub sélectionné.

9. Sélectionnez Enregistrer.

   Les nouvelles validations correspondant au dépôt et à la branche sélectionnés sont déployées en continu dans votre application App Service. Vous pouvez suivre les validations et les déploiements sous l’onglet Journaux.

Bitbucket

L’intégration de Bitbucket utilise les services de build App Service pour l’automatisation de la génération.

4. La première fois que vous effectuez un déploiement à partir de Bitbucket, sélectionnez Autoriser et suivez les invites d’autorisation. Si vous souhaitez effectuer un déploiement à partir d’un autre dépôt d’utilisateur, sélectionnez Changer de compte.

5. Pour Bitbucket, sélectionnez l'Équipe, le Référentiel et la Branche que vous souhaitez déployer en continu.

6. Sélectionnez Enregistrer.

   Les nouvelles validations correspondant au dépôt et à la branche sélectionnés sont déployées en continu dans votre application App Service. Vous pouvez suivre les validations et les déploiements sous l’onglet Journaux.

Git local

Consultez Déploiement Git local vers Azure App Service.

Azure Repos

4. Le service de build App Service est le fournisseur de build par défaut.

   Remarque

   Pour utiliser Azure Pipelines comme fournisseur de build pour votre application App Service, configurez-le directement à partir d’Azure Pipelines. Ne le configurez pas dans App Service. L’option Azure Pipelines permet de simplement pointer dans la bonne direction.

5. Sélectionnez l'organisation Azure DevOps, le projet, le référentiel et la branche que vous souhaitez déployer en continu.

   Si votre organisation DevOps n'est pas répertoriée, assurez-vous qu'elle est liée à votre abonnement Azure. Pour plus d’informations, consultez l’article Créer une connexion au service Azure.

Autres dépôts

Pour les applications Windows, vous pouvez configurer manuellement le déploiement continu à partir d’un dépôt cloud Git ou Mercurial que le portail ne prend pas directement en charge, comme GitLab. Pour ce faire, vous devez sélectionner Git externe dans la liste déroulante Source. Pour plus d’informations, consultez Configurer le déploiement continu avec des étapes manuelles.

Désactiver le déploiement continu

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

2. Dans le volet gauche, sélectionnez Centre de déploiement. Ensuite, sélectionnez Paramètres>Déconnecter :

   

3. Par défaut, le fichier de workflow GitHub Actions est conservé dans votre référentiel, mais continue de déclencher le déploiement vers votre application. Pour supprimer ce fichier de votre dépôt, sélectionnez Supprimer le fichier de workflow.

4. Cliquez sur OK.

Qu’est-ce qu’un fournisseur de build ?

En fonction de votre source de déploiement dans le Centre de déploiement, quelques options peuvent être disponibles pour les fournisseurs de build. Les fournisseurs de build vous aident à créer une solution CI/CD avec Azure App Service en automatisant la génération, le test et le déploiement.

Vous n’êtes pas limité aux options de fournisseur de build figurant dans le Centre de déploiement, mais App Service vous permet de les configurer rapidement et offre une expérience de journalisation de déploiement intégrée.

Actions GitHub

Le fournisseur de build GitHub Actions est disponible uniquement pour le déploiement GitHub. Lorsqu’il est configuré à partir du Centre de déploiement de l’application, il effectue ces actions pour configurer CI/CD :

• 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.
• Pour l’authentification de base, il ajoute le profil de publication de votre application en tant que secret GitHub. Le fichier de workflow utilise ce secret pour s’authentifier auprès d’App Service.
• Pour l’identité affectée par l’utilisateur, consultez Que fait l’option d’identité affectée par l’utilisateur pour GitHub Actions ?
• Capture des informations à partir des journaux d’exécution de workflow et les affiche sous l’onglet Journaux dans le Centre de déploiement.

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 que le workflow est déployé dans App Service avec l’action azure/webapps-deploy.
• Si la branche sélectionnée est protégée, vous pouvez toujours afficher un aperçu du fichier de workflow sans enregistrer la configuration, puis l’ajouter manuellement dans votre dépôt. Cette méthode ne permet pas l’intégration des journaux avec le portail Azure.
• Au lieu d’utiliser l’authentification de base ou une identité affectée par l’utilisateur, vous pouvez également déployer à l’aide d’un principal de service dans Microsoft Entra ID. Cela ne peut pas être configuré dans le portail.

Service de build App Service

Remarque

Le service de build App Service exige que l’authentification SCM de base soit activée pour que le webhook fonctionne. Pour plus d’informations, consultez Déploiement sans authentification de base.

Le service de build App Service est le moteur de déploiement et de build natif d’App Service, autrement appelé Kudu. Lorsque cette option est sélectionnée, App Service ajoute un webhook dans le dépôt que vous avez autorisé. Tout envoi (push) de code vers le dépôt déclenche le webhook, et App Service tire (pull) les modifications dans son dépôt et effectue toutes les tâches de déploiement. Pour plus d’informations, consultez Déploiement à partir de GitHub (Kudu).

Ressources :

• Examiner les problèmes courants liés au déploiement continu
• Project Kudu

Azure Pipelines

Azure Pipelines fait partie d’Azure DevOps. Vous pouvez configurer un pipeline pour générer, tester et déployer votre application sur App Service à partir de n’importe quel dépôt source pris en charge.

Pour utiliser Azure Pipelines en tant que fournisseur de build, ne le configurez pas dans App Service, mais accédez directement à Azure DevOps. Dans le Centre de déploiement, l’option Azure Pipelines vous mène simplement dans la bonne direction.

Pour plus d’informations, consultez Déployer sur App Service avec Azure Pipelines.

Que se passe-t-il au niveau de mon application pendant le déploiement ?

Toutes les méthodes de déploiement officiellement prises en charge apportent des modifications aux fichiers dans le dossier /home/site/wwwroot de votre application. Ces fichiers sont utilisés pour exécuter votre application. Par conséquent, le déploiement peut échouer si des fichiers sont verrouillés. L’application peut également se comporter de façon imprévisible pendant le déploiement, car tous les fichiers ne sont pas tous mis à jour en même temps. Cela n’est pas souhaitable pour une application faisant face au client. Il existe différentes manières d’éviter ces problèmes :

• Exécutez votre application directement à partir du package ZIP sans l’en extraire.
• Arrêtez votre application ou activez le mode hors connexion pendant le déploiement. Pour plus d’informations, consultez Gérer les fichiers verrouillés au cours du déploiement.
• Effectuez le déploiement sur un emplacement de préproduction avec échange automatique activé.

Forum aux questions

• Le fournisseur de build GitHub Actions fonctionne-t-il avec l’authentification de base si celle-ci est désactivée ?
• Que fait l’option d’identité affectée par l’utilisateur pour GitHub Actions ?
• Pourquoi l’erreur « Cette identité n’a pas d’autorisations d’écriture sur cette application. Sélectionnez une identité différente ou collaborez avec votre administrateur pour accorder le rôle Contributeur de site web à votre identité sur cette application » s’affiche-t-elle ?
• Pourquoi l’erreur « Cette identité n’a pas d’autorisations d’écriture sur cette application. Sélectionnez une identité différente ou collaborez avec votre administrateur pour accorder le rôle Contributeur de site web à votre identité sur cette application » s’affiche-t-elle ?

Le fournisseur de build GitHub Actions fonctionne-t-il avec l’authentification de base si celle-ci est désactivée ?

Non. Essayez d’utiliser GitHub Actions avec l’option d’identité affectée par l’utilisateur.

Pour plus d’informations, consultez Déploiement sans authentification de base.

Que fait l’option d’identité affectée par l’utilisateur pour GitHub Actions ?

Lorsque vous sélectionnez Identité affectée par l’utilisateur sous la source GitHub Actions, App Service configure toutes les ressources nécessaires dans Azure et dans GitHub pour activer l’authentification OpenID Connect recommandée avec GitHub Actions.

Plus précisément, App Service effectue les opérations suivantes :

• Crée des informations d’identification fédérées entre une identité managée affectée par l’utilisateur dans Azure et votre dépôt et votre branche sélectionnés dans GitHub.
• Crée les secrets AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID à partir des informations d’identification fédérées dans votre dépôt GitHub sélectionné.
• Affecte l’identité à votre application.

Dans un workflow GitHub Actions dans votre dépôt GitHub, vous pouvez ensuite utiliser l’action Azure/login pour vous authentifier auprès de votre application à l’aide d’OpenID Connect. Pour obtenir des exemples, consultez Ajouter le fichier de workflow à votre dépôt GitHub.

Si votre compte Azure dispose des autorisations requises, App Service crée une identité managée affectée par l’utilisateur et la configure pour vous. Cette identité n’apparaît pas dans la page Identités de votre application. Si votre compte Azure ne dispose pas des autorisations requises, vous devez sélectionner une identité existante avec le rôle requis.

Pourquoi l’erreur « Vous ne disposez pas des autorisations suffisantes sur cette application pour attribuer un accès en fonction du rôle à une identité managée et configurer des informations d’identification fédérées » s’affiche-t-elle ?

Le message indique que votre compte Azure n’a pas les autorisations requises pour créer une identité managée affectée par l’utilisateur pour GitHub Actions. Les autorisations requises (étendues à votre application) sont les suivantes :

• Microsoft.Authorization/roleAssignments/write
• Microsoft.ManagedIdentity/userAssignedIdentities/write

Par défaut, les rôles Administrateur de l’accès utilisateur et Propriétaire disposent déjà de ces autorisations, mais le rôle Contributeur n’en dispose pas. Si vous n’avez pas les autorisations requises, collaborez avec votre administrateur Azure pour créer une identité managée affectée par l’utilisateur avec le rôle Contributeur de site web. Dans le Centre de déploiement, vous pouvez ensuite sélectionner l’identité dans la liste déroulante GitHub>Identité.

Pour plus d’informations sur les autres étapes, consultez Déployer sur App Service à l’aide de GitHub Actions.

Pourquoi l’erreur « Cette identité n’a pas d’autorisations d’écriture sur cette application. Sélectionnez une identité différente ou collaborez avec votre administrateur pour accorder le rôle Contributeur de site web à votre identité sur cette application » s’affiche-t-elle ?

Le message indique que l’identité managée affectée par l’utilisateur sélectionnée n’a pas le rôle requis pour activer OpenID Connect entre le dépôt GitHub et l’application App Service. L’identité doit avoir l’un des rôles suivants sur l’application : Propriétaire, Contributeur, Contributeur de sites web. Le rôle le moins privilégié dont l’identité a besoin est Contributeur de sites web.

Plus de ressources

• Utilisation d'Azure PowerShell