Déployer des modèles ARM à l’aide de GitHub Actions

GitHub Actions est une suite de fonctionnalités dans GitHub permettant d’automatiser vos workflows de développement logiciel dans le même emplacement que celui où vous stockez le code et collaborez sur les demandes de tirage (pull requests) et les problèmes.

Utilisez l’action Déployer un modèle Azure Resource Manager pour automatiser le déploiement d’un modèle Azure Resource Manager (modèle ARM) sur Azure.

Prérequis

• Compte Azure avec un abonnement actif. Créez un compte gratuitement.

• Un compte GitHub. Si vous n’en avez pas, inscrivez-vous gratuitement.

  • Un référentiel GitHub pour stocker vos modèles Resource Manager et vos fichiers de workflow. Pour en créer un, consultez Création d’un référentiel.

Vue d’ensemble du fichier de workflow

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

Le fichier comporte deux sections :

Section	Tâches
Authentification	1. Générer les informations d’identification du déploiement.
Déployer	1. Déployez le modèle Resource Manager.

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

OpenID Connect

Pour utiliser l’action de connexion Azure avec OIDC, vous devez configurer des informations d’identification d’identité fédérée sur une application Microsoft Entra ou une identité managée affectée par l’utilisateur.

Option 1 : application Microsoft Entra

• Créez une application Microsoft Entra avec un principal de service par Portail Azure, Azure CLI ou PowerShell.
• Copiez les valeurs pour ID client et ID d’abonnement et ID d’annuaire (locataire). Vous en aurez besoin dans votre workflow GitHub Actions.
• Attribuez un rôle approprié à votre principal de service par le Portail Azure, Azure CLI ou Azure PowerShell.
• Configurez des informations d’identification fédérées sur une application Microsoft Entra pour approuver les jetons émis par GitHub Actions pour votre référentiel GitHub.

Option 2 : identité managée affectée par l’utilisateur

• Créer une identité managée attribuée par l’utilisateur.
• Copiez les valeurs pour ID client et ID d’abonnement et ID d’annuaire (locataire). Vous en aurez besoin dans votre workflow GitHub Actions.
• Attribuez un rôle approprié à votre identité managée affectée par l’utilisateur.
• Configurez des informations d’identification fédérées sur une identité managée affectée par l’utilisateur pour approuver les jetons émis par GitHub Actions pour votre référentiel GitHub.

Principal du service

• Créez une application Microsoft Entra avec un principal de service par Portail Azure, Azure CLI ou PowerShell.
• Créez une clé secrète client pour votre principal de service par le Portail Azure, Azure CLI ou Azure PowerShell.
• Copiez les valeurs de l’ID client, de la Clé secrète client, de l’ID d’abonnement et de l’ID d’annuaire (locataire) pour les utiliser plus tard dans votre flux de travail GitHub Actions.
• Attribuez un rôle approprié à votre principal de service par le Portail Azure, Azure CLI ou Azure PowerShell.

Configurer les secrets GitHub

OpenID Connect

Vous devez fournir l’ID de client, l’ID d’annuaire (locataire) et l’ID d’abonnement de votre application à l’action de 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. Dans GitHub, accédez à votre dépôt.

2. Sélectionnez Sécurité > Secrets et variables > Actions.

   

3. Sélectionnez New repository secret (Nouveau secret de dépôt).

   Remarque

   Pour améliorer la sécurité des flux de travail dans des référentiels publics, utilisez des secrets d’environnement plutôt que des secrets de référentiel. Si l’environnement nécessite une approbation, un travail ne peut pas accéder aux secrets d’environnement tant que l’un des réviseurs requis ne l’approuve pas.

4. Créez des secrets pour AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID. Copiez ces valeurs à partir de votre application Microsoft Entra ou de l’identité managée affectée par l’utilisateur pour vos secrets GitHub :

   Secret GitHub	Application Microsoft Entra ou identité managée affectée par l’utilisateur
   AZURE_CLIENT_ID	ID client
   AZURE_SUBSCRIPTION_ID	ID d’abonnement
   AZURE_TENANT_ID	ID de l’annuaire (locataire)

   Remarque

   Pour des raisons de sécurité, nous vous recommandons d’utiliser des secrets GitHub plutôt que de transmettre des valeurs directement au flux de travail.

Principal du service

1. Dans GitHub, accédez à votre dépôt.

2. Sélectionnez Paramètres dans le volet de navigation.

3. Sélectionnez Sécurité > Secrets et variables > Actions.

   

4. Sélectionnez New repository secret (Nouveau secret de dépôt).

