Gérer des images Docker Node.js dans GitHub Packages avec GitHub Actions

Si vous développez des logiciels open source aujourd’hui, il y a de fortes chances que vous soyez actif au sein de la communauté GitHub, en participant à des projets open source et à leurs dépôts. Un ajout récent à l’écosystème GitHub est GitHub Packages, annoncé en 2019 et qui bénéficie désormais de nouvelles mises à jour avec la disponibilité générale du registre de conteneurs GitHub Packages. Cela signifie que nous pouvons publier et récupérer des images basées sur Docker, ainsi que tout autre format compatible avec OCI, entièrement au sein de l’écosystème GitHub.

Dans cet article, je vais vous présenter pas à pas un workflow GitHub Actions. Vous apprendrez à publier des projets Node.js sous forme d’images Docker, puis à les envoyer vers le registre de conteneurs GitHub Packages.

Avant de commencer, saviez-vous qu’il existe un forum d’assistance dédié aux utilisateurs de GitHub, appelé GitHub Support Community ? N’hésitez pas à le consulter si vous avez besoin d’aide.

Le projet Node.js que nous utiliserons dans cet article est dockly, un outil en ligne de commande open source pour Node.js qui fournit une interface immersive dans le terminal pour gérer des conteneurs et des services Docker.

Créer un workflow GitHub Actions

Accédez à votre dépôt open source sur GitHub, cliquez sur l’onglet Actions, puis sur New Workflow et set up a workflow yourself. Vous devriez voir ceci :

Commencez par définir le nom du fichier de workflow : docker-publish.yml, ou toute autre convention de nommage de votre choix.

GitHub peut préremplir le code du workflow. Si c’est le cas, supprimez-le et collez le code suivant :

1name: Docker
2
3# This workflow uses actions that are not certified by GitHub.
4# They are provided by a third-party and are governed by
5# separate terms of service, privacy policy, and support
6# documentation.
7
8on:
9  push:
10    branches: [ main ]
11    tags: [ 'v*.*.*' ]
12  pull_request:
13    branches: [ main ]
14
15env:
16  REGISTRY: ghcr.io
17  IMAGE_NAME: ${{ github.repository }}

Le workflow ci-dessus définit les conventions suivantes :

• Le workflow s’exécute uniquement lors des commits sur la branche main ou des pull requests vers la branche main. Remarque : Si votre dépôt utilise l’ancienne convention de branche master, remplacez son nom ici et dans le reste de l’extrait de code. Le workflow s’exécute également à chaque envoi de balises au dépôt au format semver <v*.*.*>, ce qui est pratique, car nous pouvons alors publier des images Docker pour chaque version.

• Il garantit que la publication d’une nouvelle image Docker crée également des balises dans le dépôt GitHub.

• Il définit des variables d’environnement globales pour les autres tâches du workflow, qui pointent vers GitHub Container Registry (ghcr.io), et définit le nom de l’image Docker selon les conventions habituelles de Docker Hub, comme <user>/<repo>, par exemple lirantal/nodejs-app.

Définissons ensuite nos tâches, qui mettront en place le processus de création de l’image Docker, puis de sa publication.

Créer une image Docker dans le cadre du workflow GitHub Actions

Pour publier des images Docker sur le registre de conteneurs GitHub Packages (ou même simplement sur GitHub), nous devons d’abord nous authentifier avec un compte valide. La première étape de la tâche de création et de publication consiste donc à se connecter.

Ajoutez le code suivant à la suite du code précédent :

1jobs:
2  build_and_publish:
3
4    runs-on: ubuntu-latest
5    permissions:
6      contents: read
7      packages: write
8
9    steps:
10      - name: Checkout repository
11        uses: actions/checkout@v2
12
13      - name: Log into registry ${{ env.REGISTRY }}
14        if: github.event_name != 'pull_request'
15        uses: docker/login-action@28218f9b04b4f3f62068d7b6ce6ca5b26e35336c
16        with:
17          registry: ${{ env.REGISTRY }}
18          username: ${{ github.repository_owner }}
19          password: ${{ secrets.GITHUB_TOKEN }}
20
21      - name: Extract Docker metadata
22        id: meta
23        uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
24        with:
25          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

