Partager via

Déployer sur Azure App Service à l’aide de GitHub Actions

Utilisez GitHub Actions pour automatiser votre workflow et déployer sur Azure App Service à partir de GitHub.

Prérequis

Configurer le déploiement gitHub Actions lors de la création d’une application

Le déploiement de GitHub Actions est intégré au processus Créer une application web par défaut. Définissez le déploiement continu sur Activer sous l’onglet Déploiement et configurez votre organisation, votre référentiel et votre branche choisis.

Capture d’écran montrant comment activer le déploiement gitHub Actions dans l’onglet Déploiement d’App Service.

Lorsque vous activez le déploiement continu, le processus Créer une application web sélectionne automatiquement la méthode d’authentification en fonction de la sélection d’authentification de base et configure votre application et votre dépôt GitHub en conséquence :

Sélection de l’authentification de base Méthode d'authentification
Disable Identité affectée par l’utilisateur (OpenID Connect) (recommandé)
Activer Authentification de base

Remarque

Lorsque vous créez une application, vous pouvez recevoir une erreur indiquant que votre compte Azure n’a pas certaines autorisations. Votre compte aura peut-être besoin des autorisations requises pour créer et configurer l’identité affectée par l’utilisateur. Pour obtenir une alternative, consultez la section suivante.

Configurer le déploiement gitHub Actions à partir du Centre de déploiement

Pour une application existante, vous pouvez rapidement commencer à utiliser GitHub Actions à l’aide du Centre de déploiement dans App Service. Cette méthode clé en main génère un fichier de workflow GitHub Actions basé sur votre pile d’applications et le valide dans votre référentiel GitHub.

À l’aide du Centre de déploiement, vous pouvez également configurer facilement l’authentification OpenID Connect plus sécurisée avec une identité affectée par l’utilisateur. Pour découvrir plus d’informations, consultez l’option d’identité affectée par l’utilisateur.

Si votre compte Azure dispose des autorisations nécessaires, vous pouvez créer une identité affectée par l’utilisateur. Sinon, vous pouvez sélectionner une identité managée affectée par l’utilisateur existante dans le menu déroulant Identité. Vous pouvez collaborer avec votre administrateur Azure pour créer une identité managée affectée par l’utilisateur avec le rôle Contributeur de site web.

Pour plus d’informations, consultez Déploiement continu sur Azure App Service.

Configurer manuellement un workflow GitHub Actions

Vous pouvez déployer un flux de travail sans utiliser le Centre de déploiement. Effectuez ces trois étapes :

  1. Générez des identifiants de déploiement.
  2. Configurez le secret GitHub.
  3. Ajoutez le fichier de flux de travail à votre dépôt GitHub.

Générer les informations d’identification du déploiement

Nous vous recommandons d’utiliser OpenID Connect pour vous authentifier auprès d’Azure App Service pour GitHub Actions. Cette méthode d’authentification utilise des jetons de courte durée. La configuration d’OpenID Connect avec GitHub Actions est plus complexe, mais offre une sécurité renforcée.

Vous pouvez également vous authentifier avec une identité managée affectée par l’utilisateur, un principal de service ou un profil de publication.

