Tes premières commandes Docker

Tu as installé Docker, tu comprends la différence entre un conteneur et une VM. Maintenant, on met les mains dedans. Ce chapitre te donne les commandes que tu vas taper tous les jours en tant que DevOps — celles qui te permettent de lancer, inspecter, débugger et nettoyer des conteneurs.

Pas de théorie abstraite ici. On lance des trucs, on regarde ce qui se passe, et on comprend pourquoi.

Pourquoi maîtriser les commandes Docker

Docker, c’est pas juste un outil de dev. C’est le socle de quasiment toute infrastructure moderne : CI/CD, microservices, déploiements cloud. Que tu bosses sur Kubernetes, du Docker Compose ou un simple serveur avec des conteneurs, les commandes de base restent les mêmes.

Un DevOps qui galère avec docker exec ou qui ne sait pas lire des logs de conteneur, c’est comme un mécanicien qui ne sait pas ouvrir un capot. Ces commandes sont ton interface directe avec ce qui tourne en production.

🔥 Cas réel : En entreprise, quand une app plante à 3h du matin, ton premier réflexe c’est docker logs et docker ps. Pas un dashboard fancy — les commandes brutes. C’est là que la maîtrise fait la différence entre 5 minutes de debug et 2 heures de galère.

Comprendre le cycle de vie d’un conteneur

Avant de foncer sur les commandes, il faut comprendre comment vit un conteneur. Un conteneur passe par plusieurs états :

Created → Running → Stopped → Removed

La commande docker run est un raccourci qui fait docker create + docker start en une seule étape. Un conteneur arrêté existe encore sur ton système — il prend de l’espace disque et reste visible avec docker ps -a. Il faut le supprimer explicitement pour libérer les ressources.

🧠 À retenir : Un conteneur est éphémère par nature. Tout ce que tu écris à l’intérieur disparaît quand tu le supprimes. Pour persister des données, tu utiliseras des volumes (on verra ça dans un prochain chapitre). C’est un changement de mentalité par rapport aux serveurs classiques — et c’est voulu.

Les commandes essentielles

Lancer un conteneur avec docker run

C’est la commande que tu utiliseras le plus. Elle télécharge l’image si besoin, crée le conteneur et le démarre.

docker run -d --name mon-nginx -p 8080:80 nginx

• -d : mode détaché (tourne en arrière-plan)
• --name mon-nginx : un nom lisible plutôt qu’un ID aléatoire
• -p 8080:80 : redirige le port 8080 de ta machine vers le port 80 du conteneur
• nginx : l’image à utiliser (téléchargée depuis Docker Hub si absente)

Ouvre http://localhost:8080 dans ton navigateur — tu as un serveur web qui tourne. Une commande, c’est tout.

💡 Tip DevOps : Donne toujours un nom explicite à tes conteneurs avec --name. En production, retrouver un conteneur qui s’appelle festive_darwin au milieu de 30 autres, c’est l’enfer.

Inspecter ce qui tourne avec docker ps

Pour voir tes conteneurs actifs, et ceux qui sont arrêtés :

docker ps          # conteneurs en cours d'exécution
docker ps -a       # tous les conteneurs, y compris les arrêtés

La sortie t’affiche l’ID, l’image, le statut, les ports exposés et le nom. C’est ton tableau de bord en ligne de commande.

Lire les logs avec docker logs

Quand un conteneur ne fait pas ce que tu attends, les logs sont ton premier réflexe. Docker capture tout ce que le processus envoie sur stdout et stderr :

docker logs mon-nginx        # les logs complets
docker logs -f mon-nginx     # en temps réel (comme tail -f)
docker logs --tail 50 mon-nginx  # les 50 dernières lignes

⚠️ Attention : Si ton application écrit ses logs dans un fichier à l’intérieur du conteneur (genre /var/log/app.log), docker logs ne les verra pas. Seul stdout/stderr est capturé. C’est pour ça que les bonnes pratiques Docker recommandent de logger sur la sortie standard.

Entrer dans un conteneur avec docker exec

Besoin d’inspecter un fichier de config ou de debugger de l’intérieur ? docker exec te donne un shell dans le conteneur en cours d’exécution :

docker exec -it mon-nginx bash

• -i : garde l’entrée standard ouverte (interactif)
• -t : alloue un pseudo-terminal

C’est l’équivalent d’un SSH dans ton conteneur — sans avoir besoin de SSH.

Arrêter, supprimer, nettoyer

Pour gérer le cycle de vie complet :

