Docker

Docker est une plateforme open source qui permet de créer, partager et exécuter des applications dans des conteneurs : des processus isolés qui embarquent leur propre système de fichiers, avec le code, les bibliothèques et les paquets système, tout en partageant le noyau du système d’exploitation de l’hôte. dotCloud, l’entreprise qui a ensuite pris le nom de Docker, Inc., a rendu la plateforme open source en mars 2013. Son outil en ligne de commande, son format d’image à couches et son registre public ont fait des conteneurs Linux un outil courant pour les développeurs. En apprentissage automatique, une image Docker fixe la version exacte de Python, les bibliothèques CUDA, la version de PyTorch et les poids du modèle, afin qu’un modèle se comporte de la même façon sur un ordinateur portable, un serveur GPU, un exécuteur d’intégration continue et un appareil en périphérie.

Fonctionnement de Docker#

Un Dockerfile répertorie les étapes de création d’une image : une image de base, les commandes d’installation des paquets, les fichiers à copier et la commande à exécuter au démarrage. Chaque instruction RUN, COPY ou ADD ajoute une couche en lecture seule, et la compilation suivante réutilise les couches mises en cache jusqu’à ce qu’une instruction ou l’un de ses fichiers d’entrée change. Les dépendances installées au début restent ainsi en cache, tandis que le code de l’application est recompilé en quelques secondes. Une image est cette pile de couches, à laquelle s’ajoutent des métadonnées. Un conteneur est une instance en cours d’exécution d’une image, surmontée d’une fine couche inscriptible, qui est supprimée avec le conteneur, sauf si les données sont enregistrées dans un volume monté.

La commande docker communique avec Docker Engine, un démon en arrière-plan qui confie chaque conteneur à containerd et au moteur d’exécution de bas niveau runc. Ceux-ci utilisent les espaces de noms Linux pour isoler les processus, le réseau et le système de fichiers d’un conteneur, et les cgroups pour limiter son CPU et sa mémoire. Les images sont partagées par l’intermédiaire de registres comme Docker Hub, GitHub Container Registry, NVIDIA NGC et le registre propre à chaque fournisseur cloud. Elles respectent le format d’image de l’Open Container Initiative : Podman, containerd et Kubernetes peuvent donc les exécuter sans modification.

Ultralytics publie des images Docker officielles pour chaque cible matérielle, notamment les GPU CUDA, les CPU, les cartes ARM64, les appareils NVIDIA Jetson et les GPU AMD. Chaque image porte aussi le numéro de version Ultralytics, pour des compilations reproductibles. L’image légère latest-python utilisée ci-dessous contient déjà Python, PyTorch, le paquet ultralytics et les poids nano de YOLO26 ; le Dockerfile du projet n’a donc qu’à ajouter son propre code :

# Official Ultralytics CPU image with Python, PyTorch, ultralytics, and yolo26n.pt
FROM ultralytics/ultralytics:latest-python

# Install extra dependencies in their own layer, cached until requirements.txt changes
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application last, so code edits rebuild only this layer
COPY app.py .

# Command every container runs when it starts
CMD ["python", "app.py"]

docker build -t yolo-app . transforme ce fichier et les fichiers qui l’accompagnent en une image, et docker run --rm yolo-app démarre un conteneur à partir de cette image. En envoyant l’image vers un registre, toute autre machine peut récupérer et exécuter le même environnement, par exemple comme API de mise en service d’un modèle ou comme tâche nocturne d’inférence.

Docker pour l’apprentissage automatique#

Les conteneurs accèdent aux GPU par l’intermédiaire du NVIDIA Container Toolkit. Le pilote NVIDIA reste sur l’hôte, et l’image ne contient que les bibliothèques CUDA de l’espace utilisateur, qui doivent être compatibles avec ce pilote. Sous Linux, Docker 28.2 et les versions ultérieures activent CDI par défaut : --device nvidia.com/gpu=all demande donc les GPU comme périphériques CDI et conserve l’accès au GPU dans les conteneurs de longue durée, contrairement à l’ancien indicateur --gpus all, qui peut perdre cet accès lorsque l’hôte recharge systemd.

Deux autres paramètres sont importants pour l’entraînement. Les travailleurs de chargement des données PyTorch transmettent les lots au processus d’entraînement par mémoire partagée dans /dev/shm, que Docker limite à 64 Mo par défaut. Les conteneurs d’entraînement doivent donc être lancés avec --ipc=host ou une valeur --shm-size supérieure. Les jeux de données et les sorties doivent être placés dans des volumes montés, car un entraînement qui enregistre les points de contrôle dans le conteneur les perd lorsque celui-ci est supprimé. Épingler une étiquette de version ou le condensat de l’image plutôt que latest garantit qu’une tâche d’entraînement distribué ou un déploiement de modèle utilise la même image sur toutes les machines. Les serveurs d’inférence, comme NVIDIA Triton Inference Server, et les services gérés, comme Vertex AI, exécutent également les modèles sous forme d’images de conteneur.

Docker, machines virtuelles et Kubernetes#

• Machines virtuelles : Un hyperviseur émule le matériel, et chaque VM démarre son propre noyau invité. Cela isole davantage les charges de travail et permet d’utiliser n’importe quel système d’exploitation invité, au prix d’une image complète du système d’exploitation par VM et d’un démarrage plus lent. Comme les conteneurs partagent le noyau Linux de l’hôte, Docker Desktop sur macOS et Windows les exécute dans une VM Linux légère.
• Docker Compose : Définit plusieurs conteneurs qui s’exécutent ensemble sur un même hôte, par exemple une API d’inférence, un cache et un collecteur de métriques.
• Kubernetes : Planifie l’exécution des conteneurs sur un cluster, redémarre ceux qui échouent et adapte le nombre de réplicas en fonction du trafic. Kubernetes 1.24 a supprimé dockershim, son adaptateur intégré pour Docker Engine. Les clusters exécutent donc les conteneurs via containerd ou CRI-O. Les images créées avec Docker y fonctionnent toujours, car ce sont des images OCI standard.