Lab 03 — Images et runners

Le pipeline fonctionne, mais il est lent et le job de build Docker échoue. Les jobs Python utilisent python:3.12, une image qui pèse plus de 900 Mo. Et le job docker-build utilise aussi une image Python — ce qui est absurde, puisqu'une image Python ne contient pas Docker. Dans ce lab, vous allez corriger ces deux problèmes en choisissant la bonne image pour chaque job.

Ce que vous allez apprendre

Comprendre le rôle de l'image Docker dans un job GitLab CI/CD
Choisir entre python:3.12 et python:3.12-slim selon le contexte
Configurer Docker-in-Docker pour construire des images dans un pipeline
Lire la taille des images et mesurer l'impact sur la durée du pipeline

Dans quel contexte ?

Chaque job GitLab CI tourne dans un conteneur Docker. Le runner télécharge l'image spécifiée, crée un conteneur, et exécute vos commandes dedans. Si l'image est lourde (900 Mo vs 150 Mo), chaque job perd du temps à la télécharger — surtout sur les runners qui ne mettent pas les images en cache entre les runs.

Situations réelles où ce lab vous aide :

Votre pipeline prend 8 minutes alors que les tests eux-mêmes durent 30 secondes — la majeure partie du temps est dans le pull des images
Un collègue a copié-collé image: python:3.12 partout sans réfléchir au choix
Le job de build Docker échoue avec docker: command not found — l'image utilisée ne contient pas Docker
Vous voulez comparer les temps de pipeline avant et après optimisation des images

Prérequis

Lab 02 complété — ou partir directement de la branche starter/lab-03
Avoir lu Runners GitLab CI/CD (conseillé)

Point de départ

Passez sur la branche de départ
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-03
```
Poussez pour déclencher le pipeline
Fenêtre de terminal
```
git push origin starter/lab-03
```
Observez le résultat dans Build > Pipelines

Le pipeline démarre. Les jobs ruff-lint et pytest passent — lentement. Le job docker-build échoue avec une erreur clé : docker: command not found.

Le problème

Deux problèmes distincts :

Problème	Quel job	Symptôme	Cause
Performance	`ruff-lint`, `pytest`	Jobs lents (téléchargement long)	Image `python:3.12` trop lourde (~900 Mo)
Erreur fonctionnelle	`docker-build`	`docker: command not found`	Image Python n'a pas le client Docker

À vous : Ouvrez le .gitlab-ci.yml de starter/lab-03 et identifiez ces deux problèmes dans la configuration actuelle.

Indices :

Pour le premier : comparez python:3.12 avec python:3.12-slim (cherchez sur Docker Hub la taille de chaque image)
Pour le second : la commande docker build est lancée depuis une image qui n'a pas Docker installé

L'exercice

Étape 1 — À vous de proposer les corrections

Maintenant que vous avez identifié les 2 problèmes, à vous de les corriger :

Correction 1 : Remplacez python:3.12 par python:3.12-slim dans les jobs ruff-lint et pytest

Correction 2 : Corrigez complètement le job docker-build pour faire fonctionner Docker-in-Docker

Questions pour vous guider :

Quelle image utiliseriez-vous pour un job qui lance uniquement docker build ?
Que devient le pipeline si vous lancez la commande docker build sans service annexe ?
À quoi servent les variables DOCKER_TLS_CERTDIR ?

Faites les modifications, puis vérifiez ci-dessous :

👉 Vérifier votre solution

Correction 1 — Images Python slim

Remplacez python:3.12 par python:3.12-slim :

ruff-lint:
  stage: lint
  image: python:3.12-slim   # ← 150 Mo au lieu de 900 Mo
  before_script:
    - pip install ruff
  script:
    - ruff check app/ tests/

pytest:
  stage: test
  image: python:3.12-slim   # ← 150 Mo au lieu de 900 Mo
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - pytest -v

Pourquoi slim ? L'image complète python:3.12 contient des compilateurs C/C++ et des outils système inutiles pour du lint/testing. La version -slim pèse 6 fois moins et suffit pour presque tous les cas CI/CD.

Correction 2 — Docker-in-Docker pour `docker-build`

Remplacez entièrement le job docker-build :

docker-build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t pipeline-craft:test .

Explication de chaque ligne :

image: docker:27 — Contient uniquement le client Docker (la commande docker). Très léger (~50 Mo).
services: - docker:27-dind — GitLab lance un conteneur annexe avec le daemon Docker (dockerd). C'est lui qui exécute les commandes docker build.
DOCKER_TLS_CERTDIR: "/certs" — Le client Docker s'authentifie auprès du daemon via TLS. Cette variable indique le chemin des certificats auto-générés par GitLab.

Ces 3 lignes forment un bloc indissociable — sans le service dind, docker build échouerait avec Cannot connect to the Docker daemon.

Étape 2 — Pousser et vérifier

Committez et poussez

git add .gitlab-ci.yml
git commit -m "ci: use slim images and fix docker-build with dind"
git push origin starter/lab-03

Observez le pipeline dans Build > Pipelines

Les trois jobs doivent passer au vert. Comparez la durée avec le run précédent — les jobs Python sont plus rapides grâce aux images slim.

Vérification

Vous avez identifié les 2 problèmes en lisant le .gitlab-ci.yml (pas en relisant cet énoncé)
Le job ruff-lint utilise python:3.12-slim et passe au vert
Le job pytest utilise python:3.12-slim et passe au vert
Le job docker-build utilise docker:27 + service docker:27-dind et passe au vert
Vous comprenez pourquoi Docker-in-Docker nécessite image, services, et DOCKER_TLS_CERTDIR
Plus d'erreur docker: command not found

Pièges fréquents

Symptôme	Cause	Solution
`docker: command not found`	Image sans Docker (ex : `python:3.12`) utilisée pour `docker build`	Utiliser `image: docker:27`
`Cannot connect to the Docker daemon`	Service `docker:27-dind` absent	Ajouter `services: - docker:27-dind`
`TLS handshake error`	Variable `DOCKER_TLS_CERTDIR` manquante	Ajouter `DOCKER_TLS_CERTDIR: "/certs"`
`pip install` échoue avec `-slim`	Le paquet nécessite un compilateur C absent des images slim	Utiliser l'image complète ou ajouter `apt-get install -y gcc` avant pip

Pour aller plus loin

Explorez Docker Hub : toutes les images officielles expliquent la différence entre les variantes (latest, slim, alpine, bullseye…). Pour Python, consultez hub.docker.com/_/python.
Comparez avec solution/lab-03 : git diff origin/starter/lab-03..origin/solution/lab-03 montre exactement les corrections attendues.
Prochain level : dans le Lab 04, vous allez accélérer encore le pipeline en mettant les dépendances pip en cache pour éviter de les réinstaller à chaque run.

À retenir

L'image Docker d'un job doit correspondre à ce que le job fait : un job Python utilise une image Python, un job de build Docker utilise une image Docker
Les images -slim sont 5–7x plus légères que les images complètes et suffisent dans la quasi-totalité des cas CI/CD
Docker-in-Docker nécessite trois éléments : image: docker:27, services: - docker:27-dind, et DOCKER_TLS_CERTDIR: "/certs" — ces trois lignes forment un bloc indissociable
Le choix de l'image a un impact direct sur la durée du pipeline — chaque Mo téléchargé prend du temps

Prochaines étapes

Lab 04 — Artifacts et cache Transmettez des fichiers entre jobs et mettez les dépendances en cache

Runners GitLab CI/CD Comprendre où et comment s'exécutent les jobs

← Lab 02 Lire un échec et le corriger