Un Dockerfile est un fichier texte contenant une série d’instructions qui, exécutées par la commande `docker build`, produisent une image Docker. Chaque instruction crée une couche (layer) dans l’image, ce qui permet la mise en cache et la réutilisation des étapes. Une bonne écriture du Dockerfile est cruciale pour la performance des builds et la sécurité des images. ISOSET forme à l’écriture de Dockerfiles prêts pour la production.

• FROM – image de base (ex: node:18-alpine, python:3.10-slim, alpine).
• WORKDIR – définit le répertoire de travail (crée le dossier si nécessaire).
• COPY / ADD – copie des fichiers de l’hôte vers l’image (préférer COPY).
• RUN – exécute des commandes (apt-get, pip install, npm ci).
• ENV / ARG – variables d’environnement et arguments de build.
• EXPOSE – documente le port d’écoute (ne publie pas).
• CMD / ENTRYPOINT – commande par défaut à l’exécution du conteneur.

# Exemple simple (application Python)
FROM python:3.10-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Chaque instruction du Dockerfile crée une couche. Docker met en cache ces couches : si une instruction n’a pas changé, il réutilise la couche existante, ce qui accélère considérablement les reconstructions. Ordonner les instructions de la moins changeante à la plus changeante est une pratique clé.

• Couches de base – les plus stables (FROM, WORKDIR).
• Couches d’installation – dépendances (copier package.json puis RUN npm ci).
• Couches applicatives – code source (copié en dernier).
• Inspections – `docker history mon-image` pour voir la taille de chaque couche.

# Optimisation du cache (Node.js)
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci          # relancé uniquement si package*.json change
COPY . .            # code source copié après
CMD ["node", "index.js"]

ISOSET aide les équipes à restructurer leurs Dockerfiles pour des builds rapides et efficaces.

Les builds multi‑étapes permettent d’utiliser plusieurs images `FROM` dans un même Dockerfile. Seule la dernière étape est conservée dans l’image finale. Cela évite d’emporter les outils de compilation (SDK, compilateurs, bibliothèques de développement) en production, réduisant drastiquement la taille de l’image.

• Build stage – image lourde avec compilateur, dépendances de dev.
• Runtime stage – image minimale (alpine, distroless) contenant seulement l’exécutable et les assets.
• Copie entre stages – `COPY –from=build /app/dist /app/dist`.

# Multi‑stage build pour une application Go
FROM golang:1.21 AS builder
WORKDIR /src
COPY go.mod go.sum .
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /bin/app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
COPY --from=builder /bin/app /app
EXPOSE 8080
CMD ["/app"]

ISOSET enseigne le multi‑stage pour réduire la taille des images de plusieurs centaines de mégaoctets à quelques dizaines.

• ARG – variable de build (ex: `–build-arg VERSION=1.0`).
• HEALTHCHECK – définit une commande pour vérifier la santé du conteneur.
• SHELL – change le shell par défaut (utile sous Windows).
• USER – bascule vers un utilisateur non‑root pour la sécurité.
• .dockerignore – exclut des fichiers (logs, .git, node_modules) pour éviter d’invalider le cache.

# Exemple avec ARG et USER
FROM node:18-alpine
ARG APP_VERSION
ENV APP_VERSION=${APP_VERSION}
RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001
WORKDIR /app
COPY --chown=nodejs:nodejs . .
USER nodejs
CMD ["node", "app.js"]

• Image de base minimale – utiliser `-alpine`, `-slim` ou `distroless`.
• Ne pas exécuter en root – créer un utilisateur non privilégié (USER).
• Nettoyer les caches – `RUN apt-get update && apt-get install -y –no-install-recommends … && rm -rf /var/lib/apt/lists/*`.
• Éviter les secrets dans les couches – ne pas `COPY` de fichiers contenant des mots de passe ; utiliser `–secret` (BuildKit) ou variables d’environnement au runtime.
• Scanner les vulnérabilités – `docker scan`, Trivy, Clair.

• docker build – `-t nom:tag`, `-f Dockerfile.alternatif`.
• BuildKit – `DOCKER_BUILDKIT=1 docker build` (constructions parallèles, secrets).
• Réduire la taille – supprimer les fichiers temporaires, combiner les RUN.
• Image size analysis – `dive`, `docker history`.

# Combinaison de RUN pour limiter les couches
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    git \
 && rm -rf /var/lib/apt/lists/*

ISOSET propose des ateliers pratiques d’optimisation d’images (réduction de 70% de taille).

Une fois l’image construite, elle peut être stockée dans un registre (Docker Hub, AWS ECR, Azure ACR, GitLab Registry, Nexus). Les images peuvent être taguées (`latest`, `v1.0.0`, `git-sha`), partagées et déployées.

• docker push – pousser vers un registre.
• docker pull – télécharger depuis un registre.
• Registre privé – sécurité, conformité, vitesse.

# Taguer et pousser une image
docker tag mon-app:latest mon-registre.com/prod/mon-app:1.0.0
docker push mon-registre.com/prod/mon-app:1.0.0

ISOSET forme à l’intégration des registres dans les pipelines CI/CD.

Les témoignages d’anciens élèves d’ISOSET soulignent l’importance de maîtriser le Dockerfile : *« Avant la formation, mes images faisaient 1,2 Go. En appliquant le multi‑stage et les bonnes pratiques, je suis passé à 120 Mo. Mon pipeline CI/CD est trois fois plus rapide. »*