Partage via


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 :

    Capture d’écran montrant comment choisir la source de déploiement.

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

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

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

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

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

  5. (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é.

  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.

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 :

    Capture d’écran montrant comment déconnecter la synchronisation de votre dossier cloud avec votre application App Service dans le portail Azure

  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.

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.

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 :

Forum aux questions

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