Tuto Docker - Comprendre Docker (Partie1)

Article initialement publié en 2015, mis à jour en octobre 2026.

Cet article fait partie d'une série de billets portant sur Docker et son environnement :

• Tuto Docker : comprendre Docker (partie 1)
• Tuto Docker : démarrer Docker (partie 2)
• Tuto Docker : les commandes Docker (partie 3)

Sommaire

• Pourquoi un article sur Docker ?
• Présentation de Docker
• Qu'est-ce que Docker ?
• Docker, isoler un environnement ? Comme une VM ?
• Docker sur Windows et macOS : comment ça marche ?
• Docker, cas d'utilisation
• Docker, déployer vos applications facilement
• Conclusion

Pourquoi un article sur Docker ?

Lorsque je me suis lancé dans l'écriture de cet article, j'avais l'intention de décrire le fonctionnement de Docker ainsi que ses fondamentaux. À force d'écrire, il m'a bien fallu faire le constat que Docker est peut-être simple à décrire à la pause café, mais que le décrire de manière plus fonctionnelle est un peu plus compliqué que ça.

Aujourd'hui, je vais tenter d'être simple et concret. Mon objectif : vous faire comprendre le fonctionnement de Docker en 10 minutes.

Présentation de Docker

Docker est un produit développé par la société du même nom (Docker, Inc.). Initialement développé par un ingénieur français, Solomon Hykes, au sein de la société dotCloud, le produit a été dévoilé en mars 2013. Depuis, Docker est devenu le standard de fait de la conteneurisation : ses formats d'images et de conteneurs ont donné naissance au standard ouvert OCI (Open Container Initiative), utilisé aujourd'hui par tout l'écosystème, Kubernetes compris. Nous allons voir à quoi il sert et comment vous pouvez vous en servir au quotidien.

Qu'est-ce que Docker ?

Docker permet de créer des environnements isolés, appelés conteneurs (containers), dans lesquels on exécute des applications. L'idée est de lancer du code dans un environnement cloisonné, sans qu'il interfère avec le reste du système.

Pour cela, Docker s'appuie sur deux fonctionnalités natives du noyau Linux :

• les namespaces, qui isolent ce que voit un processus (ses autres processus, son réseau, son système de fichiers, ses utilisateurs…) ;
• les cgroups (control groups), qui limitent et mesurent les ressources qu'il consomme (RAM, CPU, I/O…).

Docker n'invente donc pas l'isolation : il la rend simple à utiliser. Sous le capot, le démon Docker (dockerd) délègue l'exécution des conteneurs à containerd puis à runc, deux briques open source conformes au standard OCI.

Aaah ok ! Donc en fait, Docker utilise simplement des fonctionnalités natives du noyau Linux ? Mais du coup, je peux l'utiliser sur Windows ou sur Mac ?

Oui, grâce à Docker Desktop, mais avec une subtilité que j'explique dans les paragraphes suivants.

À retenir : Docker permet de créer des environnements (appelés conteneurs) de manière à isoler des applications.

Image, conteneur, registry : le vocabulaire de base

Avant d'aller plus loin, trois mots que vous croiserez partout :

• Image : un modèle en lecture seule, composé de couches (layers), qui contient tout ce qu'il faut pour faire tourner une application (système de fichiers, dépendances, configuration). C'est le « moule ».
• Conteneur : une instance en cours d'exécution d'une image. On peut lancer autant de conteneurs que l'on veut à partir d'une même image.
• Registry : un entrepôt d'images, comme Docker Hub ou le registry intégré à GitLab. C'est un peu le « GitHub des images ».

Docker, isoler un environnement ? Comme une VM ?

Oui… et non ! Docker et les conteneurs ne se comportent pas comme une VM. Une machine virtuelle émule une machine complète et embarque son propre système d'exploitation, avec son propre noyau et ses propres ressources.

