Docker est partout dans les discussions techniques, mais quand il s’agit de passer à l’action, une question revient systématiquement au moment d’ouvrir le terminal : « concrètement, quelle commande pour lancer un conteneur Docker sans se perdre dans la documentation officielle ? ». Pour beaucoup de TPE, d’agences, de freelances et même d’associations qui commencent à goûter à la containerisation, la première barrière se situe là, au niveau de la ligne de commande.
Une fois cette étape franchie, tout devient plus fluide : environnements identiques entre les postes, déploiements propres sur un petit serveur distant, tests rapides sans casser l’existant.
Une bonne nouvelle se cache derrière cette apparente complexité : pour exécuter un conteneur, il suffit de maîtriser quelques instructions bien ciblées, en particulier docker run. Le reste n’est qu’une affaire d’options à ajouter pour mapper un port, nommer un conteneur, monter un volume ou passer une variable d’environnement.
Une poignée de paramètres pour transformer un simple test en vraie brique de production. Pour un commerce avec un petit site vitrine, une collectivité locale ou une PME industrielle du coin qui veut tester un nouvel outil sans tout réinstaller, cette maîtrise change clairement la donne.
En bref
- La commande clé pour lancer un conteneur Docker est docker run, qui crée et démarre un conteneur à partir d’une image Docker.
- Pour relancer un service déjà créé, on utilise plutôt docker start sur un conteneur arrêté.
- Une première commande complète typique ressemble à : docker run -d -p 8080:80 –name mon-site nginx.
- Les options indispensables à connaître dès le départ sont : -d (arrière-plan), -p (ports), -v (volumes), –name (nom du conteneur), -e (variables d’environnement).
- Pour les applications composées de plusieurs conteneurs, docker compose up devient plus adapté que docker run exécuté en série.
Quelle commande lancer pour créer et exécuter un conteneur Docker depuis zéro
Pour un premier pas concret, la réponse à la question « quelle commande pour lancer un conteneur Docker » tient en trois mots : docker run IMAGE. C’est la combinaison minimale pour créer et démarrer un conteneur à partir d’une image Docker.
Si l’image n’est pas présente en local, Docker ira la chercher tout seul sur Docker Hub, un peu comme un App Store des images prêtes à l’emploi.
Un développeur web freelance qui gère plusieurs sites vitrines pour des artisans du Périgord. Il veut tester rapidement un serveur Nginx sans toucher à son installation locale. Dans son terminal, la séquence ressemble à ceci : d’abord docker pull nginx pour récupérer l’image, puis docker run -d -p 8080:80 –name mon-nginx nginx pour lancer le conteneur et exposer le site sur son navigateur via http://localhost:8080.
Décomposer la commande docker run sans jargon inutile
Dans l’exemple précédent, chaque morceau de la commande a un rôle précis. docker run ordonne au moteur Docker de créer un nouveau conteneur et de l’exécuter. Le paramètre -d indique un lancement en arrière-plan pour éviter de bloquer le terminal. C’est très pratique pour des services comme Nginx, MariaDB ou Redis qui doivent tourner en continu.
Ensuite, l’option -p 8080:80 sert à publier un port interne du conteneur vers un port de la machine hôte. C’est un détail qui change tout pour un commerçant ou un restaurateur qui teste son futur site : sans cette redirection, impossible d’accéder à l’application depuis un navigateur. Enfin, –name mon-nginx fixe un nom explicite. Cela facilite grandement la gestion quotidienne avec des commandes comme docker stop mon-nginx ou docker logs mon-nginx.
Comparer rapidement docker run et docker start
Autre commande que l’on croise vite quand on débute : docker start. La nuance est simple mais importante. docker run crée un conteneur neuf à partir d’une image et le lance immédiatement. docker start, lui, se contente de rallumer un conteneur déjà existant, qui a été arrêté auparavant.
Sur un petit serveur mutualisé d’une PME, le scénario typique ressemble à ceci : un conteneur de base de données tourne pour une application interne, il est arrêté pour une maintenance avec docker stop mon-sql, puis relancé le lendemain avec docker start mon-sql. Inutile de recréer tout le service avec docker run, la configuration du conteneur reste en place.
| Commande | Rôle principal | Quand l’utiliser |
|---|---|---|
| docker run | Créer et lancer un nouveau conteneur | Premier démarrage d’un service, test rapide d’une image Docker |
| docker start | Relancer un conteneur arrêté | Redémarrage régulier d’un service déjà configuré |
| docker ps | Lister les conteneurs actifs | Vérifier ce qui tourne vraiment sur la machine |
Pour un entrepreneur qui ne vit pas dans Docker toute la journée, retenir ce trio run / start / ps suffit déjà à garder le contrôle. Le reste des options vient se greffer progressivement, au rythme des besoins réels, pas l’inverse.
Les options essentielles de docker run pour lancer un conteneur en conditions réelles
Une fois la commande de base assimilée, le vrai sujet devient : comment adapter docker run à une application métier concrète. Entre un simple test de serveur web statique et une base de données de production, les besoins ne sont pas les mêmes. Pourtant, on reste toujours autour du même noyau de paramètres.
Dans les accompagnements d’entreprises locales, un constat revient souvent. Les équipes techniques savent installer Docker, mais les projets se bloquent au moment de traduire la réalité métier en options : ports, volumes, variables, réseau. D’où l’intérêt de poser un socle commun d’options « réflexes » à injecter dans chaque commande.
Nommer, publier des ports et travailler en arrière-plan
Premier réflexe sain : donner un nom explicite au conteneur avec –name. Un camping qui gère deux sites web différents peut très bien avoir –name site-principal et –name site-piscine. Au moment du débogage, ce simple détail évite d’interrompre le mauvais service.
Ensuite viennent les ports. La syntaxe -p HOST:CONTAINER permet de choisir ce qui doit être exposé au monde extérieur. Exemple typique pour un serveur HTTP : -p 8080:80. Un office de tourisme pourrait exploiter ce mécanisme pour tester une nouvelle version de son site sur un port alternatif, avant de basculer réellement la production.
Côté mode d’exécution, -d reste la norme pour les services qui tournent en continu. Garder un conteneur interactif avec -it (mode terminal interactif) garde son intérêt pour parcourir les logs ou exécuter ponctuellement une commande de maintenance à l’intérieur du conteneur.
Volumes et variables d’environnement, la vraie vie des données
Quand une base de données ou un CMS commence à manipuler des informations clients, la question n’est plus juste de lancer un conteneur. Il faut le faire en préservant les données. docker run répond à ce besoin avec l’option -v pour monter un volume ou un répertoire de l’hôte dans le conteneur.
Une commande de type docker run -d -v mon-volume:/var/lib/mysql mysql:latest indique à Docker de stocker les fichiers de la base hors du conteneur, dans un volume persistant. Si le conteneur est supprimé puis recréé, les données restent disponibles. Pour une petite structure locale qui ne peut pas se permettre de perdre son historique de facturation, ce choix n’est pas négociable.
Autre élément critique : les variables d’environnement gérées par -e. Un exemple concret pour une base MySQL serait -e MYSQL_ROOT_PASSWORD=motdepassefort. Plus les configurations se multiplient, plus la gestion propre de ces variables devient importante, notamment pour éviter de les stocker en clair dans un dépôt Git partagé.
Un exemple complet, proche d’une situation de terrain
Pour visualiser tout cela, prenons le cas d’un cabinet médical qui veut tester un logiciel de prise de rendez-vous auto-hébergé. La commande docker run pourrait ressembler à quelque chose comme :
docker run -d –name rdv-medical -p 8081:80 -e DB_HOST=my-database -e APP_ENV=production my-image-rdv:latest
On y retrouve l’ensemble des briques vues plus haut. Le conteneur se lance en arrière-plan, porte un nom lisible, publie un port précis, et récupère ses paramètres sensibles via les variables d’environnement. De cette manière, le cabinet peut expérimenter l’outil sans changer son site principal et sans impliquer son prestataire d’hébergement trop tôt.
Pour les équipes mixtes (développeurs, intégrateurs, responsables com), un support vidéo expliquant la lecture d’un docker-compose.yml peut débloquer beaucoup de malentendus sur « ce qui tourne où ».
Bonnes pratiques pour lancer un conteneur Docker sans se tirer une balle dans le pied
La théorie donne une impression de contrôle, mais la pratique réserve toujours son lot de surprises. Entre les conteneurs qui se ferment immédiatement, les ports déjà utilisés ou les données qui disparaissent après une suppression malheureuse, lancer un conteneur Docker peut vite virer au casse-tête pour un non-spécialiste.
Heureusement, quelques réflexes simples suffisent à éviter les erreurs les plus douloureuses. Sur le terrain, on voit souvent les mêmes pièges se répéter. Autant les désamorcer dès maintenant, avant qu’un site de collectivité ou de restaurant ne se retrouve hors ligne un samedi soir.
Vérifier systématiquement ce que fait vraiment le conteneur
Un conteneur qui « plante » juste après un docker run ne s’arrête jamais par hasard. Dans ce cas, première étape : inspecter les logs avec docker logs nom-du-conteneur. Ils indiquent souvent une configuration manquante, un port déjà pris ou un fichier introuvable.
Autre commande qui sauve du temps : docker ps -a. Là où docker ps ne montre que les conteneurs actifs, la variante avec -a liste aussi ceux qui se sont arrêtés. Cela aide à repérer un service qui boucle sur un crash/restart silencieux. Un graphiste qui s’occupe d’un WordPress local pour un client gagnera ainsi un temps précieux avant même d’appeler un développeur à la rescousse.
Sécuriser les données avant de toucher aux conteneurs
Un conteneur reste, par définition, éphémère. Suppression du conteneur, suppression du système de fichiers interne. Ce fonctionnement convient très bien pour un service stateless, comme un proxy ou un frontend qui se reconstruit. Par contre, pour une base de données ou un CMS, ce serait du sabotage assumé.
C’est pour cela qu’avant de lancer ou relancer un conteneur, il vaut mieux s’assurer que les données importantes sont stockées dans des volumes Docker ou des bind mounts bien identifiés. Les commandes de gestion comme docker volume create, docker volume inspect ou docker volume prune deviennent alors des alliées pour garder un environnement propre sans prendre de risque inconsidéré.
Standardiser les commandes pour l’équipe
Dans une structure même modeste, la meilleure façon d’éviter les surprises consiste à documenter les commandes d’exécution des conteneurs. Un simple fichier texte partagé ou un dépôt Git avec quelques scripts bash peut faire l’affaire. L’idée est que chacun relance les mêmes services avec exactement la même commande, plutôt qu’avec une variante approximative.
Pour les projets un peu plus ambitieux, ce rôle est naturellement repris par Docker Compose. Au lieu d’envoyer des lignes de terminal par mail, on partage le fichier YAML et la consigne « docker compose up -d ». C’est plus clair, plus durable, et beaucoup plus simple à auditer quelques mois plus tard.
Aller plus loin que docker run : réseaux, registres et orchestration légère
Une fois à l’aise avec la commande basique pour lancer un conteneur Docker, la curiosité arrive vite. Comment faire communiquer deux services entre eux sans exposer toute la machine sur Internet ? Comment partager facilement une image créée en interne avec un prestataire externe ou un hébergeur ? Pourquoi certains parlent dès qu’ils le peuvent de Kubernetes, alors que le besoin se limite parfois à un simple cluster de deux serveurs ?
Ces questions montrent qu’un cap est franchi. On sort du test local pour approcher des usages proches de la production, même dans des structures qui ne se voient pas comme des « boîtes tech ».
Configurer des réseaux pour des applications multi-services
Par défaut, Docker place les nouveaux conteneurs sur un réseau bridge standard qui suffit pour des tests unitaires. Dès que des services commencent à échanger des données entre eux (web, base de données, cache, worker d’arrière-plan), créer un réseau dédié via docker network create mon-reseau permet de garder un minimum de maîtrise.
La commande docker run –network mon-reseau rattache ensuite chaque conteneur à ce réseau. Résultat concret pour un restaurant ou une petite chaîne de magasins équipée d’un intranet : les conteneurs peuvent se parler par leurs noms, sans exposer inutilement leurs ports à l’extérieur. La surface d’attaque diminue et la configuration réseau devient plus lisible.
Partager les images entre équipes sans tout réinstaller
Dès qu’une équipe commence à bâtir ses propres images, la question du partage se pose. Docker Hub reste le réflexe le plus courant, avec un simple docker push vers un dépôt privé ou public. C’est souvent suffisant pour distribuer une application à un intégrateur externe chargé de l’installation chez un hébergeur régional.
Un schéma typique ressemble à ceci : l’équipe conçoit un Dockerfile, construit une image avec docker build -t mon-registre/mon-app:latest ., puis publie avec docker push. Au bout de la chaîne, le prestataire ou le client final n’a plus qu’à exécuter un docker run bien documenté, sans se préoccuper de toutes les dépendances internes.
Pour certains projets locaux plus avancés, un registre privé sur le réseau interne de l’entreprise permet même de garder ces images en circuit fermé, tout en conservant la même logique de fonctionnement.
Pour des stacks plus complexes, mêlant WordPress, outils maison, services tiers et passerelles de paiement, un point de départ concret reste d’étudier une configuration existante comme celle présentée sur ce guide WordPress avec Docker Compose. Le principe reste identique, seul le nombre de services augmente.
Quelle est la commande la plus simple pour lancer un conteneur Docker ?
La commande minimale pour lancer un conteneur Docker est docker run IMAGE. Par exemple, docker run nginx crée et démarre un conteneur basé sur l’image Docker nginx. En pratique, on ajoute rapidement des options comme -d pour le lancer en arrière-plan et -p pour publier un port accessible depuis un navigateur.
Quelle différence entre docker run et docker start ?
docker run crée un nouveau conteneur à partir d’une image et le démarre immédiatement. docker start relance uniquement un conteneur qui existe déjà mais qui est arrêté. Pour un premier lancement, on utilise donc docker run, puis pour les redémarrages réguliers on passe à docker start afin de conserver la configuration du conteneur.
Comment lancer un conteneur Docker en arrière-plan ?
Pour exécuter un conteneur en arrière-plan, il suffit d’ajouter l’option -d à la commande. Exemple : docker run -d -p 8080:80 –name mon-nginx nginx. Le conteneur reste actif, et le terminal rend la main immédiatement, ce qui est pratique pour les services qui doivent tourner en continu.
Comment rendre mon application Docker accessible depuis un navigateur ?
Il faut exposer un port du conteneur sur un port de la machine hôte avec l’option -p de docker run. La syntaxe est -p PORT_HOTE:PORT_CONTENEUR. Pour un serveur web classique, une commande comme docker run -d -p 8080:80 nginx permet d’accéder au site sur http://localhost:8080 depuis le navigateur.
Quand vaut-il mieux utiliser docker compose up plutôt que docker run ?
docker compose up devient préférable dès que ton application utilise plusieurs conteneurs qui dialoguent entre eux, ou si tu dois partager la configuration avec d’autres personnes. Au lieu de lancer chaque conteneur avec une commande docker run différente, tu décris la stack dans un fichier docker-compose.yml et tu démarres l’ensemble avec docker compose up -d. Cela limite les erreurs et documente l’architecture.
