Générateur de commandes Docker et Podman
Les commandes docker et podman du quotidien : shell, logs, exec, run, build, compose.
À propos de cet outil
Choisissez ce que vous voulez faire, par exemple ouvrir un shell dans un conteneur, suivre ses logs, exécuter une commande, copier des fichiers, l’inspecter, construire ou nettoyer des images, ou piloter Docker Compose, et obtenez la commande docker ou podman exacte avec chaque option expliquée. Le générateur de run transforme aussi un conteneur en fichier Compose, et les commandes run collées peuvent être importées et modifiées.
Mode d’emploi
- Choisissez Docker ou Podman ; les commandes sont identiques, au nom du programme près.
- Choisissez une tâche à gauche, comme Ouvrir un shell, Voir les logs ou Libérer de l’espace disque.
- Renseignez le nom du conteneur et les options. Le nom saisi est repris dans les autres tâches.
- Copiez la commande et lisez ce que fait chaque partie. Pour Lancer un nouveau conteneur, vous pouvez aussi obtenir un fichier Compose.
Questions
- Comment obtenir un shell dans un conteneur en cours d’exécution ?
- Exécutez docker exec -it CONTAINER sh. Utilisez bash au lieu de sh si l’image le contient ; les images slim et Alpine n’ont généralement que sh. Tapez exit pour sortir sans arrêter le conteneur.
- Comment suivre les logs d’un conteneur ?
- docker logs -f --tail 100 CONTAINER affiche les 100 dernières lignes et continue le flux. Ajoutez --since 10m pour ne voir que les lignes récentes, et redirigez vers grep -i --line-buffered error pour filtrer au fil de l’arrivée des lignes.
- Comment transformer une commande docker run en docker compose ?
- Collez la commande dans la zone d’import et basculez le résultat sur Fichier Compose. Les ports, volumes, variables d’environnement, politique de redémarrage, réseau et limites de ressources sont repris.
- Que signifie -p 8080:80 ?
- Le nombre de gauche est le port de votre machine et celui de droite le port dans le conteneur. Préfixez-le par 127.0.0.1: pour que le port ne soit accessible que depuis votre propre ordinateur.
- Quelle est la différence entre un volume nommé et un montage lié (bind mount) ?
- Un montage lié (bind mount) comme ./data:/data relie un dossier de votre machine. Un volume nommé comme pgdata:/var/lib/postgresql/data est un stockage géré par Docker, qui survit au conteneur : c’est le choix habituel pour les bases de données.
- Les commandes Docker et Podman sont-elles identiques ?
- Presque : podman run accepte les mêmes options. Les principales différences sont les réglages par défaut sans root (rootless), si bien que les ports de l’hôte inférieurs à 1024 demandent une configuration supplémentaire, et les systèmes SELinux ont souvent besoin de :Z sur les montages liés.
- Faut-il mettre des mots de passe dans les options -e ?
- Ils se retrouvent dans l’historique de votre shell et dans docker inspect. Au-delà des tests en local, utilisez un --env-file tenu hors du contrôle de version, ou la gestion des secrets de votre plateforme.
- Comment trouver l’adresse IP d’un conteneur ?
- Choisissez Inspecter un conteneur puis Adresse IP : l’outil écrit pour vous le template docker inspect --format. Vous avez cependant rarement besoin de l’IP. Les conteneurs d’un même réseau défini par l’utilisateur ou d’un même projet Compose se joignent par leur nom, comme db:5432, et l’IP peut changer chaque fois qu’un conteneur est recréé.
- Peut-on copier des fichiers depuis un conteneur arrêté ?
- Oui. docker cp CONTAINER:/var/log/app.log ./ fonctionne que le conteneur soit en cours d’exécution ou arrêté, ce qui est pratique pour récupérer des journaux ou des dumps après un plantage. La commande copie aussi des dossiers entiers. Utilisez Copier des fichiers vers ou depuis le conteneur pour obtenir la commande dans un sens ou dans l’autre.
- Quelle est la différence entre docker stop et docker kill ?
- docker stop envoie SIGTERM, attend 10 secondes (modifiable avec -t), puis envoie SIGKILL. docker kill envoie SIGKILL immédiatement, sans laisser au programme la possibilité de faire le ménage. Si stop prend toujours les 10 secondes complètes, votre programme ignore probablement SIGTERM, souvent parce qu’un shell tourne en tant que processus 1 et ne transmet pas le signal.
docker exec ou docker run : quelle différence ?
docker run crée un nouveau conteneur à partir d’une image et le démarre. docker exec exécute une commande dans un conteneur déjà en cours d’exécution. Une erreur courante consiste à lancer docker run -it nginx bash pour « entrer » dans un serveur : cela démarre un nouveau conteneur à côté du vrai, et tout ce que vous y modifiez disparaît. Sans --rm, chaque tentative laisse aussi derrière elle un conteneur arrêté que docker ps -a affichera.
docker exec ne fonctionne que pendant que le conteneur tourne : il ne peut donc pas aider avec un conteneur qui plante au démarrage. Lisez d’abord docker logs --tail 50 CONTAINER. Démarrez ensuite l’image avec un shell au lieu de son programme habituel : docker run -it --rm --entrypoint sh IMAGE. Le générateur de commandes run propose pour cela les champs Point d’entrée et Commande et arguments, sous Plus d’options.
Comment libérer l’espace disque utilisé par Docker ?
Commencez par docker system df, qui indique l’espace occupé par les images, les conteneurs, les volumes locaux et le cache de build. docker image prune ne supprime que les images orphelines (dangling), les restes sans tag des reconstructions. docker image prune -a supprime toutes les images qu’aucun conteneur n’utilise : vous les retéléchargerez donc la prochaine fois. docker container prune supprime les conteneurs arrêtés, ce qui libère aussi leurs couches inscriptibles.
Attention aux volumes : ils contiennent les fichiers de bases de données et les fichiers envoyés. docker volume prune supprime les volumes qu’aucun conteneur n’utilise, et depuis Docker 23, il ne supprime que les volumes anonymes, sauf si vous ajoutez -a. docker system prune -a --volumes efface presque tout ce qui est inutilisé en une seule fois. Les commandes prune demandent une confirmation, sauf si vous ajoutez -f, et rien ne passe par une corbeille : lisez donc la question avant de confirmer.
Politiques de redémarrage Docker : unless-stopped ou always ?
Avec --restart always, Docker redémarre le conteneur chaque fois qu’il s’arrête, ainsi qu’au démarrage du démon Docker, même si vous aviez arrêté le conteneur à la main auparavant. unless-stopped se comporte de la même façon, sauf qu’un conteneur que vous avez arrêté vous-même reste arrêté après un redémarrage. on-failure ne redémarre qu’après un code de sortie non nul. La valeur par défaut, no, ne redémarre jamais. Pour les services de longue durée, unless-stopped est généralement le bon choix.
Dans un fichier Compose, le même réglage s’écrit restart: unless-stopped. La valeur « no » doit être entre guillemets, car les anciens parseurs YAML lisent un no sans guillemets comme false, et la sortie Compose ici l’entoure de guillemets pour vous. Podman est différent : il n’a pas de démon toujours actif, donc les conteneurs dotés d’une politique de redémarrage ne reviennent après un redémarrage que si le service podman-restart est activé, ou si vous les exécutez sous systemd.
Quelque chose ne fonctionne pas, ou un résultat semble faux ? Signaler un problème avec cet outil