Examinons les actions effectuées par les tâches décrites ici :

1. La première étape consiste à extraire le code source du dépôt.

2. Nous nous authentifions ensuite auprès du registre de conteneurs GitHub Packages. Comme vous pouvez le voir, nous réutilisons la variable d’environnement REGISTRY définie précédemment, qui pointe vers ghcr.io, le registre d’images de conteneurs de GitHub.

   Le nom d’utilisateur utilisé pour l’authentification est celui de la personne qui a lancé le workflow ; il doit correspondre à votre nom d’utilisateur en tant que propriétaire du dépôt. Le mot de passe utilise GITHUB_TOKEN, mis automatiquement à la disposition des workflows GitHub Actions. Vous n’avez pas besoin de l’ajouter manuellement comme secret ou variable d’environnement dans le dépôt. Notez que la connexion au registre n’a pas lieu pour une pull request : elle n’est de toute façon pas nécessaire et pourrait exposer des informations sensibles dans l’intégration continue des pull requests et des forks.

3. La dernière étape de l’extrait de code ci-dessus extrait les métadonnées de l’image et les met à disposition du processus de création de l’image Docker (notre prochaine et dernière étape de ce workflow !). Ces métadonnées contiennent des informations sur les balises et les libellés, accessibles à l’action de création Docker. Plus précisément, l’entrée images définit l’image Docker à utiliser comme nom de base pour les balises.

Créer une image Docker et la publier dans le registre de conteneurs GitHub Packages

La dernière étape consiste à créer l’image Docker et à la publier. Il s’agit d’une étape unifiée qui utilise une action prenant en charge ces deux opérations. Notez toutefois que nous avons défini l’entrée push de ce workflow à l’aide d’une condition : la publication de l’image dans le registre n’est tentée que si l’événement n’est pas déclenché par une pull request :

1      - name: Build and push Docker image
2        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
3        with:
4          context: .
5          push: ${{ github.event_name != 'pull_request' }}
6          tags: ${{ steps.meta.outputs.tags }}
7          labels: ${{ steps.meta.outputs.labels }}

Et voilà.

Une fois le workflow enregistré (en respectant l’indentation !) et déclenché en fusionnant ce workflow dans la branche main, il devrait créer une image et la publier dans le registre de conteneurs GitHub Packages.

Si tout s’est bien passé, vous devriez voir la coche verte tant attendue indiquant que la tâche a réussi, comme ici :

Comment envoyer une image Docker vers le registre de conteneurs GitHub Packages ?

Utilisez l’action Docker officielle pour GitHub, docker/build-push-action, dans votre fichier de workflow GitHub Actions et assurez-vous qu’une variable d’environnement REGISTRY est définie sur ghcr.io.

Récupérer des images Docker depuis le registre de conteneurs GitHub Packages

Maintenant que notre projet a une image Docker publiée dans un registre public, testons-la en la récupérant depuis notre environnement de développement local :

1$ docker pull ghcr.io/lirantal/my-nodejs-app
2Using default tag: latest
3latest: Pulling from lirantal/my-nodejs-app
4b4d181a07f80: Pulling fs layer
5de8ecf497b75: Pulling fs layer
669b92f9e5e70: Pulling fs layer
71f2b8e2c8ad8: Waiting
8d0f4259cb643: Waiting
99ae47f3f99ba: Waiting
1087270829eb60: Waiting
11905fc634546c: Waiting

Comment préciser la version des images Docker à récupérer ?

La commande docker pull accepte un argument supplémentaire au format <registry>/<user>/<repo>:<image tag>. Par exemple, pour récupérer la balise d’image Docker « latest » du registre de conteneurs GitHub Packages pour l’image my-nodejs-app image, utilisez la commande suivante : docker pull ghcr.io/lirantal/my-nodejs-app

Hourra, ça marche !

