Docker : qu’est-ce que c’est et comment l’utiliser ?

Docker est la plateforme de conteneurisation la plus utilisée. Découvrez tout ce que vous devez savoir à son sujet : qu’est-ce que c’est, à quoi ça sert, comment ça fonctionne et quelles formations permettent d’apprendre à l’utiliser.

Les conteneurs et les microservices sont de plus en plus utilisés pour le développement et le déploiement des applications. C’est ce qu’on appelle le développement « cloud-native ». Dans ce contexte, Docker est devenue une solution massivement exploitée en entreprise.

Qu’est-ce qu’un conteneur ?

Avant de découvrir Docker, vous devez comprendre ce qu’est un conteneur. Il s’agit d’un environnement d’exécution léger, et d’une alternative aux méthodes de virtualisation traditionnelles basées sur les machines virtuelles. Concrètement, un conteneur est un composant exécutable standardisé qui regroupe le code source d’une application avec toutes ses dépendances : bibliothèques, outils système, variables d’environnement et fichiers de configuration. L’une des pratiques clés du développement logiciel moderne est d’isoler les applications déployées sur un même hôte afin d’éviter qu’elles interfèrent entre elles.

Avec une machine virtuelle, une application embarque un système d’exploitation complet de plusieurs gigaoctets, géré par un hyperviseur. Avec un conteneur, seuls les composants strictement nécessaires à l’exécution sont inclus : le conteneur partage le noyau (kernel) du système d’exploitation hôte. Cette architecture allégée réduit considérablement l’empreinte sur l’infrastructure. Un conteneur est plus léger, démarre presque instantanément et s’adapte facilement aux besoins fluctuants liés au scaling d’une application.

Qu’est-ce que Docker ?

Docker est une plateforme de conteneurisation open source lancée en 2013, qui permet aux développeurs de créer, déployer, exécuter et gérer des applications sous forme de conteneurs. C’est la solution la plus utilisée dans ce domaine : plus facile à prendre en main que ses concurrentes, elle s’appuie sur une large communauté qui contribue en permanence à son développement. Initialement conçue pour Linux, Docker prend également en charge les environnements Windows et macOS grâce à une couche de virtualisation dédiée.

Prenons un exemple concret : un développeur crée une application web sur son poste de travail, avec ses propres bibliothèques et sa propre version de Python. En production, le serveur dispose d’une configuration différente et l’application refuse de démarrer. Avec Docker, ce problème disparaît : l’application est empaquetée dans un conteneur qui embarque tout son environnement d’exécution, dépendances incluses. Ce conteneur s’exécute de façon identique sur le poste du développeur, sur le serveur de test et en production. C’est ce principe de portabilité et de reproductibilité qui a fait le succès massif de Docker en entreprise.

Conteneurs Docker vs machines virtuelles : quelles différences ?

Le fonctionnement des machines virtuelles

Une machine virtuelle est une simulation logicielle complète d’un serveur : elle embarque un système d’exploitation entier, des pilotes, des bibliothèques et des applications, le tout géré par un hyperviseur qui distribue les ressources matérielles entre chaque VM. Chaque machine virtuelle pèse plusieurs gigaoctets et nécessite un temps de démarrage comparable à celui d’un système réel.

Le fonctionnement des conteneurs Docker

Un conteneur Docker fonctionne selon une logique radicalement différente. Au lieu d’embarquer un OS complet, il partage le noyau du système d’exploitation hôte et n’embarque que les bibliothèques et dépendances strictement nécessaires à l’application. La taille d’un conteneur se mesure en mégaoctets, là où une VM se compte en gigaoctets. Cette légèreté se traduit par des démarrages quasi instantanés, une utilisation optimisée des ressources et une densité bien plus élevée sur un même serveur. En contrepartie, les conteneurs offrent un niveau d’isolation légèrement inférieur, puisqu’ils partagent le même noyau.

Complémentarité et cas d’usage

