Exercice - Générer l’image d’application de production

  • 10 minutes

Dans l’exercice précédent, vous avez généré le workflow de préproduction pour générer et publier l’image d’application. Dans cette unité, vous générez un workflow de production qui utilise le déclencheur de version balisée.

Diagram that shows the procession from triggers, through three build steps, to the deploy steps in a pipeline.

Dans cet exercice, vous allez :

  • Générer le workflow Actions.
  • Créer le déclencheur on tag.
  • Générer et envoyer (push) l’image de production.
  • Générer un jeton d’accès personnel (PAT).
  • Déclencher l’événement de balisage.

Créer le workflow GitHub Actions

  1. Pour commencer à générer le pipeline, accédez à votre duplication (fork) de l’exemple de dépôt sur le site web GitHub et sélectionnez l’onglet Actions.

  2. Dans le volet gauche, sélectionnez Nouveau workflow.

    Screenshot that shows the New workflow button on the GitHub Actions page.

  3. Dans la page Choisir un workflow, sélectionnez Configurer un workflow vous-même.

  4. Copiez et collez le workflow de base dans le volet d’édition :

    # This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

  5. Au-dessus du volet d’édition, remplacez le nom du fichier main.yml par build-production.yml.

  6. Changez la clé name de CI en Build and push the tagged build to production.

Créer le déclencheur de balisage

Modifiez les déclencheurs par défaut dans la clé on.

  1. Supprimez le deuxième déclencheur de façon à ne laisser que les étiquettes push.

  2. Remplacez la clé branches par la clé tags suivante. Cette clé signifie que le workflow s’exécute uniquement sur des balises spécifiques. Dans ce cas, le workflow ne s’exécute que si l’étiquette suit le modèle v*, qui inclut v1.0.0.

    name: Build and push the tagged build to production

on:
  push:
    tags:
      - 'v*'