La procédure suivante décrit les étapes de création d’une application Microsoft Entra, d’un principal de service et d’informations d’identification fédérées à l’aide d’instructions Azure CLI. Pour savoir comment créer une application Microsoft Entra, un principal de service et des informations d’identification fédérées dans le portail Azure, consultez Connecter GitHub et Azure.

  1. Si vous n’avez pas d’application existante, inscrivez une nouvelle application Microsoft Entra et un principal de service pouvant accéder aux ressources. Créez l’application Microsoft Entra.

    az ad app create --display-name myApp

    Cette commande retourne une sortie JSON avec une appId valeur qui est votre client-id. Enregistrez la valeur à utiliser comme secret GitHub AZURE_CLIENT_ID ultérieurement.

    Vous utilisez la valeur objectId lorsque vous créez des informations d’identification fédérées avec l’API Graph et la référence en tant que APPLICATION-OBJECT-ID.

  2. Créer un principal de service. Remplacez la $appID valeur par celle appId de votre sortie JSON.

    Cette commande génère une sortie JSON avec une objectId différente à utiliser à l’étape suivante. Le nouveau objectId est le assignee-object-id.

    Copiez la appOwnerTenantId clé à utiliser ultérieurement en tant que secret GitHub pour AZURE_TENANT_ID.

    az ad sp create --id $appId

  3. Créez une attribution de rôle par abonnement et objet. Par défaut, l’attribution de rôle est liée à votre abonnement par défaut. Remplacez $subscriptionId par votre ID d’abonnement, $resourceGroupName par le nom de votre groupe de ressources, $webappName par le nom de votre application web, et $assigneeObjectId par le id généré. Découvrez comment gérer les abonnements Azure avec Azure CLI.

    az role assignment create --role "Website Contributor" --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal

  4. Exécutez la commande suivante pour créer des informations d’identification d’identité fédérée pour votre application Microsoft Entra.

    • Remplacez APPLICATION-OBJECT-ID par celui appId que vous avez généré lors de la création de l’application pour votre application Active Directory.

    • Définissez une valeur pour CREDENTIAL-NAME que vous référencerez ultérieurement.

    • Définissez subject. GitHub définit sa valeur en fonction de votre workflow :

      • Pour les travaux dans votre environnement GitHub Actions, utilisez : repo:< Organization/Repository >:environment:< Name >
      • Pour les travaux non liés à un environnement, incluez le chemin de référence pour la branche/étiquette en fonction du chemin de référence utilisé pour déclencher le flux de travail : repo:< Organization/Repository >:ref:< ref path>. Par exemple, repo:n-username/ node_express:ref:refs/heads/my-branch ou repo:n-username/ node_express:ref:refs/tags/my-tag.
      • Pour les flux de travail déclenchés par un événement de pull request, utilisez : repo:< Organization/Repository >:pull_request.
    az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:organization/repository:ref:refs/heads/main",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

Configurer le secret GitHub

Vous devez fournir l’ID client, l’ID de locataire et l’ID d’abonnement de votre application à l’actionAzure/login. Vous pouvez fournir ces valeurs directement dans le workflow ou les stocker dans des secrets GitHub et les référencer dans votre workflow. L’enregistrement des valeurs en tant que secrets GitHub est l’option la plus sécurisée.

  1. Ouvrez votre référentiel GitHub et accédez à Paramètres>Sécurité>Secrets et variables>Actions>Nouveau secret de référentiel.

  2. Créez des secrets pour AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID. Utilisez les valeurs de votre application Active Directory pour vos secrets GitHub :

    Secret GitHub Application de l'Active Directory
    AZURE_CLIENT_ID ID d’application (client)
    AZURE_TENANT_ID ID de l’annuaire (locataire)
    AZURE_SUBSCRIPTION_ID Identifiant d’abonnement

  3. Sélectionnez Ajouter un secret pour enregistrer chaque secret.

Ajouter le fichier de workflow à votre référentiel GitHub

Un fichier YAML (.yml) situé dans le chemin /.github/workflows/ de votre référentiel GitHub définit un workflow. Cette définition contient les étapes et les paramètres qui composent le workflow.

Au minimum, le fichier de flux de travail comporte les étapes distinctes suivantes :

  1. Authentifiez-vous auprès d’App Service à l’aide du secret GitHub que vous avez créé.
  2. Créez l’application web.
  3. Déployez l’application web.

Pour déployer votre code sur une application App Service, utilisez l’action azure/webapps-deploy@v3 . L’action nécessite le nom de votre application web dans app-name et, en fonction de votre pile de langage, le chemin d’un *.zip, *.war, *.jar ou dossier à déployer dans package. Pour obtenir la liste complète des entrées possibles pour l’action azure/webapps-deploy@v3, consultez action.yml.

Les exemples suivants illustrent la partie du workflow qui génère l’application web, dans différents langages pris en charge.

Pour déployer avec OpenID Connect en utilisant l'identité managée que vous avez configurée, utilisez l’action azure/login@v2 avec les clés client-id, tenant-id et subscription-id. Faites référence aux secrets GitHub créés plus tôt.

name: .NET Core

on: [push]

permissions:
      id-token: write
      contents: read