Ces deux technologies sont en réalité complémentaires. Les conteneurs sont privilégiés pour les déploiements cloud-native, les architectures microservices et les pipelines CI/CD. Les VM restent pertinentes lorsqu’une isolation totale est requise, ou lorsqu’il faut exécuter plusieurs systèmes d’exploitation différents sur un même serveur.

Critère	Machine virtuelle (VM)	Conteneur Docker
Taille	Plusieurs gigaoctets (OS complet inclus)	Quelques mégaoctets (uniquement les dépendances nécessaires)
Démarrage	Lent (chargement d’un OS complet)	Quasi instantané (pas d’OS à initialiser)
Isolation	Très forte (OS dédié par VM)	Bonne, mais partage du noyau hôte
Consommation de ressources	Élevée (hyperviseur + OS par VM)	Faible (noyau partagé, pas de duplication OS)
Portabilité	Limitée (dépend de l’hyperviseur)	Très élevée (fonctionne sur tout environnement Docker)
Scalabilité	Limitée par la surcharge des VM	Rapide et horizontale, facilitée par Kubernetes
Cas d’usage typique	Multi-OS sur un même hôte, isolation maximale	Microservices, CI/CD, applications cloud-native
Gestion	Hyperviseur (VMware, Hyper-V…)	Docker Engine, orchestré par Kubernetes

L’histoire de Docker

Docker Inc a été fondée par Solomon Hykes, Kamel Founadi et Sebastien Pahl au cours du groupe d’incubation de startups Y Combinator Summer 2010. L’entreprise fut lancée en 2011 et figura parmi les 12 startups de la première cohorte de Founder’s Den. Le projet fut initié par Solomon Hykes en France, sous la forme d’un projet interne de l’entreprise de plateforme en tant que service dotCloud.

En 2013, Docker fut présentée au public à Santa Clara dans le cadre de la PyCon, avec un objectif clair : simplifier le déploiement d’applications sur des serveurs. Le logiciel fut lancé en open source en mars 2013. À l’époque, LXC était utilisé comme environnement d’exécution par défaut, avant d’être remplacé un an plus tard, avec la version 0.9, par son propre composant libcontainer écrit en langage Go.

Au fil des années, Docker a noué de nombreux partenariats stratégiques avec les géants du Cloud et de l’IT : Red Hat en 2013, Microsoft, IBM et Amazon Web Services en 2014, Oracle en 2015, puis Cisco, Google et Huawei. Depuis 2016, Docker peut être utilisé nativement sur Windows 10. Cette même année, une analyse de LinkedIn révèle que le nombre de mentions du logiciel sur les profils des utilisateurs a augmenté de 160 %. Technologie quasi inconnue à ses débuts, Docker est aujourd’hui devenu un environnement d’exécution standardisé, officiellement pris en charge pour de nombreux produits d’entreprise à grande échelle.

Comment fonctionne Docker ?

Le fonctionnement de Docker repose sur le noyau Linux et ses fonctions clés, notamment les groupes de contrôle (cgroups) et les espaces de noms (namespaces), qui permettent de séparer les processus pour qu’ils s’exécutent de façon indépendante. Tous les outils de conteneurisation comme Docker sont associés à un modèle de déploiement basé sur une image, ce qui simplifie le partage d’une application entre plusieurs environnements. Docker permet également d’automatiser le déploiement des applications au sein d’un environnement de conteneurs, offrant aux utilisateurs la capacité d’accélérer le déploiement, de contrôler les versions et de les attribuer.

Mécanismes Linux sous-jacents : namespaces, cgroups, UnionFS

Docker s’appuie sur trois primitives du noyau Linux pour garantir que chaque conteneur fonctionne dans un environnement cloisonné et contrôlé :

