Docker : définition, Dockerfile et bonnes pratiques

Docker est à la fois un logiciel et une entreprise. Le logiciel permet de construire des images, de les partager et de lancer des conteneurs à partir d'elles ; l'entreprise, Docker Inc., le développe et commercialise des services autour.

Son histoire commence chez dotCloud, une start-up de plateforme d'hébergement (PaaS) fondée par Solomon Hykes. Pour ses propres besoins, l'équipe avait développé un outil interne de gestion de conteneurs Linux. Solomon Hykes le présente publiquement à la PyCon de mars 2013 et le publie en open source dans la foulée. Le succès est tel que la société se renomme Docker Inc. dès la fin de la même année. Docker s'appuyait au départ sur LXC, puis sur sa propre bibliothèque écrite en Go. Docker Inc. a ensuite donné runc à l'Open Container Initiative et containerd à la CNCF : une partie du cœur de Docker est ainsi devenue le socle commun de tout l'écosystème.

Docker n'a pas inventé le conteneur, dont les briques existaient dans le noyau Linux. Il a apporté ce qui manquait pour une adoption massive : un format d'image simple, une CLI accessible, un fichier de description lisible et un registre public pour partager les images. Notre article Docker, à quoi ça sert ? revient sur ces usages.

À retenir : le conteneur est le concept, Docker est l'outil qui l'a rendu populaire. Les images qu'il produit respectent les standards OCI et s'exécutent avec d'autres outils.

Docker suit une architecture client-serveur. Quand vous tapez une commande, plusieurs composants interviennent.

• La CLI (docker) est le client. Elle traduit chaque commande en appel à l'API REST du démon, en local par un socket Unix ou à distance.
• Docker Engine (dockerd) est le démon. Il gère les images, les réseaux, les volumes et orchestre la construction des images avec BuildKit.
• containerd prend le relais pour le cycle de vie des conteneurs et le stockage des images.
• runc crée enfin le processus isolé, avec ses namespaces et ses cgroups.

Les couches d'image

Une image n'est pas un bloc monolithique. Chaque instruction du Dockerfile qui modifie le système de fichiers (RUN, COPY, ADD) produit une couche en lecture seule, identifiée par son empreinte. Les couches sont superposées par le pilote de stockage overlay2, et partagées entre images : dix images basées sur python:3.12-slim ne stockent cette base qu'une fois.

Ce découpage alimente le cache de build. Si une instruction et ses fichiers d'entrée n'ont pas changé, Docker réutilise la couche existante. Dès qu'une couche change, toutes les suivantes sont reconstruites : l'ordre des instructions a donc un impact direct sur la vitesse des builds.

Docker Hub et les registres

Docker Hub est le registre public de Docker Inc. Il héberge les images officielles (python, node, postgres, nginx…), maintenues et mises à jour régulièrement, ainsi que les images publiées par les éditeurs et la communauté. En entreprise, on utilise souvent un registre privé, Cloud (Amazon ECR, Google Artifact Registry, Azure Container Registry) ou auto-hébergé comme Harbor.

Cette image empaquette une API Python servie par Uvicorn. Le build se fait en deux étapes : la première installe les outils de compilation et les dépendances dans un environnement virtuel, la seconde ne récupère que cet environnement et le code. Les compilateurs ne finissent pas dans l'image livrée.

# syntax=docker/dockerfile:1

# Étape 1 : installation des dépendances
FROM python:3.12-slim AS builder
RUN apt-get update \
    && apt-get install -y --no-install-recommends build-essential \
    && rm -rf /var/lib/apt/lists/*
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH" \
    PIP_NO_CACHE_DIR=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1
COPY requirements.txt .
RUN pip install -r requirements.txt

# Étape 2 : image d'exécution minimale
FROM python:3.12-slim
ENV PATH="/opt/venv/bin:$PATH" \
    PYTHONUNBUFFERED=1
RUN useradd --create-home --uid 1000 app
WORKDIR /app
COPY --from=builder /opt/venv /opt/venv
COPY --chown=app:app src/ ./src/
USER app
EXPOSE 8000
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

Le fichier requirements.txt est copié avant le code : tant que les dépendances ne changent pas, la couche pip install reste en cache, même si le code évolue à chaque commit. Les commandes du quotidien :

# Construire l'image et la taguer
docker build -t mon-api:1.0 .

# Lancer un conteneur en arrière-plan, port 8000 publié sur l'hôte
docker run -d --name mon-api -p 8000:8000 --env-file .env mon-api:1.0

# Observer et diagnostiquer
docker ps
docker logs -f mon-api
docker exec -it mon-api sh

# Publier dans un registre privé
docker tag mon-api:1.0 registry.example.com/equipe/mon-api:1.0
docker push registry.example.com/equipe/mon-api:1.0

# Arrêter et supprimer le conteneur (l'image est conservée)
docker stop mon-api && docker rm mon-api

Dès que l'application a besoin d'une base de données ou d'un cache, enchaîner les docker run devient fastidieux : c'est le rôle de Docker Compose.

Quelques règles font la différence entre une image de 1,5 Go pleine de vulnérabilités et une image de 150 Mo prête pour la production.

1. Choisir une base minimale et officielle : variantes slim, Alpine ou distroless, et une version précise plutôt que latest. Pour une reproductibilité totale, épinglez l'image par son digest.
2. Ordonner les instructions pour le cache : ce qui change rarement (dépendances système, fichier de dépendances) en haut, le code en bas.
3. Utiliser le multi-stage pour séparer outils de build et image d'exécution.
4. Ajouter un .dockerignore pour exclure .git, les environnements virtuels, les données et les fichiers de secrets du contexte de build.
5. Ne pas exécuter en root : créez un utilisateur dédié et basculez dessus avec USER.
6. Ne jamais intégrer de secret dans l'image : utilisez les secrets de build de BuildKit (RUN --mount=type=secret) et injectez les secrets d'exécution par variables d'environnement ou par l'orchestrateur.
7. Un processus principal par conteneur, écrit en forme exec (CMD ["..."]) pour recevoir correctement les signaux d'arrêt.
8. Scanner les images avec Docker Scout ou Trivy, et automatiser build, scan et publication dans un pipeline CI/CD.

Podman, développé par Red Hat, est l'alternative la plus courante à Docker. Les deux produisent et exécutent des images OCI et partagent l'essentiel de la syntaxe de la CLI.

Dans les deux cas, l'image produite est la même : le choix porte sur le poste de travail et la politique de sécurité, pas sur la production, où Kubernetes prend le relais.