Docker s’est imposé comme l’outil standard pour packager et faire tourner des applications de façon reproductible. Voici l’essentiel pour comprendre à quoi il sert.
Le problème que Docker résout
“Ça marche sur ma machine” est le résumé du problème : une appli qui tourne bien en local peut planter en prod à cause d’une version de dépendance différente, d’une variable d’environnement manquante, d’un OS différent… Docker isole l’application avec tout ce dont elle a besoin (code, runtime, dépendances, configuration) dans un même paquet portable : le conteneur.
Image vs conteneur
- Une image est un modèle en lecture seule : le code, les dépendances, la configuration figés à un instant donné.
- Un conteneur est une instance en cours d’exécution de cette image, isolée du reste du système (mais partageant le noyau de l’OS hôte — contrairement à une VM, pas besoin de virtualiser tout un système d’exploitation, donc c’est beaucoup plus léger et rapide à démarrer).
Tu peux lancer plusieurs conteneurs à partir de la même image, chacun isolé des autres.
Le Dockerfile
Une image se construit à partir d’un Dockerfile, une recette texte :
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/mon-appli.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
FROM: l’image de base (ici, un JRE 17 déjà prêt)COPY: ajoute des fichiers dans l’imageEXPOSE: documente le port utilisé par l’applicationENTRYPOINT: la commande lancée au démarrage du conteneur
Commandes essentielles
| Commande | Description |
|---|---|
docker build -t mon-appli . |
Construit une image à partir du Dockerfile du dossier courant |
docker run -p 8080:8080 mon-appli |
Lance un conteneur à partir de l’image, en exposant le port 8080 |
docker ps |
Liste les conteneurs en cours d’exécution |
docker logs <id> |
Affiche les logs d’un conteneur |
docker exec -it <id> bash |
Ouvre un shell interactif dans un conteneur en cours d’exécution |
docker stop <id> |
Arrête un conteneur |
Et Kubernetes dans tout ça ?
Docker s’occupe de faire tourner un conteneur. Dès qu’on doit en gérer des dizaines, répartis sur plusieurs machines, avec de la haute disponibilité et du scaling automatique, on passe à un orchestrateur comme Kubernetes, qui pilote des conteneurs (Docker ou autres) à grande échelle. Ce sera peut-être le sujet d’un prochain article.
En résumé
Docker répond à un besoin simple : empaqueter une application avec tout son environnement pour qu’elle tourne pareil partout — en local, en CI, en prod. C’est devenu un prérequis quasi incontournable dans les pipelines CI/CD modernes.