🐳 Docker : les fondamentaux de la conteneurisation, pour de bon

📚 Introduction

« Ça marche sur ma machine. » Cette phrase, on l’a tous prononcée avant que le déploiement ne parte en fumée. Docker existe précisément pour la faire disparaître : au lieu de dépendre de ce qui est installé sur le serveur, on empaquette l’application et son environnement dans une unité portable qui tourne à l’identique partout.

Docker est aujourd’hui la brique de base de l’infrastructure moderne. Avant de parler d’orchestration ou de Kubernetes, il faut maîtriser ses fondamentaux : ce qu’est une image, ce qu’est un conteneur, comment persister des données et faire communiquer plusieurs services. C’est l’objet de cet article — le mental model d’abord, les commandes ensuite.

🔎 Qu’est-ce qu’un conteneur, exactement ?

Un conteneur n’est pas une machine virtuelle légère, même si la métaphore est tentante. Une VM émule un ordinateur complet, avec son propre noyau. Un conteneur, lui, partage le noyau de la machine hôte et n’isole que l’espace applicatif : ses processus, son système de fichiers, son réseau.

Concrètement, ça change tout. Là où une VM pèse plusieurs gigaoctets et démarre en dizaines de secondes, un conteneur pèse quelques mégaoctets et démarre quasi instantanément. On peut en lancer des dizaines sur une machine modeste. C’est cette légèreté qui a rendu possible l’infrastructure à base de microservices — et, plus tard, la nécessité de les orchestrer.

🧱 Images et conteneurs : le duo fondateur

C’est la distinction qui débloque tout le reste. Une image est un modèle immuable, en lecture seule, qui contient l’application et ses dépendances, construit en couches empilées. Un conteneur est une instance en cours d’exécution de cette image, avec une fine couche d’écriture par-dessus.

Le parallèle avec la programmation objet est direct : l’image est la classe, le conteneur est l’instance. Une seule image postgres:17 peut donner naissance à autant de conteneurs qu’on veut.

On construit une image à partir d’un Dockerfile, une recette étape par étape :

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Puis on la construit et on lance un conteneur :

docker build -t mon-app:1.0 .
docker run -d -p 8080:3000 --name web mon-app:1.0

Chaque instruction du Dockerfile crée une couche, mise en cache. C’est ce mécanisme de couches qu’on optimise pour accélérer les builds — un sujet que je détaille dans le multi-stage build pour Laravel.

💾 Persister les données avec les volumes

Voici l’erreur classique du débutant : écrire des données dans le conteneur, puis les voir disparaître quand on le recrée. C’est normal — la couche d’écriture d’un conteneur meurt avec lui.

Pour persister, on utilise un volume, un espace de stockage géré par Docker qui vit indépendamment du conteneur :

docker volume create pgdata
docker run -d \
  -v pgdata:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:17

On peut aussi monter un dossier de l’hôte directement (un « bind mount »), pratique en développement pour éditer le code sans rebuild :

docker run -v $(pwd):/app node:22-alpine

La règle d’or : le conteneur est jetable, le volume est précieux. Tout ce qui doit survivre à un redémarrage — base de données, fichiers uploadés — passe par un volume.

🌐 Réseaux et communication entre conteneurs

Par défaut, Docker isole les conteneurs, mais leur permet de communiquer via des réseaux virtuels. Quand plusieurs conteneurs partagent un même réseau, ils se joignent par leur nom :

docker network create app-net
docker run -d --network app-net --name db postgres:17
docker run -d --network app-net --name api mon-app:1.0

Depuis le conteneur api, la base est joignable à l’adresse db:5432. Pas besoin d’IP en dur : Docker fournit une résolution DNS interne. C’est cette mécanique qui rend les applications multi-conteneurs élégantes — et qui préfigure la découverte de services de Kubernetes.

🧰 Docker Compose : orchestrer sans se compliquer

Lancer trois conteneurs à la main avec les bons flags, c’est vite pénible. Docker Compose décrit toute l’application dans un fichier compose.yaml :

services:
  api:
    build: .
    ports:
      - '8080:3000'
    depends_on:
      - db
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
 
volumes:
  pgdata:

Et on démarre tout d’une commande :

docker compose up -d

Compose est aujourd’hui intégré à Docker sous la forme docker compose (avec un espace) — plus besoin d’installer un binaire séparé. Pour un seul serveur, Compose couvre l’écrasante majorité des besoins : c’est souvent tout ce dont on a besoin avant de basculer vers Kubernetes.

⚠️ Quelques précautions

• N’écrivez jamais de secrets en dur dans une image. Une image est distribuable ; un mot de passe committé dedans est un mot de passe fuité. Passez par des variables d’environnement ou un gestionnaire de secrets.
• Épinglez vos tags. postgres:latest change sans prévenir ; postgres:17 reste prévisible. Le latest en production est une source de surprises.
• Un processus par conteneur. Ne transformez pas un conteneur en mini-serveur avec dix services dedans. Un conteneur = une responsabilité.
• Nettoyez régulièrement. Images et volumes orphelins s’accumulent. docker system prune fait le ménage — mais vérifiez ce que vous supprimez.

🎉 Conclusion

Docker tient sur quatre idées : les images (le modèle), les conteneurs (l’instance), les volumes (la persistance) et les réseaux (la communication). Une fois ce socle en tête, Docker Compose suffit à faire tourner une application complète sur un seul serveur, proprement et de façon reproductible.

C’est aussi la fondation indispensable pour la suite. Un conteneur Docker est exactement ce que Kubernetes va orchestrer à grande échelle, et un runtime comme FrankenPHP se distribue justement sous forme d’image Docker. Maîtrisez Docker d’abord : tout le reste s’y appuie.

🔗 Liens utiles

• Docker — documentation officielle
• Référence du Dockerfile
• Docker Compose — documentation
• Docker Hub — registre d’images officielles