Exercice – Publier un module dans un registre

  • 5 minutes

Dans votre entreprise de jouets, vous avez publié vos modules Bicep dans un registre. Vous avez exécuté manuellement le processus de publication à partir de votre propre ordinateur. À présent, vous souhaitez créer un workflow pour gérer le processus de publication.

Dans cet exercice, vous allez :

  • Créez un registre de conteneurs pour vos modules Bicep.
  • Ajoutez un travail lint au workflow.
  • Ajoutez un travail de workflow pour publier le module dans votre registre.
  • Vérifiez que votre workflow s’exécute correctement.
  • Vérifiez le module publié dans votre registre.

Créer un registre de conteneur

Avant de pouvoir publier des modules, vous devez créer un registre pour votre organisation. Ici, vous utilisez le Portail Azure pour créer un registre.

  1. Dans votre navigateur, créez un registre de conteneurs dans le Portail Azure.

  2. Sous l’onglet Informations de base, sélectionnez votre abonnement cible et le groupe de ressources ToyReusable que vous avez créé précédemment.

  3. Entrez un nom pour votre registre et un emplacement proche de vous.

    Important

    Le nom du registre doit être unique dans Azure et contenir entre 5 et 50 caractères alphanumériques. Une coche en regard du nom du registre indique que le nom que vous avez choisi est disponible.

  4. Sous Plan tarifaire, sélectionnez Essentiel.

    Conservez les valeurs par défaut pour les autres paramètres de configuration.

  5. Sélectionnez Revoir + créer.

    Capture d’écran du portail Azure montrant la page de création de registre de conteneurs.

  6. Lorsque le message Validation réussie s’affiche, sélectionnez Créer.

    Attendez que le déploiement se termine, ce qui prend généralement 1 à 2 minutes.

  7. Lorsque le message Déploiement réussi s’affiche, sélectionnez Accéder à la ressource pour ouvrir le registre de conteneurs.

    Capture d’écran du portail Azure montrant le déploiement du registre de conteneurs, avec le bouton d’accès à une ressource mis en évidence.

  8. Dans la zone Présentation du registre de conteneurs, notez la valeur du paramètre Serveur de connexion. Le nom ressemble à yourregistryname.azurecr.io.

    Capture d’écran du portail Azure montrant les détails du registre de conteneurs, avec le serveur de connexion mis en évidence.

    Vous aurez besoin de cette valeur dans un instant.

Ajouter un fichier de métadonnées de module

Dans l’unité précédente, vous avez découvert l’importance d’avoir une stratégie de contrôle de version pour vos modules. Vous avez également appris à utiliser des fichiers de métadonnées de module pour spécifier le numéro de version principale et secondaire de votre module dans un workflow. Ici, vous ajoutez un fichier de métadonnées pour votre module de compte de stockage.

  1. Dans Visual Studio Code, développez le dossier modules/storage-account à la racine de votre dépôt.

  2. Créez un fichier appelé metadata.json.

    Capture d’écran de Visual Studio Code montrant l’emplacement du fichier metadata point J S O N.

  3. Ajoutez le contenu suivant au fichier :

    {
  "version": {
    "major": 1,
    "minor": 2
  }
}

    Dans le fichier de métadonnées, vous définissez séparément les numéros de version majeure et mineure. Chaque fois que votre workflow s’exécute, il combine ces numéros avec le numéro d’exécution du workflow pour créer un numéro de version complet.

  4. Enregistrez les modifications apportées au fichier.

Mettre à jour votre définition de workflow et ajouter un travail lint

Votre dépôt contient un brouillon de workflow que vous pouvez utiliser comme point de départ.

  1. Dans Visual Studio Code, développez le dossier .github/workflows à la racine du dépôt.

  2. Ouvrez le fichier module-storage-account.yml.

    Capture d’écran de Visual Studio Code montrant l’emplacement du fichier de définition de workflow.

  3. Mettez à jour la valeur de la variable d’environnement MODULE_REGISTRY_SERVER avec le nom du serveur de votre registre de conteneurs. Vous avez copié ce nom précédemment dans cet exercice.

    Par exemple, si le serveur de connexion de votre registre est votrenomderegistre.azurecr.io, votre code ressemble à cet exemple :

    env:
  MODULE_NAME: storage-account
  MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
  MODULE_FILE_PATH: modules/storage-account/main.bicep
  MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json

  4. En bas du fichier, pour le commentaire # To be added, ajoutez la définition de tâche lint suivante :

    jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.MODULE_FILE_PATH }}

Ajouter un travail de publication à votre workflow

