Exercice – Publier une spec de modèle

  • 4 minutes

Votre équipe a créé des fichiers Bicep à la sécurité renforcée conformes au nouveau modèle de gouvernance de votre entreprise. L’un des fichiers Bicep renforcés déploie une application Azure App Service basée sur Linux. Dans cet exercice, vous allez utiliser un workflow de déploiement pour publier le fichier Bicep en tant que spécification de modèle.

Pendant ce processus, vous allez :

  • Ajoutez un travail lint au workflow.
  • Ajoutez un travail de workflow pour publier la spécification de modèle.
  • Exécutez manuellement le workflow et vérifiez qu’il se termine correctement.
  • Vérifiez la spécification de modèle publiée dans Azure.

Ajouter un travail lint à votre workflow

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 template-spec-linux-app-service.yml.

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

    La définition de workflow inclut deux déclencheurs. Dans cet exercice, vous ne modifiez pas le fichier Bicep pour la spécification de modèle, de sorte que le déclencheur push ne se déclenche jamais. Pour tester votre workflow, vous l’appelez manuellement à l’aide du déclencheur workflow_dispatch.

  3. En bas du fichier, où vous voyez un commentaire qui indique # To be added, ajoutez la définition de travail lint suivante :

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

    Votre dépôt a un fichier bicepconfig.json qui configure le linter pour émettre des erreurs au lieu d’avertissements. Tout échec au cours du travail lint entraînera l’échec du workflow.

    Conseil

    Les fichiers YAML sont sensibles à l’indentation. Si vous tapez ou que vous collez ce code, veillez à ce que l’indentation soit correcte. Plus loin dans cet exercice, vous examinerez la définition complète du workflow YAML pour vérifier que votre fichier y correspond.

Ajouter un travail de publication à votre workflow

Vous pouvez maintenant ajouter un deuxième travail pour publier la spécification de modèle sur Azure.

  1. Ajoutez le code suivant à la fin du fichier template-spec-linux-app-service.yml :

    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 }}
  - uses: azure/cli@v1
    name: Publish template spec
    with:
      inlineScript: |
        az ts create \
          --resource-group ${{ env.AZURE_RESOURCEGROUP_NAME }} \
          --name ${{ env.TEMPLATE_SPEC_NAME }} \
          --version ${{ github.run_number }} \
          --template-file ${{ env.TEMPLATE_SPEC_FILE_PATH }} \
          --location ${{ env.AZURE_REGION }} \
          --yes

    Ce travail extrait le code de votre référentiel et se connecte à Azure à l’aide des secrets GitHub que vous avez créés. Elle exécute ensuite la commande az ts create pour publier la spec de modèle sur Azure.

    Conseil

    Pour simplifier les choses, votre workflow utilise le numéro d’exécution du workflow comme numéro de version de la spécification de modèle. Dans l’unité suivante, vous découvrirez un schéma de contrôle de version plus complexe.

  2. Enregistrez les modifications apportées au fichier.

Vérifier et commiter votre définition de workflow

  1. Vérifiez que votre fichier template-spec-linux-app-service.yml ressemble à l’exemple suivant :

    name: template-spec-linux-app-service
concurrency: template-spec-linux-app-service

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'template-specs/linux-app-service/**'

permissions:
  id-token: write
  contents: read

env:
  AZURE_RESOURCEGROUP_NAME: ToyReusable
  AZURE_REGION: westus3
  TEMPLATE_SPEC_NAME: linux-app-service
  TEMPLATE_SPEC_FILE_PATH: template-specs/linux-app-service/main.bicep

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.TEMPLATE_SPEC_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 }}
    - uses: azure/cli@v1
      name: Publish template spec
      with:
        inlineScript: |
          az ts create \
            --resource-group ${{ env.AZURE_RESOURCEGROUP_NAME }} \
            --name ${{ env.TEMPLATE_SPEC_NAME }} \
            --version ${{ github.run_number }} \
            --template-file ${{ env.TEMPLATE_SPEC_FILE_PATH }} \
            --location ${{ env.AZURE_REGION }} \
            --yes

    Si ce n’est pas le cas, modifiez-le d’après cet exemple, puis enregistrez-le.

  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 Linux App Service template spec workflow"
git push

  3. C’est votre premier envoi (push) vers ce dépôt et vous pouvez donc être invité à vous connecter.

    Sur Windows, tapez 1 pour vous authentifier à l’aide d’un navigateur web, puis sélectionnez Entrée.

    Sur macOS, sélectionnez Autoriser.

  4. Une fenêtre de navigateur s’affiche. Vous devrez peut-être vous reconnecter à GitHub. Sélectionnez Autoriser.

Déclencher le workflow

  1. Dans votre navigateur, sélectionnez l’onglet Actions.

    Capture d’écran de GitHub montrant l’onglet Actions.

    Les exécutions de workflow ayant échoué sont déjà répertoriées, mais vous n’avez pas besoin de vous en soucier. Désolé... Nous n’avons pas pu effectuer les exécutions car les définitions de workflow n’étaient pas encore terminées lorsque vous avez créé le référentiel.

  2. Sélectionnez le workflow template-spec-linux-app-service, sélectionnez le bouton Exécuter le workflow, puis sélectionnez Exécuter le workflow.

    Capture d’écran de GitHub montrant les sélections permettant d’exécuter le workflow de la spec de modèle.

    GitHub lance une nouvelle exécution du workflow. Vous devrez peut-être actualiser votre fenêtre de navigateur pour afficher l’exécution.

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

    Capture d’écran de GitHub qui met en surbrillance la dernière exécution du workflow de la spec de modèle.

    Attendez la fin de l’exécution du workflow. La spécification de modèle est alors publiée sur Azure.

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

    Capture d’écran de GitHub montrant une exécution réussie du workflow et met en surbrillance le numéro d’exécution.

Passer en revue la spécification de modèle dans Azure

Vous pouvez également afficher la spécification de modèle publiée dans le Portail Azure.

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

  2. Accédez au groupe de ressources ToyReusable, puis sélectionnez la spécification de modèle linux-app-service.

    Capture d’écran du Portail Azure qui montre le groupe de ressources, avec la spec de modèle mise en surbrillance.

  3. Examinez les détails de la spécification de modèle.

    Capture d’écran du Portail Azure affichant les détails de la spec de modèle.

    Notez que la dernière version et le numéro de version sont identiques au numéro d’exécution du workflow. Votre workflow utilise le numéro d’exécution correspondant au numéro de version de la spécification de modèle.