DOCKER · LINUX · EXPLOITATION
La commande docker exec -it permet d’entrer dans un conteneur en cours d’exécution pour diagnostiquer un incident, tester une configuration ou vérifier un comportement sans reconstruire l’image. Bien utilisée, elle accélère le troubleshooting. Mal utilisée, elle masque des dérives d’exploitation.
📋 Au programme
En pratique, docker exec -it sert à lancer un shell interactif dans un conteneur déjà démarré. L’option -i garde l’entrée standard ouverte et -t alloue un pseudo-terminal. Tu peux ainsi lancer bash, sh, env, ps ou un outil de debug sans arrêter le service.
💡 Réponse rapide
Utilise docker exec -it <container> sh pour ouvrir un shell dans un conteneur vivant, vérifier l’état réel du service et confirmer rapidement un problème de configuration, de permissions ou de réseau.
À quoi sert docker exec -it dans un contexte réel
Quand un service conteneurisé répond mal, le premier réflexe consiste souvent à lire les logs ou à redéployer. C’est utile, mais parfois insuffisant. Tu as besoin de voir l’intérieur du conteneur au moment exact où l’incident se produit. C’est là que docker exec -it devient précieux.
La commande permet d’ouvrir une session interactive dans un conteneur déjà lancé. Tu peux confirmer la présence d’un fichier, inspecter une variable d’environnement, tester une résolution DNS, vérifier des permissions, rejouer une commande applicative ou observer les processus actifs. Pour une équipe infra ou DevOps, c’est un outil de diagnostic, pas une méthode de configuration durable.
Le vrai enjeu n’est pas seulement technique. Si tes incidents prennent trop de temps à qualifier, le coût monte vite, surtout quand l’application est utilisée par des équipes métier ou des clients. Réduire le temps de diagnostic améliore directement la continuité d’exploitation. C’est aussi pour cela qu’un audit d’infrastructure ou une maintenance serveurs Linux bien structurée reste utile, même quand Docker est déjà en place.
Différence entre docker exec, docker run et docker attach
Ces trois commandes sont souvent confondues, alors qu’elles ne répondent pas au même besoin.
✅ Comprendre le bon outil
docker run crée un nouveau conteneur à partir d’une image.docker attach se connecte au processus principal déjà lancé.docker exec -it lance un nouveau processus interactif dans un conteneur existant.Dans la vraie vie, docker attach est rarement le bon choix pour enquêter sur un service web, une base ou un worker, car tu risques de perturber le processus principal. docker exec -it est plus propre pour un shell ponctuel. À l’inverse, si ton conteneur n’existe pas encore, il faut utiliser docker run ou redémarrer via Compose.
docker ps
docker exec -it mon-nginx sh
docker exec -it mon-app bash
docker exec mon-app env
⚠️ Attention au shell disponible
Beaucoup d’images légères n’embarquent pas bash. Si docker exec -it <container> bash échoue, teste sh ou ash.
Cas d’usage concrets en production
La valeur de docker exec -it apparaît surtout dans trois situations.
🌐
Diagnostic réseau
Tester une résolution DNS, vérifier un port ou comprendre pourquoi un service applicatif n’atteint pas sa base.
🔐
Vérification de permissions
Contrôler un répertoire monté en volume, l’utilisateur effectif ou les droits sur un fichier critique.
📦
Contrôle d’environnement
Lister les variables, observer les processus et vérifier si le conteneur exécute vraiment ce que tu crois avoir déployé.
🛠️
Troubleshooting applicatif
Lancer une commande métier, vérifier une migration ou comparer un comportement entre deux environnements.
Un bon exemple est le diagnostic d’un conteneur web qui démarre, mais répond en erreur 502 derrière un reverse proxy. Les logs disent seulement que l’application n’est pas prête. Avec docker exec -it, tu peux vérifier si le fichier de configuration est présent, si le socket existe, si les variables ont bien été injectées ou si la commande de démarrage a dérivé. Tu gagnes du temps, et surtout tu évites les hypothèses fragiles.
Méthode de diagnostic propre avec docker exec -it
Le piège classique consiste à entrer dans le conteneur, modifier à la main un fichier, relancer un service et considérer que le problème est réglé. Ce n’est pas une correction durable. C’est au mieux une preuve temporaire. La bonne approche consiste à utiliser docker exec -it pour observer, pas pour bricoler la production.
# 1. Identifier le conteneur
docker ps
# 2. Entrer avec un shell compatible
docker exec -it mon-app sh
# 3. Vérifier le contexte
whoami
pwd
env | sort
ps aux
# 4. Contrôler les fichiers utiles
ls -lah /app
cat /etc/hosts
# 5. Tester le réseau
ping -c 1 db || true
nc -zv db 5432 || true
Cette séquence permet d’objectiver le problème. Si tu découvres qu’une variable d’environnement manque, la vraie correction doit revenir dans ton docker-compose.yml, ton manifeste, ton pipeline ou ton image, pas dans une manipulation interactive oubliée une heure plus tard.
Ne transforme pas le conteneur en serveur mutable
Si tu corriges un bug directement dans le conteneur avec vi, apt install ou une modification manuelle, tu crées un écart entre la prod réelle et le code source. À la prochaine recréation, le problème reviendra.
Pour industrialiser proprement Docker, il faut documenter les diagnostics récurrents, fiabiliser les images, verrouiller les permissions et revoir l’architecture si nécessaire. C’est exactement le type de sujet couvert par une démarche d’infogérance serveurs Linux quand l’exploitation devient trop dépendante de gestes manuels.
Erreurs fréquentes avec docker exec -it
⏱ Conteneur déjà arrêté
La commande ne fonctionne que sur un conteneur en cours d’exécution. Si le service crash au démarrage, commence par les logs puis corrige la cause racine.
🔤 Mauvais shell
Les images Alpine ou minimalistes n’ont pas toujours Bash. Utilise sh si besoin.
🧱 Correction non pérenne
Une modification faite à la main dans le conteneur disparaîtra au prochain redéploiement. Il faut reporter le correctif dans l’image ou la configuration source.
🔒 Droits insuffisants
Dans certains environnements verrouillés, l’utilisateur courant ne peut pas inspecter toutes les zones du conteneur. Il faut alors revoir le modèle d’image ou la stratégie de diagnostic.
Bonnes pratiques d’exploitation à retenir
La meilleure équipe n’est pas celle qui tape le plus vite docker exec -it, mais celle qui en a de moins en moins besoin. Un usage fréquent peut révéler plusieurs faiblesses : observabilité insuffisante, logs pauvres, image mal conçue, documentation absente ou procédures d’escalade floues.
La bonne posture
Utilise docker exec -it pour confirmer un état, collecter une preuve et améliorer ensuite ton infrastructure, pas pour maintenir un correctif fantôme.
Concrètement, je recommande de garder une checklist simple : savoir quels conteneurs peuvent être inspectés, quels tests sont autorisés, quelles commandes sont sûres, et comment consigner un diagnostic. Si tu veux aller plus loin, relie ce type de procédure à tes revues d’exploitation, à ton monitoring et à tes pipelines de déploiement.
✅ Checklist avant d’utiliser docker exec -it en prod
FAQ sur docker exec -it
▶ Que signifie exactement l’option -it ?
-i garde l’entrée standard ouverte et -t crée un terminal interactif. Ensemble, elles permettent d’ouvrir une session utilisable humainement dans le conteneur.▶ Pourquoi docker exec -it bash ne fonctionne pas toujours ?
sh ou ash, surtout sur Alpine et les images minimales.▶ Peut-on utiliser docker exec -it en production ?
▶ Quelle différence avec docker attach ?
▶ Comment éviter d’avoir à utiliser trop souvent docker exec ?
Besoin d’un socle Docker plus propre et plus diagnostiquerable ?
Je peux t’aider à fiabiliser tes images, ton exploitation et tes procédures d’incident pour éviter les conteneurs bricolés et les diagnostics trop longs.