docker stop mon-nginx     # arrête proprement (SIGTERM puis SIGKILL après 10s)
docker rm mon-nginx       # supprime le conteneur arrêté
docker rm -f mon-nginx    # force l'arrêt + suppression en une commande

Et pour les images qui s’accumulent sur ta machine :

docker images             # liste les images locales
docker rmi nginx          # supprime une image
docker system prune -a    # nettoie tout ce qui n'est pas utilisé

💡 Tip DevOps : Lance docker system prune -a régulièrement sur tes machines de dev. Les images et conteneurs orphelins peuvent facilement bouffer 20-30 Go d’espace disque sans que tu t’en rendes compte.

Cas concret : debug d’une API en production

Imaginons un scénario réaliste. Tu es DevOps chez une startup, et l’équipe backend te signale que l’API Node.js renvoie des erreurs 500 depuis 10 minutes. L’app tourne dans un conteneur Docker sur un serveur.

Voici exactement ce que tu fais :

# 1. Vérifier que le conteneur tourne bien
docker ps | grep api-backend

# 2. Lire les derniers logs pour comprendre l'erreur
docker logs --tail 100 api-backend

# 3. Entrer dans le conteneur pour inspecter
docker exec -it api-backend sh

# 4. Vérifier la config, les connexions réseau, l'espace disque
cat /app/config.json
curl -s http://database:5432 || echo "DB unreachable"
df -h

🔥 Cas réel : 9 fois sur 10, le problème c’est soit la base de données qui ne répond plus, soit un volume disque plein, soit une variable d’environnement manquante après un déploiement. Les commandes Docker te permettent de diagnostiquer tout ça en moins de 2 minutes.

Les pièges qui font perdre du temps

Le conteneur qui redémarre en boucle. Tu fais docker ps, le conteneur apparaît, puis disparaît. C’est souvent un crash au démarrage. Utilise docker logs nom-conteneur pour voir l’erreur, et docker ps -a pour confirmer que le statut est Exited.

Les ports déjà utilisés. Tu lances un conteneur sur le port 8080 et tu obtiens bind: address already in use. Un autre processus (ou conteneur) occupe déjà ce port. Vérifie avec docker ps ou lsof -i :8080.

⚠️ Attention : Ne prends jamais l’habitude de docker rm -f en production sans réfléchir. Le -f envoie un SIGKILL — ton application n’a pas le temps de fermer proprement ses connexions ou de terminer ses transactions. Utilise docker stop d’abord, qui envoie un SIGTERM et laisse 10 secondes de grâce.

Les images qui s’empilent. Chaque docker run avec une nouvelle version d’image garde l’ancienne en local. Au bout de quelques semaines, tu te retrouves avec des dizaines de Go d’images inutilisées.

🧠 À retenir : Docker ne nettoie rien automatiquement. C’est à toi de gérer le ménage avec docker system prune ou d’automatiser ça dans un cron.

Exercice et essentiel à retenir

À toi de jouer

Mets en pratique tout ce qu’on a vu avec cet exercice guidé. Fais-le sans regarder les commandes au-dessus — c’est comme ça que ça rentre.

1. Lance un conteneur PostgreSQL nommé exo-db avec les variables POSTGRES_USER=admin, POSTGRES_PASSWORD=secret, POSTGRES_DB=testdb, exposé sur le port 5432
2. Vérifie qu’il tourne avec docker ps
3. Lis les logs pour confirmer que PostgreSQL est prêt à accepter des connexions
4. Entre dans le conteneur et connecte-toi à la base avec psql -U admin -d testdb
5. Crée une table et insère une ligne de données
6. Arrête et supprime le conteneur, puis vérifie que tout est nettoyé

🧠 À retenir : Quand tu supprimes le conteneur à l’étape 6, tes données disparaissent. C’est normal — et c’est exactement pour ça qu’on apprendra les volumes dans le prochain chapitre.

L’essentiel

Les commandes de ce chapitre couvrent 90% de ton usage quotidien de Docker :

• docker run — tout commence ici : créer et lancer un conteneur
• docker ps — savoir ce qui tourne (et ce qui a crashé avec -a)
• docker logs — ton premier réflexe de debug, toujours
• docker exec — entrer dans un conteneur pour inspecter et diagnostiquer
• docker stop/rm — gérer le cycle de vie proprement
• docker system prune — garder ta machine propre

Ces commandes sont tes fondations. Tout ce qui vient après — Dockerfile, Compose, orchestration — repose dessus. Maîtrise-les au point de les taper sans réfléchir.

👉 Prochain chapitre : on apprend à construire nos propres images avec un Dockerfile. Fini les images toutes faites — on passe à la création.