Exercice : générer l’image de l’application

10 minutes

Dans cette unité, vous créez votre pipeline intermédiaire GitHub Actions en créant l’image de l’application et en l’envoyant (push) à Azure Container Registry.

L’image suivante montre le pipeline CI/CD que vous avez conçu :

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

Dans cet exercice, vous créez le pipeline intermédiaire en effectuant la procédure suivante :

Créez le workflow GitHub Actions.
Créez le déclencheur on push.
Générez et envoyez (push) l’image de l’application.
Définissez des secrets.
Exécutez le travail.

Créer le workflow GitHub Actions

Les workflows GitHub sont divisés en travaux, et les travaux en étapes. Chaque étape peut avoir plusieurs commandes et utiliser de nombreuses actions à exécuter.

Pour commencer à générer votre pipeline, accédez à votre duplication (fork) de l’exemple de référentiel du site web GitHub.

Sélectionnez l’onglet Actions.

Sélectionnez le lien pour Configurer vous-même un workflow.

Screenshot that shows the Get started with GitHub Actions page on the GitHub website.

À ce stade, le pipeline consiste en un simple fichier vide dans le répertoire .github/workflows de votre référentiel. GitHub fournit les composants prédéfinis nécessaires pour générer la plupart des pipelines. Pour démarrer, copiez et collez le code suivant dans le volet Modifier le nouveau fichier :

# 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.

Au-dessus du volet Modifier le nouveau fichier, renommez le fichier de main.yml en build-staging.yml.

Changez la clé name de CI en Build and push the latest build to staging.

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

name: Build and push the latest build to staging

Modifier le déclencheur « on »

Notre modèle de workflow de base est fourni avec deux déclencheurs :

N’importe quel envoi (push) étiqueté dans la branche principale
N’importe quelle demande de tirage (pull request) sur la branche principale

Vous n’avez pas besoin que le pipeline s’exécute sur une demande de tirage (pull request). Modifiez-le pour conserver uniquement le déclencheur push en modifiant les déclencheurs dans la clé on. Supprimez le deuxième déclencheur de façon à ne laisser que les étiquettes push.

name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

Configurer l’étape d’extraction

Ensuite, commencez à travailler sur les étapes du travail. Dans ce processus, vous implémentez les tâches de génération et les tâches de déploiement dans votre diagramme de conception de pipeline.

Sous jobs, renommez la clé build en build_push_image.
Vous souhaitez que ce workflow s’exécute sur Ubuntu 20.04. Changez donc la clé runs-on de ubuntu-latest en ubuntu-20.04.

Supprimez les deux dernières commandes dans la clé steps qui ne sont que des exemples tirés du modèle.

Votre fichier, sans les commentaires, doit ressembler à cet exemple :

name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

Vous disposez maintenant d’une étape qui utilise l’action checkout. Celle-ci a pour effet de cloner le référentiel dans l’environnement du travail. Cette étape est équivalente à la première action Cloner le dépôt dans le diagramme de conception du pipeline.

Ajouter des étapes Docker

Ajoutez ensuite des actions pour générer votre image Docker. Vous pouvez ajuster l’utilisation pour ces actions. Cet exemple utilise uniquement quelques-uns des paramètres disponibles. Pour plus d’informations, consultez la documentation GitHub build-push-action.

Sous l’onglet Place de marché dans le volet droit, recherchez la connexion Docker, puis sélectionnez le premier résultat publié par Docker.

Remarque

Les actions Docker antérieures à la version 2 avaient le flux de connexion intégré, mais sur les versions 2 et ultérieures, ces actions sont séparées. Vous avez donc besoin de deux actions pour définir le workflow correctement.
Sous Installation, sélectionnez l’icône de copie pour copier le YAML d’utilisation.
Collez le code YAML copié sous l’action actions/checkout@v2.

Important

