GitLab Runner: Construire des images Docker

Construisez et poussez efficacement des images Docker depuis vos pipelines GitLab CI/CD en utilisant les runners Stackhero et Docker-in-Docker

👋 Bienvenue sur la documentation de Stackhero !

Stackhero vous propose une solution GitLab Runner cloud simple à utiliser, conçue pour exécuter efficacement vos jobs GitLab CI/CD. Voici ce dont vous pouvez bénéficier :

Minutes CI/CD illimitées : aucune facturation à la minute, vos pipelines s'exécutent quand vous en avez besoin.

Jobs simultanés : lancez plusieurs jobs en parallèle pour accélérer l'ensemble de votre pipeline.

Docker executor avec prise en charge de Docker-in-Docker : facilitez la création et le push de vos images de conteneurs.

Compatible avec GitLab.com ainsi que toute instance GitLab auto-hébergée.

Une VM privée et dédiée propulsée par des disques NVMe/SSD rapides pour des builds fiables et constants.

Disponible dans les régions 🇪🇺 Europe et 🇺🇸 USA.

Gagnez du temps : connectez votre premier GitLab Runner et lancez vos pipelines en quelques minutes seulement !

Introduction

Avec un GitLab Runner Stackhero, chaque job s'exécute dans un conteneur isolé grâce à l'executor Docker. Vous pouvez construire vos propres images Docker directement dans votre pipeline en activant Docker-in-Docker (DinD). Cette configuration lance un démon Docker à côté de votre job, ce qui vous permet d'exécuter les commandes docker build et docker push dans votre processus CI/CD.

Chaque exécution bénéficie de minutes CI/CD illimitées : vous pouvez lancer autant de builds que nécessaire, sans vous soucier de quotas. Votre cache de build est stocké sur le disque dédié du runner, ce qui permet de réutiliser les couches précédentes lors de builds répétés. Cela réduit considérablement les temps de build et accélère vos pipelines.

Construire une image Docker avec Docker-in-Docker

Vous pouvez ajouter l'exemple de .gitlab-ci.yml suivant à votre dépôt. Cette configuration construit le Dockerfile situé à la racine de votre projet :

build-image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Remplacez "my-image" par le nom souhaité :
    - docker build -t my-image .
    # Optionnellement, lancez un test rapide sur l'image construite :
    # - docker run --rm my-image /path/to/tests

Nous utilisons ici la version 29 de l'image Docker. Vous pouvez choisir une version plus récente si besoin. Retrouvez les tags les plus récents sur la page officielle Docker image.

Dans cette configuration, le service docker:29-dind démarre le démon Docker. La variable DOCKER_TLS_CERTDIR: "/certs" active une connexion TLS sécurisée entre votre job et le démon Docker.

Pousser vers le registre de conteneurs GitLab

GitLab fournit des variables prédéfinies (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) pour que votre pipeline puisse s'authentifier et pousser des images vers le registre de conteneurs de votre projet en toute sécurité. Aucun secret supplémentaire n'est nécessaire.

Voici un exemple de job qui construit et pousse votre image :

build-and-push:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
    # Si vous êtes sur la branche par défaut, vous pouvez aussi taguer et pousser "latest" :
    - |
      if [ "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" ]; then
        docker tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" "$CI_REGISTRY_IMAGE:latest"
        docker push "$CI_REGISTRY_IMAGE:latest"
      fi

Pour pousser vos images vers un autre registre (comme Docker Hub ou un registre privé), vous pouvez stocker les identifiants dans les variables CI/CD et les utiliser avec docker login de la même manière.

Accélérer les builds répétés

Le disque de votre runner est conservé entre les pipelines, ce qui permet de réutiliser les couches d'image comme cache de build. Cela accélère considérablement les builds successifs. Voici un exemple de configuration :

build-cached:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Récupère la dernière image pour initialiser le cache (si elle existe) :
    - docker pull "$CI_REGISTRY_IMAGE:latest" || true
    - docker build --cache-from "$CI_REGISTRY_IMAGE:latest" -t "$CI_REGISTRY_IMAGE:latest" .
    - docker push "$CI_REGISTRY_IMAGE:latest"

Cette méthode permet à vos builds de profiter du cache de couches Docker, seules les nouvelles couches ou celles modifiées sont reconstruites.

Exécuter des jobs en parallèle

Votre offre détermine le nombre de jobs pouvant s'exécuter simultanément. Les jobs d'une même étape démarrent ensemble, dans la limite de votre niveau de parallélisme. Plusieurs jobs indépendants peuvent donc s'exécuter en parallèle et se terminer dès que le plus lent est terminé, sans attendre la fin de chaque job l'un après l'autre.

Exemple :

stages:
  - test

unit:
  stage: test
  image: node:22
  script: npm run test:unit

integration:
  stage: test
  image: node:22
  script: npm run test:integration

e2e:
  stage: test
  image: node:22
  script: npm run test:e2e

Si vous définissez votre parallélisme à 1 ou plus, les jobs unit, integration et e2e s'exécuteront en même temps.

Pour plus d'informations sur la construction d'images Docker dans les pipelines GitLab CI/CD, vous pouvez consulter la documentation officielle GitLab sur l'utilisation des builds Docker.