Docker

Docker est une plateforme open source de conteneurisation qui permet de construire, distribuer et exécuter des applications dans des conteneurs isolés et portables, garantissant un fonctionnement identique sur n’importe quel environnement.

Docker n’a pas inventé les conteneurs Linux. Il les a rendus utilisables. Avant Docker (2013), la conteneurisation nécessitait une expertise kernel (namespaces, cgroups, chroot). Docker a encapsulé ces mécanismes dans une CLI simple, un format d’image standardisé et un système de registres (Docker Hub), transformant la conteneurisation d’un exercice de plomberie système en un workflow de développement reproductible. En 2026, environ 92% des organisations IT utilisent des conteneurs, et Docker reste l’outil de build et de développement le plus répandu avec environ 71% d’adoption parmi les développeurs.

Catégorie: Plateforme de conteneurisation
Créateur: Docker, Inc. (Solomon Hykes, 2013)
Licence: Apache 2.0 (Engine/CLI), propriétaire (Desktop)
Engine: v29.3.0 (mars 2026)
Desktop: v4.x (releases mensuelles, macOS 14+ requis)
Standard: OCI (Open Container Initiative)
Registre: Docker Hub (le plus grand registre public)
URL: docker.com

Les composants de Docker

Docker Engine

Docker Engine est le runtime qui construit et exécute les conteneurs. C’est un daemon (dockerd) qui tourne sur la machine hôte et répond aux commandes de la CLI Docker. Docker Engine v29.3.0 (mars 2026) est la version stable actuelle, incluant BuildKit v0.28.0, containerd v1.7.x, et le support des dernières fonctionnalités réseau et sécurité.

Sous le capot, Docker Engine utilise containerd comme runtime de conteneurs et runc comme runtime bas niveau. Docker est donc une couche d’abstraction au-dessus de containerd, qui lui-même abstrait runc. C’est pourquoi Kubernetes peut utiliser containerd directement (sans Docker) comme runtime.

Docker CLI

La CLI Docker est l’interface en ligne de commande pour interagir avec Docker Engine. Les commandes essentielles :

# Construire une image à partir d'un Dockerfile
docker build -t mon-app:1.0 .

# Lancer un conteneur
docker run -d --name mon-api -p 8000:8000 mon-app:1.0

# Lancer un conteneur avec accès GPU (modèles ML)
docker run --gpus all -p 8001:8001 mon-modele-llm:v2

# Voir les conteneurs en cours d'exécution
docker ps

# Voir les logs d'un conteneur
docker logs -f mon-api

# Exécuter une commande dans un conteneur (debug)
docker exec -it mon-api bash

# Pousser une image vers un registre
docker push mon-registre/mon-app:1.0

# Nettoyer les ressources inutilisées
docker system prune -a

Dockerfile

Le Dockerfile est la « recette » qui décrit comment construire une image Docker. Chaque instruction (FROM, COPY, RUN) crée une couche (layer) dans l’image. Docker cache ces couches : si une couche n’a pas changé, elle est réutilisée, accélérant les builds suivants.

Voici un Dockerfile optimisé pour une application ML en Python :

# Image de base légère
FROM python:3.12-slim AS builder

WORKDIR /app

# Copier les dépendances en premier (cache Docker)
COPY requirements.txt .
RUN pip install --no-cache-dir --target=/install -r requirements.txt

# Image finale minimale
FROM python:3.12-slim
WORKDIR /app

# Copier les dépendances installées
COPY --from=builder /install /usr/local/lib/python3.12/site-packages

# Copier le code et le modèle
COPY src/ ./src/
COPY model/ ./model/

# Sécurité : utilisateur non-root
RUN useradd -m appuser
USER appuser

