Construire et publier une image Docker dans la CI

Construire une image Docker dans la CI, c'est confier au pipeline la fabrication de l'image à partir du Dockerfile : il la construit sur une machine neuve, l'étiquette avec le commit ou le numéro de version, la teste, l'analyse et la pousse dans un registre. Cette image unique est ensuite déployée en recette puis en production. Ce chapitre écrit un Dockerfile adapté à la CI, construit et teste l'image dans GitHub Actions, la publie dans le registre de GitHub avec les actions officielles de Docker, puis fait de même avec GitLab CI. Les bases de Docker (images, Dockerfile, Compose) sont dans le cours Conteneurs et Docker, qui aborde aussi Docker dans la CI/CD côté infrastructure.

Pourquoi livrer une image

Une image Docker contient l'application et tout ce dont elle a besoin pour tourner : la bonne version de Node.js, les bibliothèques système, les dépendances installées (les bases de Docker). Livrer une image plutôt que des fichiers règle trois problèmes d'un coup :

• la même chose partout : l'image testée dans la CI est celle qui tourne en recette et en production, octet pour octet ;
• un déploiement simple : sur le serveur, plus besoin d'installer Node.js ni de lancer npm ci ; on récupère l'image et on la démarre ;
• un retour arrière immédiat : l'image de la version précédente est toujours dans le registre, il suffit de la redémarrer (chapitre 12).

Un Dockerfile pour la CI

# syntax=docker/dockerfile:1

# Étape 1 : installer les dépendances de production
FROM node:24-slim AS dependances
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

# Étape 2 : l'image finale, sans outils de développement
FROM node:24-slim
ENV NODE_ENV=production
WORKDIR /app
COPY --from=dependances /app/node_modules ./node_modules
COPY package.json ./
COPY src ./src
USER node
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD node -e "fetch('http://127.0.0.1:3000/health').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"
CMD ["node", "src/server.js"]

Le fichier .dockerignore, à côté du Dockerfile, exclut ce qui ne doit pas partir dans le contexte de construction :

node_modules
.git
.github
.env
.env.*
coverage
reports
*.md

Construire et tester l'image dans la CI

Docker est préinstallé sur les runners Ubuntu de GitHub. Avant de publier quoi que ce soit, on peut construire l'image et vérifier qu'elle démarre :

jobs:
  tester-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Construire l'image
        run: docker build -t sorbier-frais:test .
      - name: Démarrer le conteneur
        run: docker run -d --name api -p 3000:3000 -e DB_HOST=exemple.invalid sorbier-frais:test
      - name: Test de fumée
        run: |
          curl --fail --silent --show-error --retry 10 --retry-delay 2 --retry-all-errors \
            http://127.0.0.1:3000/health
      - name: Journaux du conteneur en cas d'échec
        if: failure()
        run: docker logs api

Ce job vérifie ce que les tests unitaires ne voient pas : le Dockerfile construit, l'application démarre dans l'image, toutes ses dépendances sont présentes. La route /health de sorbier-frais répond même sans base de données ; une route qui vérifie aussi la base (/health/ready) se teste avec un service MySQL.

Choisir un registre

Un registre stocke les images et les distribue aux serveurs.

Pour un projet sur GitHub, ghcr.io est le plus simple : le jeton du workflow suffit. Une image publiée est privée par défaut ; le serveur qui la récupère doit s'authentifier, ou on la rend publique dans les réglages du paquet.

Étiqueter les images

Une étiquette (tag) est un nom donné à une image : ghcr.io/sorbier/sorbier-frais:2.4.0. Une même image peut porter plusieurs étiquettes.

Le workflow complet : construire, étiqueter, publier

name: Image Docker

on:
  push:
    branches: [main]
    tags: ['v*']
  pull_request:

permissions:
  contents: read

env:
  IMAGE: ghcr.io/sorbier/sorbier-frais

jobs:
  image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v7

      - name: Préparer Buildx
        uses: docker/setup-buildx-action@v4

      - name: Se connecter au registre
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Calculer les étiquettes
        id: meta
        uses: docker/metadata-action@v6
        with:
          images: ${{ env.IMAGE }}
          tags: |
            type=sha
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}

      - name: Construire et publier
        uses: docker/build-push-action@v7
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Les étiquettes produites selon l'événement :

Pour un tag de version, docker/metadata-action ajoute aussi latest par défaut (réglage flavor: latest=auto). Ce n'est pas gênant tant qu'on ne déploie jamais latest ; pour ne pas la produire du tout, ajoute flavor: latest=false dans le with: de l'étape.

L'adresse de l'image est écrite en minuscules dans env.IMAGE : un registre refuse les majuscules, et le nom d'un compte GitHub peut en contenir.

Analyser l'image avant de la déployer

Après la construction, un scanner d'images (Trivy, Grype, Docker Scout) compare les paquets de l'image aux bases de vulnérabilités (analyse des images). On le règle pour faire échouer le pipeline sur les failles critiques corrigeables, et on publie le rapport comme artefact. Si tu utilises une action tierce pour cela, épingle-la sur une empreinte de commit : c'est justement un scanner de ce type dont les étiquettes ont été détournées en 2026.

Avec GitLab CI

GitLab construit l'image dans un conteneur Docker qui parle à un service Docker-in-Docker (docker:dind) :

image-docker:
  stage: build
  image: docker:29-cli
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

image-version:
  stage: build
  image: docker:29-cli
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG

DOCKER_TLS_CERTDIR active la connexion chiffrée entre le client et le service Docker. Le mot de passe passe par --password-stdin pour ne pas apparaître dans la liste des processus. Docker-in-Docker demande un runner en mode privilégié : c'est le cas des runners partagés de GitLab.com, mais l'équipe qui gère un runner interne peut préférer un outil de construction sans démon Docker, comme Buildah.

Les pièges classiques

Exercices

FROM node:latest
WORKDIR /app
COPY . .
ENV DB_PASSWORD=Sorbier2026!
RUN npm install
EXPOSE 3000
CMD npm start

#12 exporting to image
#12 pushing layers 0.4s done
#12 ERROR: failed to push ghcr.io/sorbier/sorbier-frais:main: denied: permission_denied: write_package
ERROR: failed to build: failed to solve: failed to push ghcr.io/sorbier/sorbier-frais:main: denied: permission_denied: write_package
Error: buildx failed with: ERROR: failed to build: failed to solve: failed to push ghcr.io/sorbier/sorbier-frais:main: denied: permission_denied: write_package

    permissions:
      contents: read
      packages: write