• Namespaces (espaces de noms) : ils restreignent ce qu’un processus peut voir sur le système. Chaque conteneur dispose de son propre espace de noms pour les processus (PID), le réseau (NET), le système de fichiers (MNT), le nom d’hôte (UTS) et les utilisateurs (USER). Concrètement, un conteneur croit être seul sur la machine : il ne voit ni les processus, ni les interfaces réseau des autres conteneurs.
• Cgroups (groupes de contrôle) : ils limitent et répartissent les ressources matérielles allouées à chaque conteneur : CPU, mémoire vive, bande passante disque et réseau. C’est ce mécanisme qui empêche un conteneur de monopoliser les ressources de l’hôte au détriment des autres.
• UnionFS (système de fichiers en couches) : Docker utilise un système de fichiers par union, comme OverlayFS, pour construire les images en couches superposées. Chaque instruction du Dockerfile crée une nouvelle couche en lecture seule. Lorsqu’un conteneur démarre, une fine couche inscriptible est ajoutée par-dessus, sans toucher aux couches inférieures. Ce mécanisme rend les images légères, partageables et rapides à déployer.

Cycle de vie : build, push, run

Le flux de travail typique avec Docker s’articule en trois étapes du développement local jusqu’à l’exécution en production :

1. Build : le développeur rédige un Dockerfile décrivant l’environnement de l’application (image de base, dépendances, variables, ports). La commande docker build lit ce fichier et génère une image Docker, artefact immuable constitué de couches empilées.
2. Push : une fois l’image construite et validée, elle est envoyée vers un registre (Docker Hub ou un registre privé) via la commande docker push. L’image est alors accessible depuis n’importe quel environnement disposant d’une connexion à ce registre.
3. Run : sur l’environnement cible, la commande docker run récupère l’image depuis le registre et lance une instance de conteneur. Plusieurs conteneurs peuvent être démarrés simultanément à partir de la même image, chaque instance restant isolée des autres.

Les composants clés de Docker

La plateforme Docker repose sur plusieurs technologies et composants qui s’articulent ensemble pour couvrir l’ensemble du cycle de vie d’une application conteneurisée : construction, distribution et exécution.

Docker Engine, Daemon et Client

Docker Engine est le moteur central de la plateforme : c’est l’application à installer sur la machine hôte pour créer, exécuter et gérer des conteneurs. Il repose sur une architecture client/serveur composée de trois éléments interdépendants. Le Docker Daemon (dockerd) s’exécute en arrière-plan sur l’hôte et traite les requêtes API afin de gérer les images, les conteneurs et les volumes de stockage. Le Docker Client est l’interface principale de l’utilisateur : il reçoit les commandes via la ligne de commande (CLI) et les transmet au Daemon grâce à l’API REST. Ces deux composants peuvent s’exécuter sur la même machine ou à distance. Docker Engine existe en deux éditions : la Community Edition, open source et gratuite, et l’Enterprise Edition, payante, qui ajoute des fonctionnalités de gestion avancées.

Composant	Rôle	Points clés
Docker Engine	Moteur principal de la plateforme	Application client/serveur, éditions Community (gratuite) et Enterprise (payante)
Docker Daemon (dockerd)	Traitement des requêtes API en arrière-plan	Gère les images, les conteneurs et les volumes de stockage
Docker Client (CLI)	Interface principale de l’utilisateur	Transmet les commandes au Daemon via l’API REST, utilisable en local ou à distance

Dockerfile, images et conteneurs

Ces trois artefacts forment la chaîne complète de création et d’exécution d’un conteneur Docker. On part d’un Dockerfile pour construire une image, puis on instancie cette image en un ou plusieurs conteneurs actifs.

