Créer un artefact avec GitHub Actions

Introduction

Dans le lab précédent, vous avez découvert le « contrôle qualité » (CI). Passons maintenant à l’étape suivante : l’empaquetage.

Imaginez que le logiciel soit un produit fabriqué en usine. Après avoir passé tous les tests de qualité, il doit être placé dans une boîte, scellé et étiqueté avant d’être expédié aux clients. Dans le monde du logiciel, cette « boîte » est souvent un conteneur Docker.

Nous appelons le résultat ainsi empaqueté un artefact. Une fois créés, les artefacts doivent être stockés dans un registre afin que les étapes suivantes, comme le déploiement, puissent récupérer exactement la même version.

Cette reproductibilité est essentielle. Le déploiement doit utiliser un produit connu, et non recréer le code différemment sur chaque machine cible.

GitHub fournit un registre appelé GitHub Container Registry (GHCR).

Dans ce lab, vous allez apprendre à votre assistant robot à :

Empaqueter votre application dans un conteneur Docker.
L’étiqueter avec un tag de version.
L’expédier (la publier) automatiquement dans l’entrepôt GitHub.

Prérequis

Nous allons continuer à utiliser le dépôt github-actions-basics.

Créer un Dockerfile

Avant que le robot puisse empaqueter votre application, il a besoin d’instructions. Dans Docker, ces instructions sont écrites dans un fichier spécial appelé Dockerfile.

Accédez au répertoire du projet.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Remarque : remplacez your-username par votre véritable nom d’utilisateur GitHub.

Créez un fichier nommé Dockerfile (avec un « D » majuscule et sans extension) contenant le contenu suivant.

cat > Dockerfile << EOF
FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "index.js"]
EOF

Voici précisément ce que cette liste d’empaquetage demande au robot de faire :

FROM node:16-alpine : commencer avec un système de base léger sur lequel Node.js est déjà installé ;
WORKDIR /app : créer un répertoire de travail à l’intérieur de la boîte ;
COPY ... : copier les fichiers de notre projet dans la boîte ;
RUN npm install : installer les dépendances nécessaires à l’intérieur de la boîte ;
CMD ... : démarrer l’application lorsqu’une personne ouvre (exécute) cette boîte.

Ajoutez maintenant ce fichier à votre dépôt et envoyez-le sur GitHub.

git add Dockerfile
git commit -m "Add Dockerfile"
git push

Créer le workflow de publication

Nous allons maintenant créer un nouveau workflow chargé de l’empaquetage et de l’expédition. Nous l’appellerons docker-publish.yml.

Créez le fichier :

touch .github/workflows/docker-publish.yml

Ouvrez-le avec nano.

nano .github/workflows/docker-publish.yml

Ajoutez la configuration suivante. Nous introduisons ici un nouveau concept appelé permissions.

name: Docker Publish

on:
  push:
    branches: ["master", "main"]

permissions:
  contents: read
  packages: write

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

Pourquoi avons-nous besoin de permissions ?

Par défaut, le robot dispose d’un accès limité pour des raisons de sécurité. Comme nous voulons qu’il téléverse des éléments dans votre compte GitHub, dans la section « packages », nous devons lui donner explicitement une clé pour accéder à l’entrepôt. C’est le rôle de packages: write.

Il s’agit d’un bon exemple du principe du moindre privilège dans la conception des pipelines. Les workflows doivent recevoir uniquement les permissions nécessaires à la tâche qu’ils exécutent.

Enregistrez le fichier et quittez nano (Ctrl+X, Y, Enter).

Ajouter les étapes de création et de publication

Vérifions maintenant la partie la plus intéressante : la création et la publication proprement dites.

Nous utiliserons deux outils officiels (actions) de Docker :

docker/login-action : pour se connecter à l’entrepôt ;
docker/build-push-action : pour créer la boîte et l’expédier.

Cette étape fait le lien entre l’intégration continue et la livraison. Une fois les tests réussis, le pipeline crée un artefact versionné que d’autres systèmes pourront ensuite déployer sans recréer le logiciel à partir du code source.

Ouvrez à nouveau .github/workflows/docker-publish.yml.

nano .github/workflows/docker-publish.yml

Ajoutez les étapes suivantes au job build-and-push :

- name: Log in to the Container registry
  uses: docker/login-action@v2
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}

- name: Build and push Docker image
  uses: docker/build-push-action@v4
  with:
    context: .
    push: true
    tags: ghcr.io/${{ github.repository }}/app:latest

Comprendre les variables spéciales :

ghcr.io : c’est l’adresse de l’« entrepôt » de GitHub.
${{ github.actor }} : cette variable renseigne automatiquement votre nom d’utilisateur GitHub.
${{ secrets.GITHUB_TOKEN }} : il s’agit d’un mot de passe temporaire spécial que GitHub crée pour le robot. Vous n’avez rien à faire : cela fonctionne automatiquement ! Ce jeton permet au robot de se connecter de manière sécurisée sans que vous ayez à saisir votre mot de passe.
tags : cette propriété crée l’étiquette de votre boîte. Elle suit le format : Adresse de l’entrepôt / Votre nom / Nom du dépôt / Nom de l’application : Version.

Enregistrez le fichier et quittez nano.

Envoyez maintenant ce workflow sur GitHub pour démarrer le processus.

git add .
git commit -m "Add Docker publishing workflow"
git push

Vérifier l’artefact

Votre robot travaille maintenant activement. Il configure un serveur, se connecte, crée votre conteneur et le téléverse.

Accédez à votre dépôt sur GitHub.
Cliquez sur l’onglet Actions.
Cliquez sur l’exécution du workflow « Docker Publish ».
Observez les étapes passer au vert.

Docker Publish

Une fois l’étape « Build and push Docker image » terminée avec succès, votre package se trouve dans l’entrepôt. Allons le vérifier.

Accédez à la page principale de votre dépôt, dans l’onglet Code.
Regardez la barre latérale droite. Vous devriez voir une section intitulée Packages.
Un nouveau package doit y être répertorié.

Cliquez sur le nom du package pour afficher ses détails. Il s’agit de votre artefact finalisé. Toute personne ayant accès à votre dépôt — ou le public si votre dépôt est public — peut maintenant télécharger et exécuter votre application à l’aide de cette image.

GitHub Packages

Résumé

Dans ce lab, vous avez créé un pipeline de livraison complet.

Vous avez appris :

Empaquetage : écrire un Dockerfile pour placer votre application dans un conteneur ;
Permissions : accorder à votre workflow un accès en écriture à vos packages ;
Stockage : utiliser GitHub Container Registry (GHCR) pour stocker vos images ;
Automatisation : créer et expédier automatiquement votre code à l’aide d’actions standard.

Votre assistant robot sait désormais vérifier votre code (CI) et expédier votre code sous forme d’artefacts. Dans le prochain lab, nous verrons comment gérer de manière sécurisée les informations sensibles, comme les mots de passe.

Création d’un artefact