Comment publier des images Docker Node.js dans le registre Docker Hub avec GitHub Actions

Dans un précédent article, nous avons présenté un tutoriel détaillé expliquant comment publier des images Docker Node.js dans le registre GitHub Packages avec GitHub Actions. Dans cet article, nous allons nous intéresser à la publication de l’image Docker que nous avons créée sur le registre public Docker Hub.

Vous vous demandez peut-être à quoi cela peut servir. L’application en ligne de commande Docker docker utilise par défaut le registre docker.io, qui pointe vers Docker Hub. Cela offre une expérience développeur agréable : il suffit de récupérer les images selon la convention <user>/<repository>, comme dans l’exemple suivant si vous souhaitez utiliser Snyk CLI sous forme d’image Docker :

1docker pull snyk/snyk-cli

Dans cet article, nous allons détailler étape par étape la configuration d’un autre workflow de création et de publication d’images Docker, qui peut fonctionner en parallèle du workflow précédent présenté pour le registre GitHub Packages.

Comme le précédent, cet article fait suite à celui consacré à Dockly, l’outil open source en ligne de commande Node.js pour gérer des conteneurs Docker depuis la CLI, et explique comment envoyer une image Docker sur Docker Hub. Vous pouvez consulter le workflow final dans le dépôt GitHub de Dockly.

Créer un workflow GitHub Actions

Pour ajouter un workflow, il suffit de créer un nouveau fichier dans le répertoire .github/workflows/, ou d’ouvrir votre dépôt open source sur GitHub, de cliquer sur l’onglet Actions, puis sur New Workflow pour commencer à créer un workflow :

Choisissez le nom du fichier de workflow de publication sur Docker Hub, par exemple docker-publish-to-dockerhub.yml.

Si vous effectuez cette opération depuis l’interface GitHub, un fichier de workflow peut être prérempli. Dans ce cas, supprimez-le et ajoutez le contenu suivant :

1name: "Docker: Docker Hub"
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: docker.io
17  IMAGE_NAME: ${{ github.repository }}

Nous avons expliqué chacun de ces points en détail dans l’article précédent. Pour résumer :

• Ce workflow Docker Hub s’exécutera à chaque push, à chaque publication d’une version balisée et à chaque pull request sur la branche principale du dépôt.

• Les variables d’environnement globales définissent REGISTRY sur docker.io, ce qui signifie que nos images seront envoyées sur Docker Hub et disponibles depuis ce registre. Elles définissent également IMAGE_NAME avec le nom d’utilisateur GitHub et le nom du dépôt. Si votre nom d’utilisateur Docker Hub est différent, vous devrez peut-être modifier cette valeur.

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

Se connecter à Docker Hub, puis créer et publier l’image Docker

Nous devons ensuite effectuer les opérations suivantes :

1. Se connecter à Docker Hub. Pour cela, nous devons y créer un jeton, puis l’ajouter comme secret du dépôt dans les paramètres du dépôt GitHub.

2. Extraire les métadonnées de l’image Docker créée afin qu’elles soient accessibles au processus de création de l’image.

3. Envoyer l’image Docker créée sur Docker Hub.

Le fragment de code suivant permet d’effectuer ces opérations. Ajoutez-le au contenu du workflow créé à l’étape précédente :

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: ${{ secrets.DOCKERHUB_USERNAME }}
19          password: ${{ secrets.DOCKERHUB_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 }}
26          flavor: |
27            latest=true
28            prefix=
29            suffix=
30
31      - name: Build and push Docker image
32        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
33        with:
34          context: .
35          push: ${{ github.event_name != 'pull_request' }}
36          tags: ${{ steps.meta.outputs.tags }}
37          labels: ${{ steps.meta.outputs.labels }}

Après avoir appliqué le fichier de workflow et l’avoir fusionné dans la branche principale, vous devriez obtenir une compilation réussie qui publiera une nouvelle image Docker sur Docker Hub :

Un problème connu : à l’heure actuelle, le dépôt Docker Hub sur lequel vous publiez l’image ne renseigne pas automatiquement une description et un fichier README adaptés, car cette fonctionnalité n’est pas disponible dans l’action GitHub officielle docker/build-and-push.

Si vous souhaitez ajouter cette fonctionnalité, les responsables recommandent l’action GitHub « Docker Hub Description » disponible sur la marketplace et proposent un exemple dans leur documentation que vous pouvez reprendre.

Récupérer des images Docker depuis le registre Docker Hub

Pour récupérer la nouvelle image Docker depuis Docker Hub, il vous suffit d’exécuter la commande habituelle docker pull , par exemple :

1$ docker pull <user>/<repository>
2Using default tag: latest
3latest: Pulling from <user>/<repository>
4b4d181a07f80: Pulling fs layer
5de8ecf497b75: Pulling fs layer
669b92f9e5e70: Pulling fs layer
71f2b8e2c8ad8: Waiting
8d0f4259cb643: Waiting
99ae47f3f99ba: Waiting
1087270829eb60: Waiting
11905fc634546c: Waiting

Vous publiez des images Docker vulnérables ?

Pourquoi s’arrêter là ? Avec Snyk, vous pouvez détecter, surveiller et même corriger les vulnérabilités dans les images Docker. Adoptez le workflow qui vous convient le mieux : utilisez la CLI ou importez directement des images Docker depuis Docker Hub pour surveiller leurs vulnérabilités de sécurité.

Mon collègue Eric Smalling a rédigé un guide détaillé des bonnes pratiques sur les workflows pilotés par les développeurs : analyse des Dockerfiles et des images, priorisation et correction, pour approfondir le sujet. Enfin, vous pouvez utiliser une action GitHub Snyk dans l’écosystème GitHub Actions pour détecter les vulnérabilités de sécurité dans les bibliothèques open source et les images de conteneurs.

Pour aller plus loin

Pour approfondir les bonnes pratiques de création d’images Docker, voici quelques ressources :

1. 10 bonnes pratiques pour conteneuriser des applications web Node.js avec Docker

2. Docker pour les développeurs Node.js : 5 conseils pour ne pas compromettre votre sécurité

Si vous n’avez pas lu l’article précédent et souhaitez publier des images Docker sur GitHub Packages, découvrez comment publier des images Docker Node.js dans le registre GitHub Packages avec GitHub Actions.