1. Le Dockerfile est un fichier texte qui contient toutes les instructions de construction d’une image Docker. Il précise le système d’exploitation de base, les langages, les dépendances, les variables d’environnement, les emplacements de fichiers et les ports réseau requis.
2. L’image Docker est un modèle en lecture seule généré par la commande docker build à partir du Dockerfile. Elle est composée de plusieurs couches empaquetant toutes les installations, bibliothèques et codes d’application nécessaires à un environnement de conteneur pleinement opérationnel. Une même image peut servir de base à de multiples projets.
3. Le conteneur Docker est une instance active de l’image, lancée via la commande docker run. Au démarrage, une couche inscriptible est ajoutée sur l’image pour stocker tous les changements apportés durant le runtime. Les conteneurs sont conçus pour être temporaires, mais peuvent être arrêtés et redémarrés dans le même état. Plusieurs instances d’une même image peuvent s’exécuter simultanément.

Registre Docker et Docker Hub

Concept et fonctionnement des registres

Le registre Docker est un système de stockage et de distribution centralisé pour les images Docker. Il permet d’effectuer des opérations push (publier une image) et pull (récupérer une image) vers et depuis des dépôts organisés. Chaque dépôt peut contenir plusieurs images Docker, chacune identifiée par un tag (par exemple nginx:1.25, python:3.11 ou monapp:latest).

Types de registres disponibles

• Docker Hub (hub.docker.com) est le registre public officiel de Docker, avec plus de 100 millions d’images. On y trouve des images de projets open source, de vendeurs logiciels certifiés et de développeurs individuels. Les Personal Access Tokens (PAT) remplacent les mots de passe depuis 2024 : il est conseillé d’en créer un avec les permissions minimales nécessaires et de le stocker dans un gestionnaire de secrets.
• Les registres privés permettent aux entreprises d’héberger leurs images de façon sécurisée : Amazon ECR, Google Artifact Registry, Azure Container Registry, Red Hat Quay ou un registre auto-hébergé sont les solutions les plus répandues.

Gestion des tags et authentification

• La gestion des tags est essentielle pour organiser les versions d’une image. Il est recommandé d’éviter de n’utiliser que le tag latest en production afin de garantir la reproductibilité des déploiements.
• L’authentification s’effectue via la commande docker login. Le rate limiting de Docker Hub est strict : 10 pulls par heure en mode anonyme, 100 pulls par heure pour un compte authentifié.

Docker Desktop

Docker Desktop est l’application native proposée par Docker pour Windows, macOS et Linux. Elle constitue la façon la plus simple d’exécuter, de construire, de déboguer et de tester des applications conteneurisées en environnement local. Elle regroupe dans une interface unifiée Docker Engine, le client CLI, Docker Compose, Kubernetes et l’accès direct à Docker Hub. Deux éditions sont disponibles : l’édition Community, gratuite, et l’édition Enterprise, payante, qui ajoute des fonctionnalités avancées de sécurité, d’orchestration et de gestion.

Comment écrire un Dockerfile ?

Un Dockerfile est un fichier texte contenant la liste des instructions nécessaires à la création d’une image Docker. Une fois le fichier rédigé, la commande docker build génère l’image couche par couche, en suivant l’ordre des instructions. Chaque instruction RUN crée une nouvelle couche dans l’image. Ce mécanisme rend les images portables, reproductibles et partageables via un registre comme Docker Hub.

Instructions essentielles (FROM, RUN, COPY, CMD, ENTRYPOINT…)

