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

Article
09/26/2024

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

Principal du service
OpenID Connect

Créez un principal de service à l’aide de la commande az ad sp create-for-rbac dans Azure CLI. Exécutez cette commande en utilisant Azure Cloud Shell dans le portail Azure ou en sélectionnant le bouton Essayer.

az ad sp create-for-rbac --name "myML" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name> \
                            --json-auth

Le paramètre --json-auth est disponible dans les versions d’Azure CLI >= 2.51.0. Les versions antérieures à celle-ci utilisent --sdk-auth avec un avertissement de dépréciation.

Dans l’exemple ci-dessus, remplacez les espaces réservés par votre ID d’abonnement, le nom de votre groupe de ressources et le nom de votre application. La sortie correspond à un objet JSON avec les informations d’identification de l’attribution de rôle qui fournit l’accès à votre application App Service, similaire à ce qui suit. Copiez cet objet JSON pour une version ultérieure.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    (...)
  }

OpenID Connect est une méthode d’authentification qui utilise des jetons de courte durée. La configuration d’OpenID Connect avec GitHub Actions est un processus plus complexe qui offre une sécurité renforcée.

Si vous n’avez pas d’application existante, inscrivez une nouvelle application Microsoft Entra et un principal de service pouvant accéder aux ressources.
```
az ad app create --display-name myApp
```
Cette commande affiche une sortie JSON avec un appId qui est votre client-id. Le objectId est APPLICATION-OBJECT-ID et il sera utilisé pour créer des informations d’identification fédérées avec des appels d’API Graph. Enregistrez la valeur à utiliser comme secret GitHub AZURE_CLIENT_ID ultérieurement.
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.

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
```
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 et $assigneeObjectId par le assignee-object-id généré (l’identifiant de l’objet du principal de service nouvellement créé).
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName
```
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 l’objectId (généré lors de la création de l’application) pour votre application Microsoft Entra.
- Définissez une valeur pour CREDENTIAL-NAME que vous référencerez ultérieurement.
- Définissez subject. Cette 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:octo-org/octo-repo:environment:Production",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}
```

Dans GitHub, accédez à votre dépôt.
Sélectionnez Paramètres dans le volet de navigation.
Sélectionnez Sécurité > Secrets et variables > Actions.
Sélectionnez New repository secret (Nouveau secret de dépôt).
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.
Sélectionnez Ajouter un secret.

Vous devez fournir l’ID de client, l’ID de 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.

Dans GitHub, accédez à votre dépôt.
Sélectionnez Sécurité > Secrets et variables > Actions.
Sélectionnez New repository secret (Nouveau secret de dépôt).
Créez des secrets pour AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID. Utilisez ces valeurs à partir de votre application Microsoft Entra pour vos secrets GitHub :

Secret GitHub Application Microsoft Entra

AZURE_CLIENT_ID ID d’application (client)

AZURE_TENANT_ID ID de l’annuaire (locataire)

AZURE_SUBSCRIPTION_ID Identifiant d’abonnement
Enregistrez chaque secret en sélectionnant Ajouter un secret.

Secret GitHub	Application Microsoft Entra
AZURE_CLIENT_ID	ID d’application (client)
AZURE_TENANT_ID	ID de l’annuaire (locataire)
AZURE_SUBSCRIPTION_ID	Identifiant d’abonnement

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.

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

Principal du service
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:
          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.

  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.

Sélectionnez Démarrer la validation.
Sélectionnez Valider directement sur la branche primaire.
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

Sélectionnez l’onglet Actions. Un flux de travail Create deployStorageAccount.yml est répertorié. L’exécution du workflow prend 1 à 2 minutes.
Sélectionnez le workflow pour l’ouvrir.
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

Partager via