Partage 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é au processus Créer une application web par défaut. Définissez Déploiement continu sur Activer sous l’onglet Déploiement et configurez l’organisation, le référentiel et la branche souhaités.

Capture d’écran montrant comment activer le déploiement GitHub Actions sous l’onglet Déploiement Créer App Service.

Lorsque vous activez le déploiement continu, la 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

Il est possible que vous receviez une erreur quand vous créez l’application pour laquelle votre compte Azure ne dispose pas de certains 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 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 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 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 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

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. Cette approche est 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 suivante décrit les étapes pour créer une application Active Directory, un principal de service et des informations d’identification fédérées en utilisant des 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 renvoie un JSON avec un appId qui est votre client-id. Enregistrez la valeur à utiliser comme secret GitHub AZURE_CLIENT_ID ultérieurement.

    Vous utilisez la valeur objectId lors de la création d’informations d’identification fédérées avec l’API Graph, et la référencerez 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 à utiliser à 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. GitHub définit sa valeur en fonction de votre workflow :

      • Pour les 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"
    ]
}

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

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 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, 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 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 configurée, utilisez l’action azure/login@v1 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:
      # 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 ?

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 découvrir plus d’informations sur le plug-in Maven, 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 ?

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 découvrir plus d’informations sur l’action GitHub pour l’interface CLI et sur la façon de l’utiliser et de la configurer, consultez Action GitHub Azure CLI.

Pour découvrir 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 un fichier de démarrage ?

Utilisez GitHub Action pour Azure CLI. Par 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 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. Pour découvrir plus d’informations sur les étapes de déploiement en tirant parti de GitHub Actions dans Déployer sur un conteneur.

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 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 découvrir plus d’informations sur cette action, son utilisation et sa configuration, consultez le référentiel Paramètres App Service.

Contenu connexe

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