GitLab Runner: Construire une image Docker avec Docker-in-Docker

Cette documentation fait partie du guide Création d’images Docker. Consultez le guide complet ici : Construisez et poussez efficacement des images Docker à partir de vos pipelines GitLab CI/CD en utilisant les runners Stackhero et Docker-in-Docker.

👋 Bienvenue dans la documentation Stackhero !

Stackhero offre une solution GitLab Runner cloud simple qui rend l’exécution de vos jobs GitLab CI/CD efficace et sans tracas. Voici ce que vous pouvez attendre :

• Minutes CI/CD illimitées : exécutez vos pipelines aussi souvent que nécessaire, sans facturation à la minute ni frais imprévus.
• Plusieurs jobs simultanés : accélérez votre développement en lançant plusieurs jobs en parallèle.
• L’executor Docker avec prise en charge de Docker-in-Docker : construisez et poussez facilement des images de conteneurs dans vos processus CI/CD.
• Fonctionne parfaitement avec GitLab.com et les instances GitLab autogérées.
• Une infrastructure privée et dédiée avec stockage NVMe/SSD rapide assure des performances de build stables et prévisibles.
• Disponible dans les régions 🇪🇺 Europe et 🇺🇸 USA pour répondre aux besoins de votre équipe.

Gagnez du temps : connectez votre premier GitLab Runner et commencez à exécuter vos pipelines en quelques minutes seulement !

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:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  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 la version 29 de l’image Docker dans cet exemple. Vous pouvez utiliser une version plus récente dès qu’elle est disponible. Vous trouverez les tags les plus récents sur la page officielle Docker image.

Dans cette configuration, le service docker:29-dind démarre un démon Docker à côté de votre job, et DOCKER_HOST: "tcp://docker:2375" indique au CLI docker de l’utiliser. Définissez toujours DOCKER_HOST lorsque vous déclarez un service docker:dind : sans cela, le CLI se connecte silencieusement à un autre démon, ce qui peut faire passer votre build même si le service est mal configuré, masquant ainsi de vrais problèmes (et cassant des outils comme Testcontainers qui dépendent du service). DOCKER_TLS_CERTDIR: "" permet de se connecter via le port interne non sécurisé 2375 du réseau du job.

En alternative plus simple, vous pouvez omettre le bloc services et les deux variables : le runner Stackhero expose aussi un démon Docker prêt à l’emploi via un socket monté, donc une simple commande docker build fonctionne sans configuration supplémentaire.