Configurer l’étape d’extraction

  1. Comme dans l’exercice précédent :

    • Changez la clé jobs de ubuntu-latest en ubuntu-20.04.
    • Renommez la clé build en utilisant le nom build_push_image.
    • Dans la clé steps, supprimez les deux derniers exemples d’étape du modèle et conservez l’option checkout.

  2. Créez une nouvelle étape qui regroupe les informations de version nécessaires. Vous utilisez la commande interne ::set-output pour créer cette étape. Ajoutez les lignes suivantes sous l’action Validation :

    - name: Fetch latest version
  id: fetch_version
  run: echo ::set-output name=TAG::${GITHUB_REF#refs/tags/}

    Votre fichier YAML, sans les commentaires, doit ressembler à l’exemple suivant :

    name: Build and push the tagged build to production

on:
  push:
    tags:
      - 'v*'

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

      - name: Fetch latest version
        id: fetch_version
        run: echo ::set-output name=TAG::${GITHUB_REF#refs/tags/}

Ajouter des étapes Docker

Comme pour le workflow intermédiaire, ajoutez les étapesDocker Login et Build and push Docker images.

  1. Dans le panneau droit, recherchez Connexion Docker. Sélectionnez le premier résultat publié par Docker.

  2. Sous Installation, sélectionnez l’icône de copie pour copier le YAML d’utilisation.

  3. Collez le code YAML copié sous l’action Fetch latest version.

  4. Ajoutez les valeurs suivantes aux clés registry, username et password :

    • registry : ${{ secrets.ACR_NAME }}
    • username : ${{ secrets.ACR_LOGIN }}
    • password : ${{ secrets.ACR_PASSWORD }}

  5. Supprimez toutes les autres clés, car elles ne sont pas utilisées dans cet exercice.

  6. Dans le volet droit sous Place de marché, recherchez générer et envoyer des images Docker et sélectionnez le premier résultat publié par Docker.

  7. Sous Installation, sélectionnez l’icône de copie pour copier le YAML d’utilisation.

  8. Collez le code YAML copié sous la dernière clé de l’action docker-login précédemment copiée.

  9. Renommez la clé name de Build and push Docker images en Build and push production images.

  10. Ajoutez les valeurs suivantes aux clés context, push et tags :

    • context : .
    • push : true
    • tags : ${{secrets.ACR_NAME}}/contoso-website:latest,${{secrets.ACR_NAME}}/contoso-website:${{ steps.fetch_version.outputs.TAG }}

    Notez que la valeur de la clé tags diffère du workflow intermédiaire. L’utilisation de steps. dans YAML est une pratique courante pour faire référence aux étapes précédentes dans le pipeline. Quand vous avez utilisé set-output à l’étape fetch_version, vous avez défini la sortie de l’étape sur la valeur de la variable GITHUB_REF. Cette sortie est désormais disponible dans le pipeline à l’intérieur de l’objet steps.

  11. Supprimez toutes les autres clés, car elles ne sont pas utilisées dans cet exercice.

  12. Ajoutez une autre action nommée docker/setup-buildx-action entre l’action d’extraction et l’action de connexion, afin de configurer le moteur de génération que Docker doit utiliser. Copiez l’extrait de code suivant et collez-le entre les actions checkout et login.

    - name: Set up Buildx
  uses: docker/setup-buildx-action@v3.0.0

    Votre fichier YAML, sans les commentaires, doit ressembler à l’exemple suivant :

    name: Build and push the tagged build to production

on:
  push:
    tags:
      - 'v*'

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

      - name: Fetch latest version
        id: fetch_version
        run: echo ::set-output name=TAG::${GITHUB_REF#refs/tags/}

      - name: Set up Buildx
        uses: docker/setup-buildx-action@v3.0.0

      - name: Docker Login
        uses: docker/login-action@v3.0.0
        with:
          registry: ${{ secrets.ACR_NAME }}
          username: ${{ secrets.ACR_LOGIN }}
          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push production images
        uses: docker/build-push-action@v5.0.0
        with:
          context: .
          tags: ${{secrets.ACR_NAME}}/contoso-website:latest,${{secrets.ACR_NAME}}/contoso-website:${{ steps.fetch_version.outputs.TAG }}
          push: true

Valider les modifications

Pour valider vos modifications, sélectionnez le bouton Commiter les modifications en bas. Entrez une description du commit, puis sélectionnez Commiter les modifications.

Cette fois, l’action de production ne se déclenche pas, car vous n’avez pas envoyé de nouvelle balise, mais l’action intermédiaire précédente se déclenche et génère une nouvelle image latest.

Générer un jeton d’accès personnel (PAT)

Vous avez besoin d’un PAT pour envoyer vos balises à l’étape suivante et pour exécuter le script de déploiement lors d’une unité ultérieure.

  1. Accédez à la duplication (fork) de l’exemple de dépôt du site web GitHub. En haut à droite, sélectionnez votre photo de profil, puis Paramètres.

  2. En bas du menu de gauche, sélectionnez Paramètres du développeur.

  3. Sélectionnez Jetons d’accès personnels>Jetons (classique) dans la liste déroulante.

  4. Sélectionnez Générer un jeton d’accès personnel.

  5. Sous Remarque, spécifiez un nom pour votre PAT, tel que myPersonalAccessToken.

  6. Sous Sélectionner des étendues, cochez la case en regard de workflow.

    Screenshot that shows the personal access tokens page.

    Remarque

    L’étendue du flux de travail accorde au référentiel d’administration l’accès aux actions Github. Vous avez besoin de cet accès pour envoyer vos balises à l’étape suivante et pour exécuter le script de déploiement lors d’une unité ultérieure.

  7. Sélectionnez Générer un jeton en bas de la page.

  8. Sélectionnez l’icône de copie pour copier votre PAT. Enregistrez le PAT en vue de son utilisation lors des étapes ultérieures.

    Screenshot that shows the personal access token after it's created.

Déclencher l’événement de balisage

  1. Dans Azure Cloud Shell, accédez à votre dépôt cloné et exécutez git pull.

  2. Exécutez la commande suivante :

    git tag -a v2.0.0 -m 'My first tag'

  3. Exécutez la commande suivante : À l’invite, indiquez votre PAT comme mot de passe.

    git push --tags

    Important

    Le dépôt d’origine utilise v1.0.0. Vous devez donc envoyer (push) une balise différente, car les doublons ne peuvent pas exister.

  4. Sélectionnez l’onglet Actions et vérifiez le processus en cours d’exécution.

  5. Une fois le processus terminé, exécutez la commande suivante dans Cloud Shell, en remplaçant <ACR_NAME> par votre ACR_NAME, afin de vérifier que deux balises figurent dans les résultats.

    az acr repository show-tags --repository contoso-website --name <ACR_NAME> -o table

Passez à l’unité suivante pour en savoir plus sur l’utilisation de Helm, un outil d’empaquetage pour les applications Kubernetes, afin d’automatiser votre pipeline.