Share via

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

  • Article

Prenez en main GitHub Actions pour automatiser votre workflow et le déployer sur Azure App Service à partir de GitHub.

Prérequis

Configurer le déploiement de GitHub Actions lors de la création de l’application

Le déploiement de GitHub Actions est intégré à l’Assistant Création d’application par défaut. Vous devez simplement définir Déploiement continu sur Activer sous l’onglet Déploiement et configurer l’organisation, le référentiel et la branche souhaités.

Capture d’écran montrant comment activer le déploiement GitHub Actions dans l’Assistant Création d’App Service.

Lorsque vous activez le déploiement continu, l’Assistant Création d’application sélectionne automatiquement la méthode d’authentification en fonction de la sélection d’authentification de base et configure votre application et votre référentiel GitHub en conséquence :

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

Remarque

Si vous recevez une erreur lors de la création de votre application indiquant que votre compte Azure ne possède pas certaines autorisations, il se peut qu’il ne dispose pas des autorisations requises pour créer et configurer l’identité affectée par l’utilisateur. Pour obtenir une alternative, consultez Configurer le déploiement de GitHub Actions à partir du Centre de déploiement.

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

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

Le Centre de déploiement vous permet également de configurer facilement l’authentification OpenID Connect plus sécurisée avec l’option d’identité affectée par l’utilisateur.

Si votre compte Azure dispose des autorisations nécessaires, vous pouvez sélectionner de 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 la liste déroulante 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 également déployer un workflow sans utiliser le centre de déploiement. Dans ce cas, vous devez effectuer trois étapes :

  1. Générer les informations d’identification du déploiement
  2. Configurer le secret GitHub
  3. Ajouter le fichier de workflow à votre référentiel GitHub

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

La méthode recommandée pour l’authentification auprès d’Azure App Service pour GitHub Actions consiste à utiliser OpenID Connect. Il s’agit d’une méthode d’authentification qui 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 ci-dessous vous permet de créer une application Active Directory, un principal de service et des informations d’identification fédérées à l’aide d’instructions Azure CLI. Pour savoir comment créer une application Active Directory, 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 Active Directory et un principal de service pouvant accéder aux ressources. Créez l’application Active Directory.

    az ad app create --display-name myApp

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

    Vous allez utiliser la valeur objectId lors de la création d’informations d’identification fédérées avec l’API Graph, et la référencer en tant que APPLICATION-OBJECT-ID.

  2. Créer un principal de service. Remplacez le $appID par l’appID de votre sortie JSON.

    Cette commande génère une sortie JSON avec un objectId différent, qui sera utilisée à l’étape suivante. Le nouveau objectId est le assignee-object-id.

    copiez le appOwnerTenantId à utiliser comme secret GitHub pour AZURE_TENANT_ID ultérieurement.

     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 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 Active Directory.

    • Remplacez APPLICATION-OBJECT-ID par l’appId (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. Sa valeur est définie par GitHub en fonction de votre workflow :
      • Travaux dans votre environnement GitHub Actions : repo:< Organization/Repository >:environment:< Name >
      • Pour les tâches non liées à un environnement, incluez le chemin de référence (ref path) de la branche/étiquette en fonction du chemin de référence utilisé pour déclencher le workflow : 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 workflows déclenchés par un événement de demande de tirage (pull request) : 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"
    ]
}

2. Configurer le secret GitHub

Vous devez fournir l’ID de client, l’ID de locataire et l’ID d’abonnement de votre application à l’action Azure/connexion. 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 dépôt GitHub et accédez à Paramètres > Sécurité > Secrets et variables > Actions > Nouveau secret de dépôt.

  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 Active Directory
    AZURE_CLIENT_ID ID d’application (client)
    AZURE_TENANT_ID ID de l’annuaire (locataire)
    AZURE_SUBSCRIPTION_ID Identifiant d’abonnement

  3. Enregistrez chaque secret en sélectionnant Ajouter un secret.

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

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

Au minimum, le fichier de workflow inclut 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, vous utilisez l’action azure/webapps-deploy@v3. L’action nécessite le nom de votre application web dans app-name et, selon votre pile de langage, le chemin d’accès d’un fichier *.zip, *.war ou *.jar, ou d’un dossier à déployer dans package. Pour obtenir la liste complète des entrées possibles pour l’action azure/webapps-deploy@v3, consultez la définition 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 à l’aide de l’identité managée que vous avez configurée, utilisez l’action azure/login@v1 avec les clés client-id, tenant-id et subscription-id et faites référence aux secrets GitHub que vous avez créés précédemment.

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:
      # Checkout the repo
      - uses: actions/checkout@main
      - uses: azure/login@v1
        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

Forums Aux Questions (FAQ)

Comment faire pour déployer un fichier WAR via le plug-in Maven et OpenID Connect ?

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 de connexion Azure.

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

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

Comment faire pour déployer un fichier WAR via Az CLI et OpenID Connect ?

Si vous préférez utiliser Azure CLI pour déployer sur App Service, vous pouvez utiliser l’action GitHub pour l’interface 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

Vous trouverez plus d’informations sur l’action GitHub pour l’interface CLI et sur la façon de l’utiliser et de la configurer dans Action GitHub Azure CLI. Pour plus d’informations sur la commande az webapp deploy, sur son utilisation, et sur les détails des paramètres, consultez la documentation az webapp deploy.

Comment faire pour déployer sur un conteneur ?

Grâce à l’action Azure Web Deploy, vous pouvez automatiser votre workflow pour déployer des conteneurs personnalisés sur App Service à l’aide de GitHub Actions. Vous trouverez des informations détaillées sur les étapes de déploiement à l’aide de GitHub Actions dans Déployer sur un conteneur.

Comment faire pour mettre à jour la configuration Tomcat après le 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 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

Vous trouverez plus d’informations sur cette action et sur son utilisation et sa configuration dans le dépôt Paramètres App Service.

Étapes suivantes

Consultez les références sur Azure GitHub Actions et les workflow :