Vous pouvez maintenant ajouter un deuxième travail pour publier le module dans votre registre de conteneurs.

  1. En bas du fichier module-storage-account.yml, ajoutez la première partie de la définition du travail de publication.

    publish:
  runs-on: ubuntu-latest
  needs: [ lint ]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    Les deux étapes initiales dans cette définition consistent à extraire le code de votre référentiel et vous connecter à Azure.

  2. Sous le code que vous venez d’ajouter, ajoutez une autre étape qui lit le numéro de version à partir du fichier metadata.json de votre module et le définit en tant que variable d’environnement.

    - name: Get module version number
  run: |
    majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
    versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
    echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV

    L’étape exécute un script qui utilise l’application de ligne de commande jq pour analyser le fichier JSON.

  3. Après l’étape que vous venez de créer, ajoutez une étape finale pour publier le module dans le registre.

    - uses: azure/cli@v1
  name: Publish module
  with:
    inlineScript: |
      az bicep publish \
        --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
        --file ${{ env.MODULE_FILE_PATH }}

    Cette étape construit dynamiquement la valeur de l’argument --target. Elle combine la valeur du serveur de registre, le nom du module et le numéro de version.

  4. Enregistrez les modifications apportées au fichier.

Vérifier et commiter votre définition de workflow

  1. Vérifiez que votre fichier module-storage-account.yml ressemble à l’exemple suivant :

    name: module-storage-account
concurrency: module-storage-account

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'modules/storage-account/**'

permissions:
  id-token: write
  contents: read

env:
  MODULE_NAME: storage-account
  MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
  MODULE_FILE_PATH: modules/storage-account/main.bicep
  MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.MODULE_FILE_PATH }}

  publish:
    runs-on: ubuntu-latest
    needs: [ lint ]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - name: Get module version number
      run: |
        majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
        versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
        echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV
    - uses: azure/cli@v1
      name: Publish module
      with:
        inlineScript: |
          az bicep publish \
            --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
            --file ${{ env.MODULE_FILE_PATH }}

    Si le contenu de votre fichier est différent, mettez-le à jour pour qu’il corresponde à cet exemple, puis enregistrez le fichier.

  2. Commitez et poussez (push) vos modifications à votre dépôt Git en exécutant les commandes suivantes dans le terminal Visual Studio Code :

    git add .
git commit -m "Add lint and publish jobs to storage account module workflow"
git push

Déclencher le workflow

  1. Dans votre navigateur, accédez à votre dépôt GitHub et sélectionnez l’onglet Actions.

  2. Sélectionnez le workflow module-storage-account.

    Notez qu’une exécution de workflow est déjà en cours. Le déclencheur d’émission a été déclenché, car vous avez modifié le fichier metadata.json dans le dossier du module.

  3. Sélectionnez la dernière exécution dans la liste.

    Capture d’écran de GitHub qui met en évidence la dernière exécution du workflow du module.

    Attendez la fin de l’exécution du workflow. Le module Bicep est publié dans votre registre de conteneurs.

    Notez le numéro d’exécution du workflow, qui est probablement 3.

Passer en revue le module dans le registre

Vous pouvez également afficher le module publié dans le portail Azure.

  1. Dans votre navigateur, accédez au Portail Azure.

  2. Accédez au groupe de ressources ToyReusable.

  3. Dans Ressources, sélectionnez le registre de conteneurs précédemment créé.

  4. Sélectionnez Services>Référentiels à partir du menu. Sélectionnez ensuite le dépôt modules\storage-account, qui représente le module publié par votre workflow.

    Capture d’écran du portail Azure montrant le module Bicep dans le registre de conteneurs.

    Notez qu’il existe une balise unique, qui correspond au numéro de version du module publié par votre workflow. La version principale (1) et la version mineure (2) correspondent aux numéros de version que vous avez définis dans le fichier metadata.json. Le numéro de révision (3) correspond au numéro d’exécution du workflow.

Nettoyer les ressources

Maintenant que vous avez terminé l’exercice, vous pouvez supprimer les ressources afin de ne pas avoir à payer pour.

Dans le terminal Visual Studio Code, exécutez la commande suivante :

az group delete --resource-group ToyReusable --yes --no-wait

Le groupe de ressources est supprimé en arrière-plan.

Remove-AzResourceGroup -Name ToyReusable -Force

Vous pouvez également supprimer le référentiel et les secrets GitHub, ainsi que les identités de charge de travail Azure.

  • Secrets GitHub

    1. Dans le référentiel GitHub, accédez à Paramètres>Secrets et variables>Actions.
    2. Pour chaque secret GitHub enregistré, sélectionnez l’icône Supprimer <nom du secret>, puis suivez les invites.

  • Dépôt GitHub

    1. Accédez à Paramètres>Général.
    2. Sélectionnez Supprimer ce référentiel et suivez les invites.

  • Informations d’identification fédérées et principal de service de l’inscription Azure App.

    1. Dans la page d’accueil du portail, recherchez Microsoft Entra ID et sélectionnez-le dans la liste des Services.
    2. Accédez à Gérer>inscriptions d'applications.
    3. Sous l’onglet Applications détenues, sélectionnez toy-reusable.
    4. Sélectionnez Supprimer et suivez les invites.
    5. Sélectionnez l’onglet Applications supprimées.
    6. Sélectionnez toy-reusable, sélectionnez Supprimer définitivement, puis Oui pour supprimer définitivement l’inscription de l’application.

    Important

    Il est possible d’avoir des noms d’inscription d’application et de principal de service en double. Nous vous recommandons de vérifier l’ID d’application pour veiller à supprimer la ressource appropriée.