Mais attendez… n’existe-t-il pas un moyen plus simple d’afficher les images Docker que j’envoie vers GitHub Packages ? Ne cherchez plus !

Trouver des images Docker dans GitHub Packages

Rendez-vous sur votre page de profil GitHub (par exemple la mienne : https://github.com/lirantal?tab=packages) pour voir toutes vos images Docker accessibles au public.

Si vous avez suivi ce tutoriel pour créer votre propre image Docker, pouvez-vous la retrouver ? Voici la page du paquet d’image Docker que j’ai envoyé vers GitHub Packages dans le cadre de l’intégration continue GitHub Actions du dépôt :

La balise latest est absente de l’image Docker publiée ?

Si vous avez essayé de récupérer l’image Docker par son nom, sans préciser la balise de l’image Docker pour la branche main ou master que vous utilisez, vous avez peut-être constaté que la balise Docker courante latest n’est pas disponible. Cela se produit si aucune balise semver (versionnement sémantique) n’a été envoyée. Vous en envoyez peut-être dans votre propre dépôt ; elles seront alors disponibles.

Pour imposer l’alias de balise Docker latest dans l’image publiée, nous pouvons mettre à jour l’action de métadonnées comme suit (remarquez la clé flavor supplémentaire sur plusieurs lignes) :

1      - name: Extract Docker metadata
2        id: meta
3        uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
4        with:
5          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
6          flavor: |
7            latest=true
8            prefix=
9            suffix=

Notez toutefois que cela définira toujours une balise d’image latest comme alias de l’image Docker publiée lorsqu’un travail d’intégration continue est déclenché par la branche main.

Comment attribuer la balise latest à une image Docker ?

Pour baliser localement une image créée précédemment, nous pouvons utiliser la structure suivante de la commande Docker tag : docker tag <local image name> <new tag>. Par exemple : docker tag my-nodejs-app lirantal/my-nodejs-app:latest

Comment exécuter une image Docker avec un tag ?

Pour utiliser une balise d’image Docker spécifique lors de l’exécution d’une image, indiquez simplement le nom complet de l’image et sa balise dans la commande docker run. Par exemple : docker run --rm -p 27017:27017 mongo:latest

Intégrations pertinentes pour Docker et les conteneurs sur GitHub Actions Marketplace

Vous pouvez également trouver et créer des workflows GitHub Actions dans GitHub Actions Marketplace, qui propose plus de 9 000 workflows couvrant notamment la qualité du code, la gestion des dépendances et la sécurité. Vous y trouverez aussi les Snyk GitHub Actions, qui permettent de protéger vos projets contre les vulnérabilités de bibliothèques open source tierces et d’aider votre équipe à respecter les bonnes pratiques de codage sécurisé.

Pour créer, tester et publier des images Docker dans un registre, il existe un moyen plus simple que de parcourir la marketplace. Si votre dépôt contient déjà un fichier Dockerfile, GitHub le détectera automatiquement et vous proposera des workflows adaptés à GitHub Actions. Il vous suffit d’aller dans l’onglet Actions :

Le premier workflow suggéré, Publish Docker Container, vous permettra de mettre en place un workflow similaire de création et de publication d’images Docker à celui que nous avons déjà examiné.

Résumé et ressources complémentaires

Cet article vous a donné envie d’adopter des pratiques de développement sécurisé ? Parfait ! Voici quelques ressources complémentaires pour vous lancer et marquer des points en matière de sécurité auprès de votre équipe :

1. La sécurité de la chaîne d’approvisionnement est importante. Voici donc 10 bonnes pratiques de sécurité GitHub pour éviter de reproduire les erreurs courantes.

2. Vous aimez Node.js et la création de paquets npm ? Moi aussi ! J’ai écrit un article pour vous aider à publier des paquets npm en toute sécurité avec GitHub Actions.

3. Si vous passez beaucoup de temps dans l’écosystème GitHub, découvrez l’analyse de code de Snyk, qui s’intègre davantage à vos workflows : Analyse de code de sécurité GitHub : sécurisez vos dépendances open source