Bonnes pratiques et mémo des commandes : le récap complet
Dernier guide de ce parcours. Gardez cette page sous la main : elle est pensée pour être relue, pas juste lue une fois.
Vous êtes parti du guide 1 sans savoir ce qu'était un conteneur. Trente guides plus tard, vous avez construit une image, écrit un Dockerfile complet, géré ports, variables d'environnement et volumes, fait communiquer deux services, orchestré le tout avec Compose, et diagnostiqué une vraie panne. Ce dernier guide rassemble l'essentiel à retenir.
La checklist des bonnes pratiques
- Partez toujours d'une image de base officielle et, quand c'est possible, d'une variante allégée comme alpine (guides 11 et 28).
- Copiez d'abord les fichiers qui décrivent les dépendances, installez-les, puis copiez le reste du code, pour profiter du cache de build (guide 12).
- Ajoutez systématiquement un fichier .dockerignore, en y excluant au minimum node_modules et tout fichier contenant des secrets (guide 14).
- Faites passer toute information changeante ou sensible par une variable d'environnement, jamais écrite en dur dans le code (guide 17).
- Protégez avec un volume nommé toute donnée qui doit survivre à la suppression d'un conteneur (guide 18).
- Préférez un réseau personnalisé, ou Docker Compose, dès que deux conteneurs doivent se joindre par leur nom (guides 20 et 25).
- Ne publiez un port vers l'extérieur qu'après vous être demandé si c'est réellement nécessaire (guide 29).
- Exécutez vos conteneurs avec un utilisateur non-root dès que l'image de base le permet (guide 29).
- En cas de problème, consultez toujours docker logs en premier réflexe, avant toute autre hypothèse (guide 19 et 30).
Le mémo complet des commandes
| Commande | Rôle |
|---|---|
| Commandedocker --version | RôleVérifie que Docker est installé et accessible. |
| Commandedocker run | RôleCrée et démarre un conteneur à partir d'une image. |
| Commandedocker ps | RôleListe les conteneurs en cours d'exécution. |
| Commandedocker ps -a | RôleListe tous les conteneurs, y compris arrêtés. |
| Commandedocker stop | RôleArrête proprement un conteneur actif. |
| Commandedocker start | RôleRelance un conteneur déjà créé. |
| Commandedocker rm | RôleSupprime un conteneur arrêté. |
| Commandedocker images | RôleListe les images présentes sur l'ordinateur. |
| Commandedocker rmi | RôleSupprime une image inutilisée. |
| Commandedocker build -t nom . | RôleConstruit une image à partir d'un Dockerfile. |
| Commandedocker logs | RôleAffiche ce qu'un conteneur a écrit dans sa sortie. |
| Commandedocker logs -f | RôleSuit les logs d'un conteneur en temps réel. |
| Commandedocker exec -it nom sh | RôleOuvre une session interactive dans un conteneur. |
| Commandedocker network create | RôleCrée un réseau personnalisé. |
| Commandedocker network ls | RôleListe les réseaux existants. |
| Commandedocker volume create | RôleCrée un volume nommé (souvent implicite via -v). |
| Commandedocker compose up -d | RôleDémarre tous les services d'un fichier Compose. |
| Commandedocker compose up -d --build | RôleReconstruit les images avant de démarrer. |
| Commandedocker compose down | RôleArrête et supprime les conteneurs Compose (garde les volumes). |
| Commandedocker compose down -v | RôleArrête tout, et supprime aussi les volumes déclarés. |
| Commandedocker compose ps | RôleListe les services gérés par le fichier Compose courant. |
| Commandedocker compose logs | RôleAffiche les logs de tous les services d'un fichier Compose. |
Vous savez expliquer avec vos mots la différence entre une image et un conteneur. Vous savez écrire un Dockerfile réfléchi, pas juste copié. Vous savez configurer une application via ses ports, ses variables d'environnement et ses volumes. Vous savez faire communiquer plusieurs conteneurs, et orchestrer le tout avec un seul fichier Compose. Et vous savez, surtout, où chercher quand quelque chose ne fonctionne pas du premier coup. C'est exactement l'objectif que ce parcours s'était fixé au tout premier guide : vous rendre autonome sur un vrai projet, personnel ou professionnel.
Pour continuer, ailleurs sur Web-Shine Docs
Un Dockerfile et un compose.yaml sont des fichiers de code comme les autres : ils méritent d'être versionnés. Si ce n'est pas déjà une habitude chez vous, le parcours Git & GitHub de Web-Shine Docs vous apprend à suivre leur historique et à les partager sereinement avec une équipe.
Si vous utilisez déjà Claude Code au quotidien, le guide Utiliser Claude Code avec Docker montre comment lui déléguer la rédaction d'un Dockerfile ou d'un fichier Compose, une fois que vous savez, comme maintenant, lire et vérifier ce qu'il vous propose plutôt que de le copier les yeux fermés.
Vérifiez que vous avez compris
Face à un conteneur qui ne se comporte pas comme prévu, sur un vrai projet, quelle est la toute première chose à faire, avant même de modifier quoi que ce soit ?
Consulter ses logs avec docker logs, ou docker compose logs s'il s'agit d'un projet Compose. C'est le réflexe répété tout au long de ce parcours, du guide 19 au guide 30 : dans l'immense majorité des cas, le message qui explique le problème est déjà là, sous vos yeux, avant même d'avoir besoin de modifier une seule ligne de configuration.