Dans le cas de Docker, tous les conteneurs partagent le noyau du système hôte. Il n'y a pas d'OS invité à démarrer. Techniquement, Docker n'est pas une VM, pas le moins du monde, mais en termes d'utilisation, on peut l'en rapprocher.

Lancer un environnement et isoler ses composants de ceux de mon hôte, voilà ce que Docker sait faire ! Et il le fait de manière beaucoup plus légère qu'une VM : un conteneur démarre en une fraction de seconde, une image pèse quelques dizaines de Mo, et on peut en faire tourner des dizaines sur un simple poste de développement.

*Schéma : conteneurs vs machines virtuelles. Une version à jour est disponible sur la documentation Docker.

💡 Ok je comprends mieux. Dans une machine virtuelle, tu alloues « physiquement » de la RAM et du stockage, par exemple 2 Go de RAM et 20 Go de disque. Alors qu'avec Docker, tout est partagé avec le système hôte. C'est pour ça que c'est plus rapide, je me trompe ?

C'est exactement ça ! Si tu as déjà une petite expérience avec les machines virtuelles (VirtualBox ou Vagrant), tu verras que Docker est beaucoup, beaucoup plus rapide à démarrer et plus économe en ressources.

Il y a toutefois une contrepartie : comme le noyau est partagé, l'isolation est moins forte que celle d'une VM. Une faille dans le noyau peut potentiellement concerner tous les conteneurs de la machine. C'est pourquoi on évite de lancer des conteneurs en root sans nécessité, et que l'on utilise des images de confiance.

Et voici un point qui devrait te convaincre que Docker n'est pas une VM : un conteneur utilise le noyau de son hôte. Un conteneur Linux a donc besoin d'un noyau Linux pour tourner. Convaincu ?

Docker sur Windows et macOS : comment ça marche ?

Nous avons évoqué plus haut l'utilisation de Docker sur Windows ou macOS. Peut-être l'utilisez-vous déjà ainsi. Pourtant, nous venons de voir qu'un conteneur Linux a besoin d'un noyau Linux !

Pour ne pas exclure les développeurs travaillant sur une autre plateforme, Docker Desktop fait tourner, de manière transparente, une machine virtuelle Linux très légère :

• sur Windows, via WSL 2 (le sous-système Linux de Windows) ;
• sur macOS, via le framework de virtualisation d'Apple.

Une seule VM suffit pour exécuter autant de conteneurs que vous le souhaitez, et vous n'avez pas à vous en occuper : vous tapez vos commandes docker dans votre terminal comme sur Linux.

De cette manière, tous les développeurs, quelle que soit leur plateforme, peuvent travailler sur une même application avec un environnement identique.

Ok, si je résume : pour faire tourner des conteneurs Linux sur Mac ou Windows, il faut une VM qui les héberge. C'est pas un peu le serpent qui se mord la queue ?

Un peu, oui ! Mais cette VM est conçue pour le poste de développement. En production, on fait tourner Docker directement sur un serveur Linux, sans VM intermédiaire. On profite alors pleinement de la légèreté des conteneurs.

Quelques points pratiques :

• Licence : Docker Desktop est gratuit pour un usage personnel, l'éducation et les petites structures, mais payant pour les entreprises de plus de 250 salariés ou de plus de 10 M$ de chiffre d'affaires. Il existe des alternatives libres : Podman Desktop, Rancher Desktop, Colima (macOS), ou OrbStack (macOS, payant en entreprise).
• Installation sur Linux : on installe directement Docker Engine en suivant la documentation officielle, qui couvre les versions maintenues de Debian, Ubuntu, Fedora, RHEL, etc.

Et les conteneurs Windows ?

Ils existent aussi ! Depuis Windows Server 2016, Docker sait faire tourner des conteneurs Windows natifs, qui partagent le noyau Windows de l'hôte. Ils ne sont pas compatibles avec les conteneurs Linux, mais répondent au même besoin pour des applications .NET Framework, par exemple. Dans le monde du web, l'immense majorité des images reste toutefois basée sur Linux.

