Envie d’un workflow qui ne craque pas dès que deux projets s’empilent ? Docker s’est imposé comme le raccourci le plus fiable pour lancer, isoler et relancer des environnements en 2026. Oublie les « ça marche sur ma machine » : une image Docker, une commande, et le container démarre, identique pour tout le monde. Ce n’est pas de la magie, mais une suite d’outils qu’il faut apprivoiser.
Naviguer dans la CLI, choisir la bonne option pour démarrer ou relancer un conteneur, savoir où les volumes atterrissent… Ces détails font la différence entre un projet fluide et des heures perdues à déboguer du YAML. Ce guide fait le point terrain : focus sur les commandes Docker de base pour lancer et contrôler un container sans galérer, exemples à la clé et cap sur les petites erreurs qui font perdre une après-midi entière.
En bref :
- Docker run et Docker start : deux commandes proches mais pas interchangeables, utiles pour lancer ou relancer un conteneur.
- Images Docker, ports, volumes et variables d’environnement : vérifier où les options font vraiment effet (ou pas…).
- Éviter les erreurs courantes comme le mauvais mapping des dossiers ou le conflit de ports.
- Les commandes indispensables pour vérifier, lister, stopper un container sans perdre l’état actuel.
- Conseils pour intégrer Docker dans des workflows plus complexes (WordPress, orchestration, etc.).
Maîtriser les bases pour lancer un conteneur avec Docker : du Docker run aux subtilités d’options
Lancer un environnement isolé sur une machine neuve ou amorcer un projet WordPress à partir d’une image prédéfinie : la majorité commence avec la commande docker run. Cette instruction fait double emploi : elle crée un conteneur à partir d’une image Docker (locale ou téléchargée depuis un registre comme Docker Hub) puis démarre ce container d’un coup.
Un raccourci redoutable, mais qui suppose de soigner les options : mapping de ports avec -p, volumes de travail (-v), variables d’environnement (-e), et identification claire (–name ou –rm).
Un environnement concret : Julia, freelance à Angers, doit livrer une maquette WordPress qui tourne partout. Sur son poste, le dossier du projet ne doit pas être écrasé au redéploiement. Elle lance :
docker run -d -v ~/projets/demo:/var/www/html -p 8080:80 --name testwp wordpress:latest
Ici, -d passe le processus en arrière-plan (mode détaché), -v fait pointer le répertoire local sur le dossier WordPress du container, et -p publie en local sur le port 8080. En prime, –name lui évite de devoir retenir un hash abscons. Julia peut arrêter, relancer, migrer sans perdre la main sur ses sources.
Le run seul ne suffit pas à garantir le workflow parfait. Plusieurs outils complémentaires font la différence.
docker ps montrera tous les conteneurs vivants, mais pour retrouver un container arrêté, il faut docker ps -a. À chaque étape, l’important reste d’identifier clairemnt chaque container : faute de nom explicite, tout devient vite illisible.
Tableau de repérage des principales options à garder sous la main :
| Commande | Effet principal | Risques courants |
|---|---|---|
| docker run -d -p 8000:80 image | Lance et détache le container en publiant le port 80 sur 8000 | Oublier le port expose rien sur localhost |
| docker run –name monapp image | Nom explicite au container pour le retrouver facilement | Collision de noms si lancé 2 fois sans suppression |
| docker run -v /host:/container image | Partage de dossiers/vlumes pour persister des données | Attention à ne pas écraser des fichiers importants |
| docker run -e VAR=val image | Passe une variable d’environnement au container | Valeur non prise en compte si mal orthographiée |
Pas d’option magique : chaque paramètre impacte la persistance et la sécurité. En particulier, le mapping de volume (-v) doit être testé, surtout si le container écrit massivement (exemple : base de données). Certains outils (type Docker Compose sur WordPress) facilitent la structuration, mais posent eux aussi leurs pièges.
Relancer, arrêter, et gérer l’état : Docker start, stop et leurs amis
Ne relance pas un chantier complet pour un simple redémarrage : Docker différencie les containers nouveaux et ceux existants. docker start remet en route un container précédemment stoppé (par exemple après un crash ou un reboot). Rien ne se recrée, le container repart là où il s’est arrêté, état préservé, variables identiques. La commande cible le nom ou l’id.
Problème classique : après un docker run, l’erreur « port déjà utilisé » surgit. En général, on avait tout simplement oublié de stopper un ancien container (ou mal mappé le port). Solution : lister avec docker ps -a, repérer les doublons, puis stopper puis relancer le bon avec docker stop suivi de docker start.
Illustration : pour une instance MariaDB déjà créée avec docker run, un simple redémarrage (après change de config, par exemple) nécessite :
docker stop basededonnee
Attente de l’arrêt, vérification du statut éventuel, puis :
docker start basededonnee
Ce cycle évite des re-downs de volumes, aucune donnée n’est perdue (sauf volumes temporaires ou data stockée hors mapping).
Au-delà de start/stop, d’autres commandes permettent de manipuler l’état sans perte :
- docker restart [container] : stop+start en un seul geste, utile pour appliquer certains changements de variables ou de config (hors rebuild d’image).
- docker pause [container] : « met en état de sommeil ». Service figé mais non relancé, moins utilisé mais pratique en phase de test intensif.
- docker rm [container] : suppression totale. Attention, données volatiles effacées si on n’a pas anticipé les volumes.
Pour aller plus loin, certains préfèrent généraliser l’usage de docker-compose pour packager services, réseaux, et volumes. Mais pour des microservices atomiques ou tester vite un nouveau framework, la combo run/start/stop reste imbattable côté réactivité.
Orchestration de plusieurs conteneurs : introduction à Docker Compose et gestion en équipe
Docker Compose simplifie la gestion de plusieurs containers interdépendants (par exemple, WordPress + MariaDB + mailhog). Fini les longues suites de commandes run à copier-coller à chaque nouvelle machine. On centralise toutes les instructions dans un docker-compose.yml. En un docker compose up -d, tout l’écosystème démarre, ports et volumes déjà mappés, réseaux isolés, variables centralisées. C’est là que Docker franchit le cap du simple container de test.
Un collectif d’assos culturelles bordelaises voulait un portail mutualisé : WordPress public, CRM Nextcloud en interne, traçabilité de mails via Mailhog. Compose est vite devenu leur outil central pour partager la même stack en formation. Mais attention à la fausse simplicité : le fichier YAML doit préciser chaque volume et chaque réseau, sinon les containers s’ignorent. Relancer un service isolé, sans tout arrêter, requiert docker compose restart servicename.
Petit aparté rarement documenté : Compose gère aussi les variables d’environnement via des fichiers .env, ce qui permet de ne pas exposer certains secrets sur le repo git partagé avec des tiers. Un gain non négligeable côté sécurité, en particulier dès que les équipes deviennent mixtes. Pour ceux qui travaillent sur VPS (guide VPS OVHCloud ou autre fournisseur), bien vérifier que la version de Docker sur le serveur est à jour. En 2026, il arrive encore que certaines images nécessitent une version plus récente que celle installée par défaut par l’hébergeur.
- Pense à documenter les mappings essentiels dans Compose : ports, volumes, variables d’environnement et dépendances.
- Toujours indiquer les images et leurs tags explicitement.
- Tester le build sur un poste vierge avant de transmettre à l’équipe.
À noter, Compose n’est pas un manager de scaling à la façon de Kubernetes, mais il reste la porte d’entrée idéale pour l’orchestration sur un poste de dev ou un petit serveur mutualisé.
Erreurs récurrentes et pièges lors du lancement d’un container Docker : checklist anti-bug
Même après plusieurs projets, quelques imprévus persistent, surtout lors du lancement manuel de containers. Premier piège classique : oublier une option lors du run et devoir supprimer puis recréer tout le container. Pour éviter ce scénario, systématiser le nommage explicite des containers et la sauvegarde des volumes.
Autre souci fréquent : le conflit de ports. Il s’agit d’un autre service déjà actif sur la machine (parfois un vieux serveur Apache oublié), ou d’un container zombie non stoppé. Un docker ps -a permet de vérifier, puis de stopper l’intrus avec docker stop.
L’oubli du mapping de volume aboutit souvent à la perte de données : le dossier /var/www/html n’étant pas lié au dossier local, une mise à jour ou un nouvel image écrase tout. Il est donc recommandé de toujours vérifier les volumes avant de run une image critique. Certains prennent le réflexe d’associer docker volume ls et docker volume inspect dans leur routine de vérification.
Checklist partielle à consulter pour limiter la casse :
- Le nom du container est unique et documenté.
- Tous les ports nécessaires sont explicitement mappés et libres localement.
- Les volumes essentiels sont associés lors du run.
- La version de l’image est verrouillée et testée.
La vraie différence à long terme : prendre le temps de relire sa commande et de valider chaque paramètre avec une simple commande d’inspection. Bien géré, le lancement d’un container n’est jamais un pari.
Quelle différence entre docker run et docker start ?
docker run crée puis démarre un nouveau container à partir d’une image, alors que docker start ne fait que remettre en marche un container existant, interrompu mais pas supprimé. L’un initialise, l’autre relance sans perte d’état.
Pourquoi certains containers sont-ils inaccessibles depuis le navigateur ?
La plupart du temps, le port utilisé dans le container n’a pas été mappé vers l’hôte. Sans ce mapping (option -p), aucun accès possible depuis l’extérieur. Un autre cas classique concerne un firewall ou une règle réseau qui bloque la connexion.
Peut-on changer une option de volume ou de port après création du container ?
Il n’est pas possible de modifier les mappings de ports ou de volumes rétroactivement. Il faut supprimer le container et en créer un nouveau avec les bons paramètres. D’où l’importance de soigner la commande de run dès le départ.
Comment choisir entre docker-compose et un script bash de commandes docker ?
Compose est conseillé dès qu’on a plusieurs containers interdépendants, ou quand l’équipe a besoin d’un fichier unique pour documenter la stack. Un script bash reste valable pour des tests ponctuels ou des déploiements mono-container simples.
Y a-t-il un risque de sécurité à publier un port ou à monter un volume en clair ?
Oui : tout port mappé vers l’extérieur expose le service, et un volume monté sans restriction donne accès aux fichiers à tout container du même host. Toujours limiter l’exposition en production et ne jamais partager des volumes de config sensibles sans précaution.