Bonnes pratiques et mémo des commandes : le récap complet

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
docker --version	Vérifie que Docker est installé et accessible.
docker run	Crée et démarre un conteneur à partir d'une image.
docker ps	Liste les conteneurs en cours d'exécution.
docker ps -a	Liste tous les conteneurs, y compris arrêtés.
docker stop	Arrête proprement un conteneur actif.
docker start	Relance un conteneur déjà créé.
docker rm	Supprime un conteneur arrêté.
docker images	Liste les images présentes sur l'ordinateur.
docker rmi	Supprime une image inutilisée.
docker build -t nom .	Construit une image à partir d'un Dockerfile.
docker logs	Affiche ce qu'un conteneur a écrit dans sa sortie.
docker logs -f	Suit les logs d'un conteneur en temps réel.
docker exec -it nom sh	Ouvre une session interactive dans un conteneur.
docker network create	Crée un réseau personnalisé.
docker network ls	Liste les réseaux existants.
docker volume create	Crée un volume nommé (souvent implicite via -v).
docker compose up -d	Démarre tous les services d'un fichier Compose.
docker compose up -d --build	Reconstruit les images avant de démarrer.
docker compose down	Arrête et supprime les conteneurs Compose (garde les volumes).
docker compose down -v	Arrête tout, et supprime aussi les volumes déclarés.
docker compose ps	Liste les services gérés par le fichier Compose courant.
docker compose logs	Affiche les logs de tous les services d'un fichier Compose.

Ce que vous savez faire maintenant

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.