Docker a transformé la façon dont les développeurs construisent et déploient des applications depuis son lancement en mars 2013. Au cœur de cet outil se trouve la commande, cette instruction précise que l’on donne au moteur Docker pour créer un conteneur, le lancer, l’inspecter ou le supprimer. Maîtriser la commande Docker, c’est gagner en productivité, en lisibilité et en fiabilité sur ses pipelines de déploiement. Pourtant, beaucoup d’équipes se contentent des usages basiques sans exploiter la richesse des options disponibles. Cet article passe en revue quinze exemples concrets, du plus simple au plus avancé, pour tirer le meilleur parti de Docker au quotidien.
Docker, une plateforme bâtie sur la logique des conteneurs
Docker, Inc. a conçu sa plateforme autour d’un principe simple : isoler chaque application dans un conteneur léger qui embarque toutes ses dépendances. Contrairement à une machine virtuelle, un conteneur partage le noyau du système hôte. Résultat : des démarrages en quelques secondes et une consommation mémoire drastiquement réduite.
La communauté open source a largement contribué à l’écosystème Docker, avec des milliers d’images disponibles sur Docker Hub. On y trouve des images officielles pour Node.js, Python, Nginx, PostgreSQL ou Redis, prêtes à l’emploi en quelques secondes. Cette richesse rend Docker particulièrement adapté aux architectures microservices, où chaque service tourne dans son propre conteneur.
Le cycle de vie d’un conteneur repose sur quelques concepts : l’image (le modèle immuable), le conteneur (l’instance en cours d’exécution) et le registre (le dépôt d’images). Comprendre cette distinction est la première étape avant d’écrire la moindre instruction.
Docker s’intègre naturellement dans les workflows CI/CD modernes. Jenkins, GitLab CI, GitHub Actions : tous supportent Docker nativement. Les équipes peuvent ainsi garantir que le code testé en local s’exécutera de manière identique en production, éliminant le fameux problème « ça marche sur ma machine ».
Anatomie et syntaxe de la commande Docker
Une commande Docker suit toujours la même structure : docker [OPTIONS] COMMANDE [ARG...]. Le mot docker appelle le client, qui communique avec le daemon Docker via une API REST. Chaque sous-commande cible un objet précis : conteneur, image, volume, réseau ou système.
Les sous-commandes les plus courantes se regroupent en familles. docker run crée et démarre un conteneur. docker build construit une image à partir d’un Dockerfile. docker pull et docker push gèrent les échanges avec un registre. docker ps, docker inspect et docker logs servent à l’observation.
Chaque sous-commande accepte des flags qui modifient son comportement. Le flag -d lance un conteneur en arrière-plan (detached mode). Le flag -p mappe un port de l’hôte vers le conteneur. Le flag -v monte un volume. Ces options se combinent librement, ce qui donne une flexibilité considérable.
La documentation officielle sur docs.docker.com reste la référence absolue. Docker évolue régulièrement : certaines options sont dépréciées, d’autres apparaissent. Vérifier la version installée avec docker version avant d’appliquer un exemple trouvé en ligne évite bien des surprises.
15 exemples pratiques pour maîtriser la commande
Voici quinze exemples classés par thématique, du démarrage rapide à la gestion avancée des ressources. Chaque exemple est directement réutilisable dans un terminal.
- Lancer un conteneur interactif :
docker run -it ubuntu bashouvre un shell Bash dans un conteneur Ubuntu. Le flag-igarde l’entrée standard ouverte,-talloue un pseudo-terminal. - Nommer un conteneur :
docker run --name mon-nginx nginxattribue un nom lisible plutôt qu’un identifiant aléatoire, facilitant les opérations ultérieures. - Mapper les ports :
docker run -p 8080:80 nginxexpose le port 80 du conteneur sur le port 8080 de l’hôte. Utile pour tester un serveur web localement. - Monter un volume local :
docker run -v $(pwd)/data:/app/data mon-imagesynchronise un répertoire local avec le conteneur, idéal pour le développement en temps réel. - Passer des variables d’environnement :
docker run -e DATABASE_URL=postgres://... mon-imageinjecte des configurations sans les coder en dur dans l’image. - Limiter la mémoire :
docker run --memory="512m" mon-imageempêche un conteneur de consommer toute la RAM disponible sur l’hôte. - Limiter le CPU :
docker run --cpus="1.5" mon-imagerestreint l’usage processeur à 1,5 cœur, pratique sur des machines partagées. - Construire une image avec un tag précis :
docker build -t mon-app:v1.2 .identifie clairement la version de l’image produite. - Construire sans cache :
docker build --no-cache -t mon-app .force la reconstruction complète, utile quand les dépendances ont changé. - Inspecter un conteneur :
docker inspect mon-nginxretourne un JSON détaillé sur la configuration réseau, les volumes montés et les variables d’environnement. - Afficher les logs en temps réel :
docker logs -f mon-nginxsuit les sorties du conteneur en continu, l’équivalent detail -fpour les logs. - Exécuter une commande dans un conteneur actif :
docker exec -it mon-nginx bashouvre un shell dans un conteneur déjà en cours d’exécution sans le redémarrer. - Copier des fichiers :
docker cp mon-nginx:/etc/nginx/nginx.conf ./nginx.confextrait un fichier du conteneur vers l’hôte pour inspection ou modification. - Nettoyer les ressources inutilisées :
docker system prune -fsupprime les conteneurs arrêtés, les images orphelines et les réseaux non utilisés en une seule opération. - Sauvegarder une image :
docker save -o mon-app.tar mon-app:v1.2exporte l’image dans un fichier archive transportable, sans dépendance à un registre distant.
Ces quinze exemples couvrent les besoins les plus fréquents. Ils se combinent entre eux : rien n’empêche de nommer un conteneur, de mapper ses ports et de limiter sa mémoire dans une seule ligne. La puissance de Docker réside précisément dans cette compositionnalité.
Bonnes pratiques pour des conteneurs robustes en production
Un conteneur qui fonctionne en local ne suffit pas. En production, la sécurité, la reproductibilité et la maintenabilité des images comptent autant que la fonctionnalité.
Commencer par des images de base minimales réduit la surface d’attaque et accélère les téléchargements. L’image alpine pèse moins de 10 Mo contre plusieurs centaines pour une image Ubuntu standard. Pour les applications Go ou Rust, les builds multi-étapes permettent même de produire des images sans aucun outil de compilation.
Ne jamais stocker de secrets dans une image. Les mots de passe, clés API et certificats doivent transiter par des variables d’environnement injectées au runtime, ou mieux, par un gestionnaire de secrets comme HashiCorp Vault ou les secrets natifs de Docker Swarm. Une image publiée sur Docker Hub est publique par défaut : tout secret embarqué devient accessible à quiconque la télécharge.
Taguer les images avec un numéro de version sémantique (v1.2.3) plutôt que latest garantit la traçabilité. Le tag latest est pratique pour le développement, mais il rend les déploiements imprévisibles en production car il pointe sur la dernière image construite, quelle qu’elle soit.
Ajouter un healthcheck dans le Dockerfile avec l’instruction HEALTHCHECK CMD curl -f http://localhost/ || exit 1 permet à Docker de surveiller l’état réel du service, pas seulement l’état du processus. Un orchestrateur comme Kubernetes peut ainsi redémarrer automatiquement un conteneur qui répond mais retourne des erreurs.
Aller plus loin avec Docker Compose et les registres privés
Docker Compose étend la logique des conteneurs individuels à des architectures multi-services. Un fichier docker-compose.yml décrit l’ensemble des services, réseaux et volumes d’une application. Une seule commande, docker compose up, lance tout l’environnement. C’est devenu le standard pour les environnements de développement local complexes.
Les registres privés permettent de stocker des images internes sans les exposer publiquement. AWS Elastic Container Registry, Google Artifact Registry et Azure Container Registry s’intègrent directement avec leurs services d’orchestration respectifs. Pour les équipes qui préfèrent l’auto-hébergement, Harbor offre un registre open source avec gestion des accès et analyse de vulnérabilités.
La commande docker login authentifie le client Docker auprès d’un registre, qu’il soit public ou privé. En environnement CI/CD, les identifiants sont injectés via des variables d’environnement sécurisées, jamais en clair dans les scripts de pipeline.
Les multi-platform builds sont devenus indispensables depuis la généralisation des puces ARM (Apple Silicon, serveurs Graviton d’AWS). La commande docker buildx build --platform linux/amd64,linux/arm64 -t mon-app . produit une image compatible avec les deux architectures en une seule opération. Plus besoin de maintenir deux Dockerfiles distincts.
La maîtrise de Docker ne s’arrête pas aux conteneurs individuels. C’est en combinant les commandes de base avec une architecture réfléchie, des registres bien organisés et une stratégie de versioning cohérente que les équipes passent d’un usage artisanal à un vrai pipeline industriel, fiable de la machine du développeur jusqu’au serveur de production.