Faites attention à la mise en retrait avec YAML. La clé name doit être alignée sur la clé uses précédente.
Ajoutez les valeurs suivantes aux clés registry, username et password :
- registry : ${{ secrets.ACR_NAME }}
- username : ${{ secrets.ACR_LOGIN }}
- password : ${{ secrets.ACR_PASSWORD }}
Supprimez les autres clés, car elles ne sont pas utilisées dans cet exercice.
Dans le volet droit sous Place de marché, recherchez générer et envoyer (push) des images Docker, puis sélectionnez le premier résultat publié par Docker.
Sous Installation, sélectionnez l’icône de copie pour copier le YAML d’utilisation.
Collez le code YAML copié sous la dernière clé de l’action docker-login précédemment copiée.
Renommez la clé name de Build and push Docker images en Build and push staging images.
Ajoutez les valeurs suivantes aux clés context, push et tags :
- context : .
- push : true
- tags : ${{secrets.ACR_NAME}}/contoso-website:latest
Supprimez les autres clés, car elles ne sont pas utilisées dans cet exercice.

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 final, sans les commentaires, doit ressembler à l’exemple suivant :

name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

      - 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 staging images
        uses: docker/build-push-action@v5.0.0
        with:
          context: .
          push: true
          tags: ${{secrets.ACR_NAME}}/contoso-website:latest

Valider les modifications

Pour valider vos modifications, sélectionnez le bouton Valider les modifications en haut à droite. Dans l’écran Valider les modifications, entrez une description de la validation, puis sélectionnez Valider les modifications.

Screenshot that shows the Commit changes button in the Commit changes pane.

La sélection de Valider les modifications déclenche une nouvelle génération, mais elle échoue car vous n’avez pas encore défini les secrets.

Définir les secrets

Pour définir les secrets, sur la page de votre référentiel GitHub, sélectionnez l’onglet Paramètres, puis Secrets et variables>Actions dans le menu de gauche. Définissez les secrets suivants que votre workflow utilise :

ACR_NAME : Valeur ACR_Name retournée par le script d’installation
ACR_LOGIN : Valeur ACR Login Username retournée par le script d’installation
ACR_PASSWORD : Valeur ACR Login Password retournée par le script d’installation
RESOURCE_GROUP : Valeur Resource Group Name retournée par le script d’installation
CLUSTER_NAME : contoso-video

Pour définir chaque secret :

Sélectionnez New repository secret (Nouveau secret de dépôt).
Pour le Nom, entrez le nom du secret de la liste précédente.
Pour le Secret, entrez la valeur enregistrée à partir du script d’installation ou exécutez une requête Cloud Shell pour obtenir la valeur.
Sélectionnez Ajouter un secret.

Exécuter des requêtes facultatives pour obtenir les valeurs de secrets

Si le script d’installation ne retourne pas les valeurs, vous pouvez exécuter les commandes suivantes dans Azure Cloud Shell pour obtenir les informations :

ACR_NAME :

az acr list --query "[?contains(resourceGroup, 'mslearn-gh-pipelines')].loginServer" -o table

ACR_LOGIN :

az acr credential show --name <ACR_NAME> --query "username" -o table

ACR_PASSWORD :

az acr credential show --name <ACR_NAME> --query "passwords[0].value" -o table

RESOURCE_GROUP :

az aks list -o tsv --query "[?name=='contoso-video'].resourceGroup"

Exécuter le travail

Sélectionnez l’onglet Actions.
Sélectionnez la seule exécution dans la liste, le travail build-staging.yml ayant échoué.
En haut à droite, sélectionnez Réexécuter les travaux>Réexécuter tous les travaux, puis dans l’écran Réexécuter tous les travaux, sélectionnez Réexécuter les travaux.
Une fois la génération terminée, exécutez az acr repository list --name <ACR_NAME> -o table dans Cloud Shell pour vérifier que le référentiel Container Registry contoso-website apparaît dans les résultats.

Passez à l’unité suivante pour générer votre workflow de production.

Continuer