Docker, cas d'utilisation

Prenons un cas d'utilisation simple et concret.

Une entreprise lyonnaise que j'appellerai à tout hasard Wanadev souhaite développer un projet Symfony, comme elle sait le faire. L'équipe est composée de deux personnes :

• Manu est un vieux de la vieille. Lui, sa Debian stable, c'est parfait. En plus, il a la même version que les serveurs de production.
• Baptiste est un vrai hippie. Il utilise la dernière distribution exotique. Lui, PHP, c'est la toute dernière version ou rien. Résultat : il peut écrire du code qui ne fonctionne pas avec une version plus ancienne, comme celle de Manu… ou celle de la prod.

Pendant longtemps, on s'est dit : « faisons des tests unitaires ». Oui, cela répond à une bonne partie du problème (à condition d'avoir de bons tests, complets), mais pas au fait que chacun travaille sur un environnement différent.

En effet, c'est problématique que deux développeurs ne travaillent pas sur le même environnement… Du coup, grâce à Docker, on peut faire en sorte que Manu et Baptiste travaillent avec exactement les mêmes versions, sans craindre de problèmes de compatibilité ?

Exactement ! Le plus simple est d'écrire un Dockerfile : un fichier texte qui décrit, étape par étape, comment construire l'image de l'application (image de base, version de PHP, extensions, configuration…). Manu et Baptiste construisent la même image à partir du même Dockerfile, et obtiennent donc le même environnement.

En étant malin, ce Dockerfile sera calqué sur la production. Ainsi, Manu et Baptiste travaillent non seulement sur un environnement identique entre eux, mais aussi identique à celui de la production !

Docker, déployer vos applications facilement

Dans l'exemple précédent, j'ai mis en avant l'utilisation de Docker pour définir un environnement de développement commun. Je pense que tous les utilisateurs de Docker devraient commencer par là avant de voir plus grand.

Plus haut, je vous parlais d'une version particulière de PHP. Vous ne risquez évidemment pas d'oublier d'installer PHP sur votre serveur de production, mais peut-être que la configuration de PHP-FPM y sera légèrement différente. Peut-être avez-vous besoin d'une librairie supplémentaire comme Imagick et de son extension PHP. Autant de détails que l'on peut oublier en montant un serveur.

Pour limiter ces erreurs, ne serait-il pas plus simple de déployer directement l'image qui fait tourner votre application ? Plutôt que de pull un code source et d'exécuter des scripts de déploiement, vous déployez un ensemble cohérent et packagé, testé à l'identique en développement et en CI.

Dans le monde du web, une « application » Symfony ne serait pas grand-chose sans un serveur web comme Nginx ou Apache, un moteur d'exécution comme PHP-FPM, et une base de données. Avec Docker, chacun de ces composants tourne dans son propre conteneur, et on décrit l'ensemble dans un seul fichier grâce à Docker Compose :

# compose.yaml
services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
  php:
    build: .
  db:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Un simple docker compose up démarre toute la stack.

Si je peux lancer plusieurs conteneurs sur ma machine, ça veut dire que je peux multiplier les configurations comme je le souhaite ?

C'est tout à fait ça ! Vous pouvez construire des environnements autonomes et isolés les uns des autres. Le vieux projet en PHP 7.4 peut côtoyer, sur le même serveur, le dernier projet Symfony en PHP 8.4. Cool, non ?

Conclusion

Grâce à Docker, vous multipliez les environnements sur votre machine en partageant le noyau de l'hôte : c'est beaucoup plus léger que des machines virtuelles. Chaque image est décrite par son Dockerfile, et une application composée de plusieurs services se décrit avec Docker Compose.

Cet article avait pour but de vous présenter Docker dans ses grandes lignes et de vous aider à cerner les problèmes qu'il résout pour les développeurs. Dans la partie 2, nous passons à la pratique : récupérer une image, écrire un Dockerfile et lancer nos premiers conteneurs.