Instruction	Rôle	Exemple
FROM	Définit l’image de base à partir de laquelle l’image est construite. Obligatoire en première instruction.	FROM python:3.11-slim
WORKDIR	Définit le répertoire de travail à l’intérieur du conteneur pour les instructions suivantes.	WORKDIR /app
COPY	Copie des fichiers ou répertoires depuis la machine hôte vers l’image. À privilégier pour les cas courants.	COPY . /app
ADD	Similaire à COPY, mais supporte également les archives (décompression automatique) et les URL distantes.	ADD archive.tar.gz /app
RUN	Exécute des commandes qui construisent et configurent l’image pendant le build ; chaque instruction RUN crée une nouvelle couche.	RUN pip install -r requirements.txt
ENV	Définit des variables d’environnement disponibles lors du build et à l’exécution du conteneur.	ENV PORT=8080
EXPOSE	Indique le port sur lequel l’application écoute à l’intérieur du conteneur. Il s’agit d’une documentation pour les développeurs, pas d’une ouverture réelle du port vers l’extérieur.	EXPOSE 8080
CMD	Définit la commande par défaut qui s’exécute au démarrage du conteneur. Elle peut être surchargée par des arguments passés en ligne de commande.	CMD ["python", "app.py"]
ENTRYPOINT	Définit la commande exécutable lancée à chaque démarrage du conteneur. Les arguments passés en ligne de commande s’ajoutent sans la remplacer.	ENTRYPOINT ["python"]
USER	Spécifie l’utilisateur sous lequel les instructions suivantes et le processus du conteneur s’exécutent. Recommandé pour éviter d’utiliser root.	USER node

La différence entre CMD et ENTRYPOINT

ENTRYPOINT et CMD définissent toutes les deux ce qui s’exécute au démarrage d’un conteneur, mais elles servent des objectifs différents. La règle pratique : utilisez ENTRYPOINT pour la commande principale et CMD pour fournir des arguments par défaut. Lorsque les deux sont spécifiées, CMD fournit les arguments par défaut à ENTRYPOINT. Par exemple, une image Python peut définir ENTRYPOINT ["python"] et CMD ["app.py"] : le conteneur lancera python app.py par défaut, mais un utilisateur pourra passer un autre script sans modifier l’image.

Bonnes pratiques et multi-stage builds

• Choisir une image de base légère : privilégier les images Slim ou Alpine pour réduire la taille finale et la surface d’attaque.
• Regrouper les instructions RUN : combiner les commandes en une seule instruction RUN réduit le nombre de couches.
• Utiliser un fichier .dockerignore : exclure les fichiers inutiles (.git/, node_modules/, logs/) accélère le build et allège l’image.
• Ne jamais exécuter en root : toujours utiliser l’instruction USER avec un utilisateur dédié.
• Épingler les versions d’images : éviter le tag latest pour garantir la cohérence d’un build à l’autre.
• Optimiser l’ordre des instructions pour le cache : placer les instructions stables (ENV, WORKDIR, EXPOSE) en début de Dockerfile pour éviter d’invalider les couches inutilement.

Les multi-stage builds pour des images allégées

Les multi-stage builds permettent de construire l’application dans une image temporaire contenant tous les outils nécessaires, puis de copier uniquement les fichiers utiles dans une image finale plus légère. Un Dockerfile multi-stage contient plusieurs instructions FROM : la première étape réalise la compilation, et la seconde ne récupère que les artefacts produits, sans embarquer le compilateur ni les dépendances de développement. L’image finale peut ainsi passer de plusieurs gigaoctets à quelques dizaines de mégaoctets. Voici un exemple pour une application Node.js :

Avec ces techniques combinées, il est possible de réduire la taille des images Docker de 50 à 80 %, ce qui accélère les déploiements, réduit les coûts de stockage et limite la surface d’exposition aux vulnérabilités.

Quelles sont les commandes Docker essentielles ?

Le client Docker s’utilise via une interface de ligne de commande (CLI). Maîtriser les commandes fondamentales est indispensable pour créer des images, gérer des conteneurs, interagir avec un registre et diagnostiquer les problèmes. Voici les dix commandes à connaître en priorité.

Les dix commandes essentielles