env:
  AZURE_WEBAPP_NAME: my-app    # Set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # Set this to the path to your web app project, defaults to the repository root
  DOTNET_VERSION: '6.0.x'           # Set this to the dot net version to use

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Check out the repo
      - uses: actions/checkout@main
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      
      # Setup .NET Core SDK
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }} 
      
      # Run dotnet build and publish
      - name: dotnet build and publish
        run: |
          dotnet restore
          dotnet build --configuration Release
          dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' 
          
      # Deploy to Azure Web apps
      - name: 'Run Azure webapp deploy action using publish profile credentials'
        uses: azure/webapps-deploy@v3
        with: 
          app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
      
      - name: logout
        run: |
          az logout

Questions fréquemment posées

Comment déployer un fichier WAR via le plug-in Maven ?

Si vous avez configuré votre projet Java Tomcat avec le plug-in Maven, vous pouvez également déployer sur Azure App Service via ce plug-in. Si vous utilisez l’action GitHub Azure CLI, elle utilise vos informations d’identification Azure.

    - name: Azure CLI script file
      uses: azure/cli@v2
      with:
        inlineScript: |
          mvn package azure-webapp:deploy

Pour plus d’informations sur l’utilisation et la configuration du plug-in Maven, consultez le wiki du plug-in Maven pour Azure App Service.

Comment déployer un fichier WAR via Azure CLI ?

Si vous préférez utiliser Azure CLI pour déployer sur App Service, vous pouvez utiliser GitHub Action pour Azure CLI.

- name: Azure CLI script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path '${{ github.workspace }}/target/yourpackage.war' --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }}  --async true --type war

Pour plus d’informations sur l’utilisation et la configuration de l’action GitHub pour Azure CLI, consultez l’action GitHub d’Azure CLI.

Pour plus d’informations sur la az webapp deploy commande, notamment sur la façon de l’utiliser et les détails du paramètre, consultez az webapp deploy la documentation.

Comment faire pour déployer un fichier de démarrage ?

Utilisez l’action GitHub pour Azure CLI. Exemple :

- name: Deploy startup script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path ${{ github.workspace }}/src/main/azure/createPasswordlessDataSource.sh --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }} --type startup --track-status false

Comment déployer dans un conteneur ?

Avec l’action Azure Web Deploy , vous pouvez automatiser votre flux de travail pour déployer des conteneurs personnalisés sur App Service à l’aide de GitHub Actions. Pour plus d’informations, consultez Déployer sur un conteneur.

Comment puis-je déployer sur un emplacement de déploiement ?

Vous pouvez déployer sur un emplacement de déploiement au lieu de l’emplacement de production à l’aide du slot-name paramètre dans l’action azure/webapps-deploy@v3 . Pour effectuer un déploiement sur un emplacement, ajoutez le slot-name paramètre à l’étape de déploiement de votre workflow :

- name: Deploy to Azure Web App
  uses: azure/webapps-deploy@v3
  with:
    app-name: 'my-app-name'
    slot-name: 'staging'  # Deploy to the 'staging' slot instead of production
    package: './output'

Remarque

Lorsque vous utilisez l’authentification OpenID Connect ou par principal de service, vérifiez que l’identité dispose du rôle Contributeur de site web à la fois sur l’application et sur l’emplacement de déploiement. Pour l’authentification de profil de publication, téléchargez le profil de publication pour l’emplacement de déploiement spécifique à partir du portail Azure (emplacements>de déploiement> sélectionnez l’emplacement, puis >).

Comment faire pour mettre à jour la configuration Tomcat après un déploiement ?

Si vous souhaitez mettre à jour l’un de vos paramètres d’applications web après le déploiement, vous pouvez utiliser l’action de paramètres App Service .

    - uses: azure/appservice-settings@v1
      with:
        app-name: 'my-app'
        slot-name: 'staging'  # Optional and needed only if the settings have to be configured on the specific deployment slot
        app-settings-json: '[{ "name": "CATALINA_OPTS", "value": "-Dfoo=bar" }]' 
        connection-strings-json: '${{ secrets.CONNECTION_STRINGS }}'
        general-settings-json: '{"alwaysOn": "false", "webSocketsEnabled": "true"}' #'General configuration settings as Key Value pairs'
      id: settings

Pour plus d’informations sur l’utilisation et la configuration de cette action, consultez le référentiel des paramètres App Service .

Contenu connexe

Consultez les références suivantes sur Azure GitHub Actions et les flux de travail :

  • Last updated on