5. Collez l’intégralité de la sortie JSON de la commande Azure CLI dans le champ de valeur du secret. Nommez le secret AZURE_CREDENTIALS.

6. Sélectionnez Ajouter un secret.

Ajouter un modèle Resource Manager

Ajoutez un modèle Resource Manager à votre référentiel GitHub. Ce modèle crée un compte de stockage.

https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.json

Vous pouvez placer le fichier n’importe où dans le référentiel. L’exemple de workflow dans la section suivante suppose que le fichier de modèle est nommé azuredeploy.json et qu’il est stocké à la racine de votre référentiel.

Créer un workflow

Le fichier de workflow doit être stocké dans le dossier .github/workflows à la racine de votre référentiel. L’extension du fichier de workflow peut être .yml ou .yaml.

1. À partir de votre référentiel GitHub, sélectionnez Actions dans le menu supérieur.
2. Sélectionnez Nouveau workflow.
3. Sélectionnez Configurer vous-même un workflow.
4. Renommez le fichier de workflow si vous préférez utiliser un autre nom que main.yml. Par exemple : deployStorageAccount.yml.
5. Remplacez le contenu du fichier yml par ce qui suit :

Principal du service

  on: [push]
  name: Azure ARM
  jobs:
    build-and-deploy:
      runs-on: ubuntu-latest
      steps:

        # Checkout code
      - uses: actions/checkout@main

        # Log into Azure
      - uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

        # Deploy ARM template
      - name: Run ARM deploy
        uses: azure/arm-deploy@v1
        with:
          subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
          resourceGroupName: ${{ secrets.AZURE_RG }}
          template: ./azuredeploy.json
          parameters: storageAccountType=Standard_LRS

        # output containerName variable from template
      - run: echo ${{ steps.deploy.outputs.containerName }}

Notes

À la place, vous pouvez spécifier un fichier de paramètres au format JSON dans l’action de déploiement ARM (exemple : .azuredeploy.parameters.json).

La première section du fichier de workflow comprend les éléments suivants :

• nom : Nom du workflow.
• on : nom des événements GitHub qui déclenchent le workflow. Le workflow est déclenché quand il y a un événement push sur la branche primaire, qui modifie au moins l’un des deux fichiers spécifiés. Les deux fichiers sont le fichier de workflow et le modèle de fichier.

OpenID Connect

  on: [push]
  name: Azure ARM
  jobs:
    build-and-deploy:
      runs-on: ubuntu-latest
      steps:

        # Checkout code
      - uses: actions/checkout@main

        # Log into Azure
      - uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

        # Deploy ARM template
      - name: Run ARM deploy
        uses: azure/arm-deploy@v1
        with:
          subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
          resourceGroupName: ${{ secrets.AZURE_RG }}
          template: ./azuredeploy.json
          parameters: storageAccountType=Standard_LRS

        # output containerName variable from template
      - run: echo ${{ steps.deploy.outputs.containerName }}

Notes

À la place, vous pouvez spécifier un fichier de paramètres au format JSON dans l’action de déploiement ARM (exemple : .azuredeploy.parameters.json).

La première section du fichier de workflow comprend les éléments suivants :

• nom : Nom du workflow.
• on : nom des événements GitHub qui déclenchent le workflow. Le workflow est déclenché quand il y a un événement push sur la branche primaire, qui modifie au moins l’un des deux fichiers spécifiés. Les deux fichiers sont le fichier de workflow et le modèle de fichier.

1. Sélectionnez Démarrer la validation.
2. Sélectionnez Valider directement sur la branche primaire.
3. Sélectionnez Valider un nouveau fichier (ou Valider les modifications).

Étant donné que le workflow est configuré pour être déclenché par le fichier de workflow ou le modèle de fichier mis à jour, le workflow démarre juste après la validation des modifications.

Vérifier l’état du workflow

1. Sélectionnez l’onglet Actions. Un flux de travail Create deployStorageAccount.yml est répertorié. L’exécution du workflow prend 1 à 2 minutes.
2. Sélectionnez le workflow pour l’ouvrir.
3. Sélectionnez Exécuter le déploiement ARM dans le menu pour vérifier le déploiement.

Nettoyer les ressources

Lorsque votre groupe de ressource et référentiel ne sont plus nécessaires, nettoyez les ressources que vous avez déployées en supprimant le groupe de ressources et votre référentiel GitHub.

Étapes suivantes

Créer votre premier modèle ARM

Module d’apprentissage : Automatisation du déploiement de modèles ARM avec GitHub Actions