Commande	Rôle	Exemple d’utilisation
docker build	Construit une image Docker à partir d’un Dockerfile. Chaque instruction du fichier crée une nouvelle couche dans l’image finale.	docker build -t mon-app:1.0 .
docker pull	Télécharge une image depuis un registre (Docker Hub par défaut) vers la machine locale.	docker pull nginx:latest
docker push	Envoie une image locale vers un registre distant afin de la partager ou de la déployer sur d’autres environnements.	docker push moncompte/mon-app:1.0
docker run	Lance un nouveau conteneur à partir d’une image. Crée et démarre le conteneur en une seule instruction.	docker run -d -p 8080:80 nginx
docker exec	Exécute une commande à l’intérieur d’un conteneur déjà en cours d’exécution. Idéal pour inspecter ou déboguer sans redémarrer.	docker exec -it mon-conteneur sh
docker logs	Affiche les journaux de sortie d’un conteneur. Essentiel pour diagnostiquer une anomalie ou surveiller un service.	docker logs --follow mon-conteneur
docker ps	Liste les conteneurs en cours d’exécution. Avec l’option -a, affiche également les conteneurs arrêtés.	docker ps -a
docker inspect	Retourne des informations détaillées au format JSON sur un conteneur ou une image : configuration réseau, volumes montés, variables d’environnement, état.	docker inspect mon-conteneur
docker rm	Supprime un ou plusieurs conteneurs arrêtés. Avec l’option -f, force la suppression d’un conteneur actif.	docker rm mon-conteneur
docker rmi	Supprime une ou plusieurs images locales pour libérer de l’espace disque.	docker rmi mon-app:1.0

Cycle de vie et nettoyage

Ces commandes couvrent l’ensemble du cycle de vie d’un conteneur : de la construction de l’image (build) à sa publication (push), en passant par son exécution (run), son débogage (exec, logs, inspect) et son nettoyage (rm, rmi). La CLI Docker propose également docker system prune pour supprimer en une seule commande tous les conteneurs arrêtés, images non utilisées et caches de build accumulés.

Gérer et optimiser les images Docker

Maîtriser les images Docker ne se limite pas à les créer et à les exécuter. En production, la gestion rigoureuse des images influe directement sur les performances, la rapidité des déploiements et les coûts d’infrastructure.

La structure en couches (layers)

Une image Docker est composée d’une succession de couches superposées. Chaque instruction du Dockerfile génère une nouvelle couche représentant l’ensemble des modifications apportées au système de fichiers à cette étape. Ces couches sont immuables. Lorsqu’un développeur modifie une image, seule la couche concernée est recréée, les couches inférieures restant intactes et réutilisables. Cette architecture favorise le partage entre plusieurs images partageant une base commune.

Bonnes pratiques pour optimiser les images

Réduction de la taille et de la complexité

• Choisir une image de base légère : privilégier des images minimalistes comme Alpine Linux plutôt que des distributions complètes.
• Minimiser le nombre de couches : regrouper les commandes RUN dans une seule instruction lorsque cela est possible.
• Adopter les builds multi-étapes : ne conserver dans l’image finale que les artefacts nécessaires à l’exécution, en excluant les outils de compilation et les fichiers intermédiaires.
• Utiliser un fichier .dockerignore : exclure du contexte de build les fichiers inutiles (dossier node_modules, répertoire .git, fichiers de logs).

Optimisation du build et gestion des versions

• Utiliser le cache de build intelligemment : placer les instructions qui changent rarement (installation de dépendances) en début de Dockerfile et celles qui changent fréquemment (copie du code source) en fin de fichier.
• Tagger les images avec précision : identifier chaque image par un tag explicite (numéro de version, identifiant de commit) plutôt que de se reposer uniquement sur latest.
• Nettoyer régulièrement les images inutilisées : utiliser docker image prune, docker rmi ou docker system prune pour libérer l’espace disque.

Stockage et volumes Docker

Par défaut, toutes les données créées à l’intérieur d’un conteneur Docker sont éphémères : elles disparaissent dès que le conteneur est supprimé. Pour les applications nécessitant de la persistance, Docker propose trois mécanismes de stockage distincts : les volumes, les bind mounts et les tmpfs mounts.

Les trois types de stockage Docker