EXPOSE 8000
CMD ["python", "-m", "uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

Ce Dockerfile utilise un multi-stage build (deux étapes FROM) pour séparer l’environnement de build de l’image finale, réduisant significativement la taille.

Docker Compose

Docker Compose orchestre des applications multi-conteneurs en local. Un fichier docker-compose.yml (ou compose.yaml) définit l’ensemble des services, réseaux et volumes. C’est l’outil standard pour le développement local d’applications complexes.

services:
  api:
    build: ./api
    ports:
      - "8000:8000"
    depends_on:
      - model-server
      - postgres
    environment:
      - MODEL_URL=http://model-server:8001
  
  model-server:
    image: mon-registre/model-serving:v1.0
    ports:
      - "8001:8001"
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
  
  postgres:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret

volumes:
  pgdata:

Une seule commande lance toute la stack : docker compose up. Pour arrêter : docker compose down.

Docker Hub

Docker Hub est le plus grand registre d’images de conteneurs public. Il héberge des millions d’images, dont les images officielles (Python, Node, PostgreSQL, NVIDIA CUDA) et les images communautaires. Les registres alternatifs incluent GitHub Container Registry (GHCR), AWS ECR, Google GCR, Azure ACR, et Harbor (self-hosted).

Docker Desktop

Docker Desktop est l’application graphique pour macOS et Windows qui intègre Docker Engine, Docker CLI, Docker Compose, et un cluster Kubernetes local. La version 2026 inclut des fonctionnalités notables :

Docker Model Runner : permet d’exécuter des modèles ML localement dans Docker, avec support vLLM Metal (pour les GPU Apple Silicon) et inspection des requêtes/réponses pour le debug.

Docker MCP Toolkit : organise les serveurs MCP (Model Context Protocol) en collections nommées (profiles) et permet de créer des catalogues personnalisés pour les équipes. Intégration OAuth pour les serveurs MCP communautaires.

Gordon : assistant IA intégré qui propose des suggestions contextuelles quand les commandes docker build, docker run ou docker compose échouent.

Docker Hardened Images : images sécurisées et scannées, gérées via le nouveau plugin CLI dhi.

Docker Desktop : licence Docker Desktop est gratuit pour un usage personnel et éducatif. Pour les entreprises de plus de 250 employés ou plus de 10 M$ de CA, une licence commerciale est requise (plans Pro, Team, Business). Docker Engine (CLI + daemon) reste open source et gratuit pour tous les usages.

Docker pour l’IA et le ML

Docker est devenu un outil fondamental en MLOps. Chaque modèle ML en production est typiquement packagé dans un conteneur Docker.

Reproductibilité garantie

Un modèle ML dépend de dizaines de bibliothèques avec des versions spécifiques. Un changement de version de NumPy ou PyTorch, même mineur, peut modifier les résultats d’inférence. Le conteneur Docker fige l’environnement exact : même Python, mêmes bibliothèques, même configuration. Ce qui tourne sur le laptop du data scientist tourne de manière identique sur le serveur de production.

Conteneurs GPU avec NVIDIA Container Toolkit

Le NVIDIA Container Toolkit (anciennement nvidia-docker) permet aux conteneurs d’accéder aux GPU de l’hôte. C’est indispensable pour le serving de modèles de deep learning et de LLM. L’option --gpus all expose tous les GPU au conteneur.

# Installation du NVIDIA Container Toolkit (Ubuntu)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey 
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
# ... (suivre la doc officielle NVIDIA pour le repo apt)
sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

# Vérifier l'accès GPU
docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 nvidia-smi

Les images NVIDIA NGC fournissent des environnements pré-configurés avec CUDA, cuDNN, et les frameworks ML (PyTorch, TensorFlow, TensorRT). Ces images sont optimisées pour la performance sur GPU NVIDIA.

Packaging de modèles ML

Les runtimes de model serving (BentoML, TorchServe, Triton) produisent des images Docker optimisées. BentoML est particulièrement populaire car il simplifie le packaging : vous définissez un Service Python, BentoML génère automatiquement un Dockerfile optimisé et une image OCI-conforme avec une API REST/gRPC standardisée.

Pour le serving de LLM, vLLM fournit des images Docker prêtes à l’emploi avec endpoints compatibles OpenAI. Un LLM auto-hébergé se lance en une commande :

docker run --gpus all -p 8000:8000 
  -e HF_TOKEN=$HF_TOKEN 
  vllm/vllm-openai:latest 
  --model meta-llama/Llama-3.1-8B-Instruct

Bonnes pratiques Docker

Utilisez des images de base slim. python:3.12-slim (environ 150 Mo) plutôt que python:3.12 (environ 1 Go). Pour encore plus léger, python:3.12-alpine (environ 50 Mo), mais attention aux incompatibilités avec certaines bibliothèques ML qui dépendent de glibc.

Exploitez le cache de build. Copiez requirements.txt et installez les dépendances avant de copier le code source. Les dépendances changent rarement, le code change souvent. Cette simple optimisation évite de ré-installer toutes les dépendances à chaque build.

Multi-stage builds. Séparez l’étape de build (compilation, installation de dépendances) de l’image finale. L’image finale ne contient que le strict nécessaire, pas les outils de build.

N’exécutez jamais en root. Ajoutez USER appuser dans votre Dockerfile. C’est la mesure de sécurité la plus simple et la plus impactante.

Créez un .dockerignore. Excluez .git, __pycache__, venv, .env, les datasets d’entraînement, et les checkpoints intermédiaires. Sans ce fichier, Docker copie tout dans le contexte de build, augmentant inutilement la taille de l’image et les temps de build.

Épinglez les versions. Utilisez python:3.12.3-slim plutôt que python:3.12-slim ou pire, latest. Les tags non épinglés changent silencieusement et cassent la reproductibilité.

Scannez vos images. Utilisez docker scout (intégré), Trivy, ou Snyk pour détecter les vulnérabilités dans les couches de base avant le déploiement.

Secrets dans les images Ne mettez jamais de clés API, mots de passe ou certificats dans un Dockerfile (même dans un ENV). Les couches Docker sont inspectables. Injectez les secrets au runtime via des variables d’environnement, Docker secrets, ou un gestionnaire de secrets (Vault, AWS Secrets Manager).

Networking et volumes Docker

Networking

Docker crée des réseaux virtuels pour isoler la communication entre conteneurs. Par défaut, tous les conteneurs sur le même réseau Docker peuvent communiquer entre eux en utilisant le nom du conteneur comme hostname. Les types de réseau principaux :

bridge (défaut) : réseau isolé sur l’hôte. Les conteneurs communiquent entre eux, mais sont isolés du réseau externe sauf si des ports sont explicitement exposés (-p).

host : le conteneur partage directement le réseau de l’hôte. Aucune isolation réseau, mais pas d’overhead de NAT. Utile pour les applications nécessitant les meilleures performances réseau.

none : pas de réseau. Le conteneur est complètement isolé. Utile pour les workloads qui n’ont pas besoin de connectivité (certains jobs de batch processing).

# Créer un réseau personnalisé
docker network create mon-reseau-ml

# Lancer des conteneurs sur le même réseau
docker run -d --network mon-reseau-ml --name model-server mon-modele:v1
docker run -d --network mon-reseau-ml --name api-gateway mon-api:v1

# L'API peut accéder au modèle via http://model-server:8001

Volumes

Les conteneurs sont éphémères : quand un conteneur s’arrête ou est supprimé, ses données disparaissent. Les volumes Docker fournissent du stockage persistant, découplé du cycle de vie des conteneurs. Trois types :

Named volumes : gérés par Docker, stockés dans un répertoire Docker sur l’hôte. C’est le choix recommandé pour les données de production (bases de données, caches de modèles).

Bind mounts : montage direct d’un répertoire de l’hôte dans le conteneur. Idéal pour le développement local (le code source de l’hôte est accessible dans le conteneur en temps réel).

tmpfs mounts : stockage en mémoire RAM, jamais écrit sur disque. Utile pour les données sensibles temporaires ou les caches haute performance.

# Named volume pour une base de données
docker run -d -v pgdata:/var/lib/postgresql/data postgres:16

# Bind mount pour le développement (code source synchronisé)
docker run -d -v $(pwd)/src:/app/src mon-app:dev

# Volume pour le cache de modèles Hugging Face
docker run --gpus all -v hf-cache:/root/.cache/huggingface mon-modele:v1

Cache des modèles Hugging Face Les modèles LLM téléchargés depuis Hugging Face pèsent plusieurs Go. Sans volume persistant, Docker les re-télécharge à chaque redémarrage du conteneur. Montez un volume nommé sur ~/.cache/huggingface pour persister le cache entre les redémarrages.

Docker vs les alternatives

Outil	Différence par rapport à Docker	Quand le préférer
Podman	Daemonless, rootless par défaut, CLI compatible Docker	Environnements sécurisés, Red Hat/Fedora, pas de daemon
containerd	Runtime bas niveau, pas de CLI de build	Runtime K8s (utilisé par GKE, EKS), production
Buildah	Build d’images uniquement, daemonless	Pipelines CI/CD sans daemon Docker
Kaniko	Build d’images dans K8s sans Docker daemon	Build d’images dans des clusters K8s
nerdctl	CLI Docker-compatible pour containerd	Environnements sans Docker Desktop

Docker reste le choix par défaut pour le développement local et le build d’images. Les alternatives sont surtout pertinentes en production (containerd comme runtime K8s), en CI/CD (Kaniko, Buildah), ou dans les environnements où le daemon Docker pose des problèmes de sécurité (Podman).

Erreurs courantes

Images de plusieurs Go. Une image Python avec PyTorch et CUDA peut dépasser 10 Go. Utilisez des multi-stage builds, des images slim, et ne copiez que les fichiers nécessaires. Chaque Go d’image rallonge le pull, le push, et le cold start.

Pas de .dockerignore. Sans ce fichier, le répertoire .git (potentiellement des centaines de Mo), les virtualenvs, et les fichiers de données d’entraînement se retrouvent dans l’image.

Utiliser latest. Le tag latest n’a aucune sémantique de version. Il pointe vers la dernière image poussée, qui peut changer à tout moment. Un build reproductible nécessite des tags de version explicites.

Stocker des données dans le conteneur. Les conteneurs sont éphémères. Quand un conteneur est supprimé, ses données disparaissent. Utilisez des volumes Docker (-v) pour les données persistantes : bases de données, logs, modèles mis à jour.

Oublier le HEALTHCHECK. Sans health check, ni Docker ni Kubernetes ne peuvent détecter si votre application est fonctionnelle. Ajoutez un HEALTHCHECK dans le Dockerfile ou configurez des probes dans K8s.

Questions fréquentes sur Docker

Quelle est la différence entre Docker et Kubernetes ?

Docker construit et exécute des conteneurs individuels. Kubernetes orchestre des clusters de conteneurs à grande échelle : auto-scaling, load balancing, rolling updates, self-healing. Docker est l’outil de build et de test local. Kubernetes est l’outil de déploiement et de gestion en production. Les deux sont complémentaires : vous utilisez Docker pour créer vos images, Kubernetes pour les déployer.

Docker est-il gratuit ?

Docker Engine (CLI + daemon) est open source et gratuit pour tous les usages. Docker Desktop est gratuit pour un usage personnel, éducatif et pour les petites entreprises (moins de 250 employés et moins de 10 M$ de CA). Au-delà, une licence commerciale est requise : Pro (5 $/mois), Team (9 $/user/mois), Business (24 $/user/mois). Alternative gratuite : Podman (compatible CLI Docker, sans daemon, sans licence commerciale).

Docker est-il nécessaire pour le machine learning ?

Pas pour l’expérimentation. Mais dès que vous déployez un modèle en production, Docker devient quasi-indispensable pour garantir la reproductibilité (mêmes dépendances en dev et prod), la portabilité (déployez sur n’importe quel cloud), et l’intégration avec les outils MLOps (KServe, BentoML, Kubeflow). Les runtimes de model serving produisent des conteneurs Docker prêts à déployer.

Comment réduire la taille d’une image Docker pour le ML ?

Cinq techniques : (1) images de base slim (python:3.12-slim), (2) multi-stage builds (séparer build et runtime), (3) .dockerignore pour exclure les fichiers inutiles, (4) --no-cache-dir sur pip pour ne pas stocker les fichiers d’installation, (5) ne copier que le modèle final (pas les checkpoints intermédiaires ni les datasets d’entraînement). Pour les modèles GPU, utilisez les images NVIDIA NGC optimisées plutôt que d’installer CUDA vous-même.

Quelle est la dernière version de Docker ?

Docker Engine v29.3.0 (mars 2026) est la version stable actuelle, avec BuildKit v0.28.0 et containerd mis à jour. Docker Desktop reçoit des mises à jour mensuelles avec des fonctionnalités récentes comme Docker Model Runner (exécution de modèles ML locaux avec support vLLM), Docker MCP Toolkit (gestion des serveurs MCP), et Gordon (assistant IA pour le debugging de commandes).