Docker s’est imposé comme le pivot des environnements de développement et de production agiles. En 2026, il est quasi impossible de parler d’isolation applicative ou de pipelines CI/CD sans croiser cette CLI qui fait le lien entre rapidité, automatisation et sobriété technique. Pourtant, l’écart reste immense entre lancer un conteneur avec docker run et piloter un écosystème d’applications interconnectées grâce à Compose.
À chaque étape, la qualité de la commande tapée – options comprises – fait la différence entre un setup jetable et un vrai hub réutilisable, robuste et mesurable. Les PME l’ont bien compris : revoir une commande mal rédigée coûte plus cher que concevoir une architecture propre dès le départ. Ce guide plonge dans l’essentiel des commandes Docker, du b.a.-ba jusqu’à l’orchestration multi-conteneurs, en décryptant options, erreurs et bonnes pratiques concrètes pour éviter de scier la branche que l’on vient tout juste de poser.
En bref :
- docker run permet de créer puis démarrer un nouveau conteneur à partir d’une image. C’est l’instruction la plus fréquente pour les premiers essais ou les tests rapides.
- Pour relancer un conteneur déjà créé et arrêté, la commande devient docker start, à ne pas confondre avec run.
- Les options comme -d, -it, -p, –name, -v sont incontournables pour contrôler le mode d’exécution, l’accessibilité réseau, la persistance des données ou l’interactivité des sessions.
- La gestion multi-conteneurs s’effectue via Docker Compose (docker compose up/down), qui lit votre docker-compose.yml et verrouille l’orchestration.
- Les erreurs récurrentes valent le coup d’œil : conflit de port, image absente, permissions insuffisantes, conteneur qui s’arrête sans raison apparente ou conflit de nom.
- Au fil du guide, des cas concrets, une checklist minute et une FAQ pour éliminer les “prises de tête” du quotidien.
docker run : lanceur universel du conteneur, mais pas sans config
Lancer son premier conteneur Docker avec la CLI, c’est croquer dans la partie visible de l’iceberg. La commande docker run incarne la porte d’entrée vers un univers où chaque option influe sur la maintenabilité, la sécurité et la productivité.
Sortez du “Hello World” pour passer à l’étape supérieure : il ne s’agit plus d’exécuter un simple container, mais de le piloter selon vos besoins réels.
La syntaxe brute :
docker run [OPTIONS] IMAGE [COMMANDE] [ARGUMENTS]
Exemple direct :
docker run ubuntu
Cette commande lance Ubuntu… et s’arrête presque aussitôt, car il n’y a pas d’action précisée. Pour ceux qui s’attendaient à explorer le shell, petit rappel : il manque l’option -it ! Ajoutez bash en fin de commande et une option interactive, c’est la clé pour conserver la main sur l’application.
Pour mémoriser, voici une table des options incontournables à intégrer dans chaque commande sérieuse :
| Option | Effet | Exemple |
|---|---|---|
| -d | Mode détaché (arrière-plan) | docker run -d nginx |
| -it | Session interactive avec terminal | docker run -it ubuntu bash |
| -p | Redirection port hôte/conteneur | docker run -p 8080:80 nginx |
| –name | Attribuer un nom unique au conteneur | docker run –name demo nginx |
| -v | Monter un volume local | docker run -v /data:/app/data nginx |
| -e | Définir une variable d’environnement | docker run -e MODE=prod nginx |
| –rm | Suppression automatique après exécution | docker run –rm ubuntu echo « test » |
Ce niveau de granularité est important. Un site événementiel déployé à la volée ? Le mode détaché, le mapping du port et les variables ENV suffisent à rendre l’exercice invisible pour l’utilisateur, mais lisible et modifiable à tout moment pour la technique.
Les mauvaises surprises ? Elles viennent d’une option oubliée : pas de nom personnalisé et vous perdez le suivi ; pas de volume, et vos données s’envolent à l’arrêt du conteneur. Sur des projets impliquant la gestion de données clients ou des maintenances croisées, il n’est pas rare de voir ces oublis ruiner des heures de configuration.
L’exemple d’une PME champenoise qui lançait ses workflows de tests automatisés sans -v l’illustre : le jour du bug, impossible de récupérer la moindre trace. Conseil : systématisez une checklist des options selon l’usage visé avant tout lancement “musclé”.
docker start et docker exec : courir ou réparer, choisissez votre tempo
Les confusions entre docker run et docker start ne sont pas rares. Pour un conteneur déjà créé (et stoppé), relancer avec run crée un nouvel objet. Résultat : multiplication des conteneurs inutiles, traces résiduelles et stockage saturé. docker start s’adresse à ceux qui veulent accélérer le tempo, remettre en route un service existant, sans pile de clones dans la médiathèque Docker.
Exemple concret : après tests, le service Nginx personnalisé (“monserveur”) doit redémarrer suite à une coupure de la VM. Pas la peine de passer par la case création : la commande docker start monserveur suffit. Elle ne touche ni aux volumes ni au réseau, tout repart là où l’on s’était arrêté, presque comme une pause/résumé (fans des séries Netflix, cette mécanique vous parlera !).
Tour d’horizon rapide avec ce tableau comparatif :
| Commande | Usage | Nouveau conteneur ? |
|---|---|---|
| docker run | Créer et lancer une instance fraîche | Oui |
| docker start | Réactiver un conteneur stoppé | Non |
| docker restart | Arrêt puis redémarrage immédiat | Non |
Côté interaction en “live”, la commande docker exec sert de téléporteur interne. Elle permet de parachuter une commande ou un shell directement dans le conteneur. Pratique lorsque l’application tourne mais qu’il faut intervenir (logs à consulter, troubleshooting SQL, test de configuration). Rien de plus simple : docker exec -it monserveur bash.
Pour ceux qui veulent aller plus loin sur l’optimisation des architectures locales et la manipulation de serveurs, le mini-guide LAMPP pour héberger un site en local complètera utilement cet arsenal CLI.
Pensée UX, la différence entre run, start et exec se ressent surtout quand les environnements prolifèrent : garder un carnet de bord, ou mieux, coller une étiquette claire (–name) à chaque conteneur permet de faire le ménage sans errer dans des IDs illisibles. Petit aparté : dans une équipe, standardiser la nomenclature des ressources Docker évite bien des quiproquos lors des passages de relai.
Gérer l’orchestration multi-conteneurs avec Docker Compose : stack automatisée, stress minimisé
Dès que le projet prend de l’épaisseur – base PostgreSQL par-ci, API Node.js par-là, puis reverse proxy Nginx pour chapeauter le tout – la simplicité de docker run atteint rapidement ses limites. Docker Compose s’impose : il centralise la description des services (docker-compose.yml), automatise toute la pile applicative, et offre un contrôle millimétré de l’enchaînement, des liaisons réseau, et de la persistance.
La commande pivot : docker compose up -d. Un coup de roue et la stack entière démarre, synchronisée, chaque service dans son espace réseau, ses volumes partagés, ses variables d’environnement héritées du manifeste. En phase de développement, passer sur un docker compose down nettoie intégralement la scène sans trauma sur les images ou les bases de code.
Détail à ne pas sous-estimer : Compose prend en charge la création des réseaux internes, gère les dépendances (“depends_on”), et automatise le provisionnement des volumes pour sauvegarder vos données.
Une start-up rémoise, spécialisée dans l’agrégation de flux météo, a migré tous ses tests unitaires grâce à Compose : un docker-compose.yml, trois services (backend, BDD, job cron), et des tests reproductibles, même sur laptop vieillissant. Retour sur investissement quasi immédiat au regard des bugs liés au “ça marche sur ma machine”.
- Déploiement synchronisé et documenté.
- Rollback facilité (docker compose down & up).
- Stack portable, duplicable, versionnable (git comme référentiel).
Pour structurer visuellement vos architectures et échanges entre services, un détour par les ressources de schématisation Draw.io vous donnera de précieux modèles à adapter à votre pipeline Docker Compose.
Côté ergonomie : Compose gomme la multiplicité des instructions individuelles. Il déporte le cerveau – et donc les bugs – dans le fichier de configuration… et pas dans la mémoire des techniciens. À noter : dans le B2B, imposer ce standard dès le POC allège les chantiers d’intégration à moyen terme. Chaque développeur, designer, ou responsable produit lit la stack, la comprend, voire l’améliore, sans avoir besoin de demander “Par quelle commande a-t-on lancé ce service ?”. Preuve que, même dans la technique, le récit collectif existe.
Dépannage sur la ligne de commande : erreurs courantes et checklist minute
L’usage quotidien de Docker ne pardonne pas l’inattention. Chaque option omise, chaque nom d’image mal orthographié, chaque port oublié dans le firewall peut faire perdre plus de temps qu’une réunion mal préparée. La CLI Docker renvoie des erreurs parfois laconiques. Dominer ces messages (ou savoir les éviter) fait toute la différence sur un ticket de support ou pendant une démonstration client. Rappel des plus courantes :
- Port déjà utilisé (bind error) : un autre service occupe le port ciblé (8080:80). Deux solutions : modifier le port hôte ou tuer le process récalcitrant.
- Image introuvable : Docker n’a pas trouvé l’image localement et, faute de connexion ou d’orthographe, échoue à la télécharger.
- Permission denied sur le socket Docker : votre session n’est pas dans le groupe docker. Ajouter votre utilisateur avec usermod -aG docker $USER et reconnectez-vous.
- Conteneur qui s’arrête immédiatement : souvent, le process principal s’est terminé trop tôt. Correction : passer par le mode interactif (-it) ou fixer correctement ENTRYPOINT dans le Dockerfile.
- Conflit de nom : erreur fréquente lors des tests en chaîne. Un ancien conteneur porte encore le nom ciblé. Solution rapide : docker rm [nom] avant relance, ou choisir un nouvel identifiant.
Une PME industrielle du Grand Est a connu la mésaventure : debug interrompu par un port déjà pris, fichier Compose mal synchronisé, session perdue faute de groupe utilisateur configuré. Dix minutes de prise de tête, puis la résolution, une fois la checklist systématisée :
- Lancer docker ps -a pour vérifier les états.
- Réparer les ports (netstat, ps aux | grep).
- Vérifier l’image (docker images).
- Nettoyer les causants (docker rm/stop).
- Toujours relire la configuration Compose en amont.
Pas besoin d’attendre la crise : afficher cette liste près de l’écran ou l’inclure dans le README interne réduit déjà les interruptions.
Résumé opérationnel : commandes essentielles Docker à garder sous la main
Le bon réflexe, ce n’est pas de tout retenir par cœur, mais de savoir où trouver l’information et comment l’adapter. À force d’expérience, certaines commandes deviennent réflexes. Voici une synthèse fonctionnelle :
| Objectif | Commande |
|---|---|
| Lancer un conteneur de base | docker run [image] |
| Lancer en détaché | docker run -d [image] |
| Mode interactif | docker run -it [image] bash |
| Port exposé | docker run -p 8080:80 [image] |
| Nom personnalisé | docker run –name [nom] [image] |
| Relancer un conteneur stoppé | docker start [nom_ou_id] |
| Orchestration multi-services | docker compose up -d |
Un mini “aide-mémoire” imprimé à côté du terminal vaut parfois une documentation officielle. D’ailleurs, pour comprendre comment intégrer Docker dans un cursus digital, la page formations digital et outils avancés propose quelques retours d’expérience précieux sur l’apprentissage opérationnel côté PME et équipes agiles.
Si une chose devait être retenue, c’est bien l’importance de ne pas surcharger systèmes et équipes de conteneurs “fantômes” ou de stack Compose bancale. Les gains sont visibles dans les métriques et la sérénité de travail : moins de manipulations manuelles, plus de lisibilité, moins de perte de contexte.
Quelle est la différence exacte entre docker run et docker start ?
docker run crée et démarre une nouvelle instance d’un conteneur à partir d’une image, alors que docker start ne fait que relancer un conteneur qui existe déjà mais est à l’arrêt.
Comment faire en sorte qu’un conteneur redémarre après un reboot système ?
Ajoutez l’option –restart unless-stopped à la commande docker run. Le conteneur se relancera automatiquement sauf s’il a été arrêté manuellement.
Pourquoi mon conteneur Docker s’arrête-t-il tout de suite après le lancement ?
Si le processus principal se termine (exemple : echo, script fini trop vite), le conteneur s’arrête aussitôt. Pour garder un shell, utilisez l’option -it ou définissez un ENTRYPOINT adéquat dans votre Dockerfile.
Comment vérifier facilement que mon conteneur fonctionne correctement ?
Utilisez docker ps pour voir le statut des conteneurs actifs. Si besoin, docker logs [nom] affiche les journaux et docker exec -it [nom] bash permet d’aller voir à l’intérieur.
Composer ou pas Compose, quand faut-il passer à l’orchestration multi-conteneurs ?
Dès lors qu’un projet nécessite au moins deux services qui communiquent (exemple : base + API), Compose devient incontournable. Il simplifie le lancement, la mise à jour et le suivi de vos stacks, et fluidifie le passage en environnement de production comme de test.