Type	Géré par	Emplacement des données	Persistance	Cas d’usage idéal
Volume	Docker	/var/lib/docker/volumes/ sur Linux	Oui, indépendante du conteneur	Production, bases de données, données applicatives
Bind mount	Utilisateur	N’importe où sur le système hôte	Oui, si les données existent sur le système hôte	Développement, hot-reload, débogage rapide
tmpfs	Système d’exploitation	Mémoire vive (RAM) uniquement	Non, données perdues à l’arrêt du conteneur	Secrets temporaires, cache, données sensibles

Les volumes Docker

Les volumes sont gérés par Docker et stockés dans un emplacement spécifique du système de fichiers hôte. Ils peuvent être partagés entre plusieurs conteneurs et offrent un moyen isolé et portable de stocker les données. C’est la solution recommandée pour la production, notamment pour les bases de données et les fichiers applicatifs critiques.

Les bind mounts

Les bind mounts pointent directement vers un emplacement spécifique du système de fichiers hôte. Le conteneur peut accéder aux données et les modifier en temps réel. Les développeurs utilisent souvent les bind mounts pour simplifier le débogage, en apportant des modifications au code et en voyant les résultats immédiats dans le conteneur.

Les tmpfs mounts

Le montage tmpfs stocke les données directement en RAM : performances fulgurantes, mais les données disparaissent à l’arrêt du conteneur. C’est idéal pour les secrets, le cache ou les fichiers temporaires. Les tmpfs mounts sont limités par la RAM disponible et ne fonctionnent que sur les hôtes Linux.

Bonnes pratiques pour les données persistantes

• Privilégiez les volumes nommés en production. Les bind mounts dépendent trop des chemins spécifiques à l’hôte et présentent des risques de sécurité.
• Réservez les bind mounts au développement. Rapides et pratiques, mais à ne pas utiliser en production.
• Utilisez tmpfs pour les données sensibles ou temporaires. Accès rapide, stockage éphémère, adapté aux secrets et aux caches.
• Planifiez la sauvegarde de vos volumes. Mettez en place une stratégie régulière avec des outils comme Restic ou Rclone.
• Partagez les volumes entre conteneurs avec précaution. Un volume nommé peut être monté simultanément sur plusieurs conteneurs, mais nécessite de gérer les accès concurrents pour éviter toute corruption de données.

Comment fonctionne le réseau Docker ?

Par défaut, chaque conteneur dispose de sa propre pile réseau isolée, incluant une adresse IP dédiée, et peut communiquer avec d’autres conteneurs au sein d’un réseau privé interne. Docker propose plusieurs pilotes réseau, chacun adapté à un cas d’usage précis.

Les quatre modes réseau principaux

Mode réseau	Description	Cas d’usage typique
bridge	Réseau NAT isolé, privé sur l’hôte. Mode par défaut à la création d’un conteneur.	Applications multi-conteneurs sur un seul hôte, développement local.
host	Le conteneur partage directement la pile réseau de l’hôte. Aucune isolation réseau, aucun NAT.	Applications nécessitant des performances maximales ou une très faible latence.
overlay	Réseau distribué couvrant plusieurs hôtes Docker. Utilisé avec Docker Swarm ou Kubernetes.	Déploiements en cluster, architectures distribuées en production.
macvlan	Assigne une adresse MAC propre au conteneur, l’intégrant directement au réseau physique.	Applications legacy nécessitant une présence directe sur le réseau LAN.

Le mode bridge

En mode bridge, le daemon Docker crée un pont virtuel (docker0) sur l’hôte. Chaque conteneur reçoit une interface Ethernet virtuelle connectée à ce pont, qui utilise le mécanisme NAT pour permettre les communications vers l’extérieur.

Il existe une distinction importante entre le bridge par défaut et un bridge personnalisé. Le bridge par défaut (docker0) ne permet pas la résolution DNS par nom de conteneur. Il est donc fortement recommandé de créer un bridge personnalisé : Docker y embarque un serveur DNS interne (127.0.0.11) qui permet aux conteneurs de se joindre par leur nom plutôt que par leur adresse IP.

