Projet · Phase 3.6

Docker (6/9) — Construire son image : Dockerfile

Servir un site via un dossier monté, c'est fragile. On va emballer SORIA Web et son serveur dans une seule image autonome — et comprendre les couches, le cache, et CMD vs ENTRYPOINT.

⏱ ~1 h 30Niveau intermédiairePrérequis : Docker (5/9)Pratique · TP
L’idée reçue

« Une image Docker, c’est une boîte noire qu’on télécharge. »

Jusqu’ici tu as utilisé des images (debian, nginx). Maintenant tu vas en fabriquer une. Et tu découvriras qu’une image n’a rien d’opaque : c’est une pile de couches, construite par une recette lisible — le Dockerfile.

À la fin de ce module, tu sauras…

  • Écrire un Dockerfile et construire ta propre image
  • Expliquer le système de couches et le cache de build
  • Ordonner tes instructions pour un cache efficace
  • Distinguer CMD et ENTRYPOINT

01Ta première image

Expérience 1

Emballer SORIA Web dans une image

Dans le dossier de ton site, crée un fichier nommé Dockerfile :

Manipule
cd ~/soria-web
cat > Dockerfile <<'EOF'
FROM nginx:stable
COPY index.html /usr/share/nginx/html/index.html
EOF

Construis l’image, puis lance un conteneur à partir d’elle :

Manipule
docker build -t soria-web:1.0 .
docker run -d --name web -p 8080:80 soria-web:1.0
curl http://localhost:8080
Observe
<h1>SORIA Web — ma première mise en ligne</h1>
Cette fois, plus aucun montage : le site est dans l’image. Cette image est autonome — tu pourrais l’envoyer sur n’importe quel serveur et elle servirait la même page.
Comprends FROM, COPY, build

FROM choisit une image de base (ici Nginx). COPY ajoute tes fichiers dedans. docker build -t nom:tag . lit la recette et fabrique l’image (le . est le dossier de contexte). Résultat : une image qui embarque serveur + contenu.

02Une image est une pile de couches

Expérience 2

Voir les couches

Manipule
docker history soria-web:1.0
Observe
IMAGE      CREATED BY                          SIZE
<...>      COPY index.html ...                 1.09kB
<...>      /bin/sh -c ... (nginx base)         ...
...
Chaque instruction du Dockerfile a créé une couche, empilée sur la précédente. Ton COPY est la couche du dessus.
Comprends pourquoi des couches ?

Une image est un empilement de couches en lecture seule, chacune correspondant à une instruction. Les couches sont partagées entre images (deux images basées sur Nginx partagent les couches de Nginx) et mises en cache lors des builds. D’où des images plus légères et des constructions plus rapides.

03Le cache de build (et comment le gâcher)

Expérience 3

Observer le cache, puis l’ordonner

Reconstruis sans rien changer :

Manipule
docker build -t soria-web:1.0 .
Observe
=> CACHED [2/2] COPY index.html ...
CACHED : Docker n’a rien refait, il a réutilisé les couches. Modifie index.html, reconstruis : seule la couche COPY est refaite, pas la base.
Comprends la règle d’or de l’ordre

Docker réutilise une couche du cache tant que l’instruction et ce qu’elle copie n’ont pas changé. Dès qu’une couche change, toutes celles d’après sont refaites. D’où la règle : place ce qui change rarement (dépendances) en haut, et ce qui change souvent (ton code) en bas. On l’exploitera à fond au module production.

04CMD vs ENTRYPOINT

Expérience 4

Qu’exécute un conteneur au démarrage ?

Crée une petite image qui illustre la différence :

Manipule
mkdir ~/demo-cmd && cd ~/demo-cmd
cat > Dockerfile <<'EOF'
FROM debian:stable-slim
ENTRYPOINT ["echo"]
CMD ["bonjour"]
EOF
docker build -t demo-cmd .
docker run demo-cmd
docker run demo-cmd SORIA
Observe
bonjour        # docker run demo-cmd
SORIA          # docker run demo-cmd SORIA
ENTRYPOINT (echo) est toujours exécuté ; CMD (bonjour) n’est que l’argument par défaut, remplacé si tu en fournis un.
Comprends quand utiliser lequel

ENTRYPOINT définit la commande fixe du conteneur ; CMD fournit des arguments par défaut, faciles à surcharger. En pratique : ENTRYPOINT pour « ce conteneur EST tel programme », CMD pour ses options par défaut. Beaucoup d’images n’utilisent que CMD, c’est suffisant dans les cas simples.

Ce que tu retiens

Une image se fabrique avec un Dockerfile : FROM (base), COPY (tes fichiers), et une commande de démarrage (CMD/ENTRYPOINT). Elle est faite de couches mises en cache — d’où l’importance de l’ordre des instructions. SORIA Web est désormais une image autonome.

Mini-projet

Ton image SORIA Web, versionnée

À faire

  1. Améliore index.html, puis construis soria-web:1.1.
  2. Compare docker images : tu as bien 1.0 et 1.1.
  3. Reconstruis sans changement et repère la ligne CACHED.
  4. Change une ligne du HTML, reconstruis, observe quelle couche est refaite.
  5. Explique en 3 lignes pourquoi on met le code qui change souvent en bas du Dockerfile.
Fil rouge — Ton image marche, mais elle n’est pas encore « prête pour la production » : taille, sécurité, utilisateur root… Au module suivant, on écrit un Dockerfile de production : multi-stage, non-root, versions figées.

?Auto-évaluation

1. Qu’est-ce qu’une couche d’image ?

Le résultat d’une instruction du Dockerfile : une image est un empilement de couches en lecture seule, partagées et mises en cache.

2. Pourquoi placer les dépendances avant le code dans un Dockerfile ?

Parce qu’un changement dans une couche refait toutes les suivantes. Le code change souvent : le mettre en bas évite de refaire les couches de dépendances à chaque build.

3. Différence entre CMD et ENTRYPOINT ?

ENTRYPOINT est la commande toujours exécutée ; CMD fournit des arguments par défaut, surchargeables à l’exécution.

Connecte-toi pour enregistrer ta progression.

Suite → Docker (7/9) — Dockerfile de production