Exercice 05 : Optimiser pour la production avec Docker

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Ajouter des LABEL OCI standard (maintainer, version, description) à une image
• ✅ Utiliser ARG pour les paramètres de build et ENV pour les variables d'exécution
• ✅ Passer des --build-arg au moment du docker build
• ✅ Limiter la mémoire et le CPU d'un conteneur avec --memory et --cpus
• ✅ Auditer l'espace disque avec docker system df et nettoyer avec docker system prune

Durée estimée : 35 min | Difficulté : ⭐⭐⭐⭐☆

📖 Contexte

En production, les images doivent être traçables (métadonnées), paramétrables (ARG/ENV), et les conteneurs doivent être protégés contre les fuites de ressources (limits). Un audit régulier du stockage Docker evite la saturation du disque sur les serveurs CI/CD ou de production.

📋 Énoncé

Construisez une image Node.js de production avec des métadonnées complètes, paramétrable via des arguments de build. Déployez-la avec des limites de ressources. Enfin, auditez et nettoyez votre environnement Docker local.

🧭 Déroulement

Tâche 1 : Ajouter des LABEL OCI à l'image

Dans votre Dockerfile, ajoutez les labels OCI standards après la ligne FROM :

LABEL org.opencontainers.image.title="Demo App" \
      org.opencontainers.image.version="1.0.0" \
      org.opencontainers.image.description="Application de démonstration" \
      org.opencontainers.image.authors="votre@email.com" \
      org.opencontainers.image.source="https://github.com/votre/repo"

Indice : Les labels OCI standardisés (org.opencontainers.image.*) sont reconnus par les registres comme Docker Hub et GitHub Container Registry.

Vérification : docker inspect <image> | grep -A 10 '"Labels"' affiche tous les labels.

Tâche 2 : Utiliser ARG pour paramétrer le build

Remplacez la version Node.js codée en dur par un ARG avec une valeur par défaut. Transmettez cette valeur à une variable ENV pour la rendre disponible à l'exécution.

ARG NODE_VERSION=20
FROM node:${NODE_VERSION}-alpine
ARG APP_VERSION=1.0.0
ENV APP_VERSION=${APP_VERSION}

Indice : Un ARG déclaré avant FROM ne persiste pas dans le stage. Re-déclarez-le après FROM si nécessaire. ENV persiste dans l'image et l'exécution ; ARG disparait après le build.

Vérification : docker build --build-arg NODE_VERSION=22 -t demo-app . construit avec Node 22 sans modifier le Dockerfile.

Tâche 3 : Limiter les ressources du conteneur

Démarrez votre conteneur avec 256 Mo de mémoire maximum et 0.5 CPU.

Indice : docker run --memory=256m --cpus=0.5 ... ou dans docker-compose.yml sous deploy.resources.limits.

Vérification : docker stats <container> affiche 256MiB dans la colonne MEM LIMIT.

Tâche 4 : Auditer et nettoyer l'espace Docker

Affichez l'espace utilisé par les images, conteneurs, volumes et le cache de build. Supprimez les ressources inutilisées (images dangling, conteneurs arrêtés, cache de build obsolète).

Indice : docker system df donne une vue synthétique. docker system prune --volumes supprime tout ce qui n'est pas utilisé par un conteneur actif - cette commande est irréversible, confirmez avant de lancer en production.

Vérification : Relancez docker system df - la colonne RECLAIMABLE doit avoir diminué.

🗂️ Mini-Projet

Complétez les points suivants :

• docker inspect demo-app liste tous les labels OCI
• docker build --build-arg APP_VERSION=2.0.0 -t demo-app:2.0.0 . fonctionne
• docker run demo-app:2.0.0 env | grep APP_VERSION retourne APP_VERSION=2.0.0
• docker stats confirme que le conteneur respecte la limite mémoire de 256 Mo
• docker system df avant/après prune montre une réduction de l'espace utilisé