Exercice : générer l’image de l’application
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 :
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.
À 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
deCI
enBuild 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
enbuild_push_image
.Vous souhaitez que ce workflow s’exécute sur Ubuntu 20.04. Changez donc la clé
runs-on
deubuntu-latest
enubuntu-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
etpassword
: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
deBuild and push Docker images
enBuild and push staging images
.Ajoutez les valeurs suivantes aux clés
context
,push
ettags
: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 actionscheckout
etlogin
.- 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.
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
: ValeurACR_Name
retournée par le script d’installationACR_LOGIN
: ValeurACR Login Username
retournée par le script d’installationACR_PASSWORD
: ValeurACR Login Password
retournée par le script d’installationRESOURCE_GROUP
: ValeurResource Group Name
retournée par le script d’installationCLUSTER_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 Registrycontoso-website
apparaît dans les résultats.
Passez à l’unité suivante pour générer votre workflow de production.