Le mode host

Le mode host supprime entièrement le namespace réseau. Le conteneur partage directement la pile réseau de la machine hôte : pas de NAT, pas de mapping de ports, pas de pont virtuel. Ce mode améliore les performances mais réduit l’isolation. Il est utile pour les applications sensibles aux performances réseau, mais déconseillé lorsque l’isolation est requise.

Le mode overlay

Les réseaux overlay permettent aux conteneurs s’exécutant sur des hôtes différents de communiquer de manière sécurisée. Ce mode est à privilégier dans les environnements distribués, notamment avec Docker Swarm ou Kubernetes, pour les architectures de production à plusieurs nœuds.

L’exposition de ports

Par défaut, les services qui tournent à l’intérieur d’un conteneur ne sont pas accessibles depuis l’extérieur. Docker propose la publication de ports via l’option -p. L’option -p 8080:80 ouvre le port TCP 8080 sur la machine hôte et redirige le trafic vers le port TCP 80 à l’intérieur du conteneur.

L’instruction EXPOSE dans un Dockerfile est purement documentaire et n’a aucun impact direct sur l’accessibilité réseau du conteneur. Ce sont les options -p ou -P de la commande docker run qui configurent effectivement les règles de pare-feu et les redirections de port. Même si un Dockerfile expose de nombreux ports, aucun n’est accessible sans configuration explicite au démarrage.

Le DNS interne Docker

Sur un réseau bridge personnalisé, Docker exécute un serveur DNS embarqué qui résout les noms de conteneurs en adresses IP. C’est ce qui permet d’appeler http://api:3000 : Docker résout « api » en l’adresse IP du conteneur correspondant. Ce fonctionnement est particulièrement utile avec Docker Compose, où chaque service défini dans le fichier YAML est automatiquement joignable par son nom depuis les autres services du même réseau.

Qu’est-ce que Docker Compose ?

Définition et fonctionnalités principales

Docker Compose est un outil officiel de Docker conçu pour définir et gérer des applications multi-conteneurs. Il permet de décrire l’ensemble des services qui composent une application (serveur web, base de données, cache, etc.) dans un unique fichier YAML appelé docker-compose.yml. Une seule commande suffit ensuite pour démarrer, arrêter ou reconstruire tous les conteneurs de la stack. Il permet aussi de définir des volumes persistants, de configurer les réseaux internes entre conteneurs et de documenter les dépendances entre services. Un seul fichier garantit que chaque membre de l’équipe travaille avec une stack strictement identique, quel que soit son environnement.

Exemple pratique de configuration

Prenons un exemple concret : une application web composée de trois services (une application Node.js, une base de données PostgreSQL et un cache Redis).

Le service app dépend explicitement de db et cache grâce à la directive depends_on : Docker Compose démarre les conteneurs dans le bon ordre. Le volume nommé postgres_data assure la persistance des données même si le conteneur est redémarré. Pour lancer l’ensemble de la stack : docker compose up. Pour tout arrêter proprement : docker compose down.

Qu’est-ce que l’orchestration de conteneurs ?

L’orchestration de conteneurs désigne l’ensemble des processus permettant d’automatiser le déploiement, la gestion, la mise à l’échelle et la supervision d’applications conteneurisées. Dès qu’une application dépasse quelques conteneurs, coordonner manuellement leur cycle de vie devient impossible. Dans l’écosystème Docker, cette orchestration s’organise en trois niveaux selon la taille du déploiement : Docker Compose pour le développement local, Docker Swarm pour une orchestration intermédiaire, et Kubernetes comme norme de l’industrie pour les environnements de production à grande échelle. Ces solutions permettent notamment de répartir les ressources entre les conteneurs, d’ajouter ou supprimer des conteneurs, de gérer les interactions entre eux, de surveiller leur statut et d’équilibrer la charge entre les microservices.