TL-DR
docker ps --no-truncet docker inspect CONTAINERfournir le point d'entrée exécuté pour démarrer le conteneur, le long de la commande passée à, mais qui peut manquer certaines parties, par exemple ${ANY_VAR}parce que les variables d'environnement du conteneur ne sont pas imprimées comme résolues.
Pour surmonter cela, docker inspect CONTAINERprésente un avantage car il permet également de récupérer séparément les variables env et leurs valeurs définies dans le conteneur à partir de la Config.Envpropriété.
docker pset docker inspectfournir des informations sur le point d'entrée exécuté et sa commande. Il s'agit souvent d'un script de point d'entrée wrapper ( .sh) et non du programme "réel" démarré par le conteneur. Pour obtenir des informations à ce sujet, demandez des informations sur le processus avec psou /proc/1/cmdlineaide.
1) docker ps --no-trunc
Il imprime le point d'entrée et la commande exécutée pour tous les conteneurs en cours d'exécution. Bien qu'il affiche la commande passée au point d'entrée (si nous passons cela), il n'affiche pas la valeur des variables env de docker (telles que $FOOou ${FOO}).
Si nos conteneurs utilisent des variables env, cela peut ne pas être suffisant.
Par exemple, exécutez un conteneur alpin:
docker run --name alpine-example -e MY_VAR=/var alpine:latest sh -c 'ls $MY_VAR'
Lors de l'utilisation de docker -ps tels que:
docker ps -a --filter name = alpine-example --no-trunc
Il imprime:
NOMS DE PORTS D'ÉTAT CRÉÉS PAR COMMANDE D'IMAGE ID DE CONTENANT
5b064a6de6d8417 ... alpine: dernier "sh -c 'ls $ MY_VAR'" Il y a 2 minutes Quitté (0) Il y a 2 minutes alpine-example
Nous voyons la commande passée au point d'entrée: sh -c 'ls $MY_VAR'mais $MY_VAR n'est en effet pas résolue.
2) docker inspect CONTAINER
Lorsque nous inspectons le conteneur de l'exemple alpin:
docker inspect alpine-example | grep -4 Cmd
La commande est également là mais nous ne voyons toujours pas la valeur de la variable env:
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
],
En fait, nous ne pouvions pas voir les variables interpolées avec ces commandes docker.
Bien que comme compromis, nous pourrions afficher séparément les variables de commande et d'environnement pour un conteneur avec docker inspect:
docker inspect alpine-example | grep -4 -E "Cmd|Env"
Cela imprime:
"Env": [
"MY_VAR=/var",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
]
Une manière plus docker serait d'utiliser le --formatdrapeau de docker inspectqui permet de spécifier les attributs JSON à rendre:
docker inspect --format '{{.Name}} {{.Config.Cmd}} {{ (.Config.Env) }}' alpine-example
Cela génère:
/ alpine-example [sh -c ls $ MY_VAR] [MY_VAR = / var PATH = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin]
3) Récupérez le processus démarré du conteneur lui-même pour exécuter les conteneurs
Le point d'entrée et la commande exécutés par docker peuvent être utiles mais dans certains cas, ils ne suffisent pas car il s'agit "uniquement" d'un script de point d'entrée wrapper ( .sh) qui est chargé de démarrer le processus réel / principal.
Par exemple, lorsque j'exécute un conteneur Nexus, la commande exécutée et affichée pour exécuter le conteneur est "sh -c ${SONATYPE_DIR}/start-nexus-repository-manager.sh".
Pour PostgreSQL, c'est "docker-entrypoint.sh postgres".
Pour obtenir plus d'informations, nous pouvons exécuter sur un conteneur en cours d'exécution
docker exec CONTAINER ps aux.
Il peut imprimer d'autres processus qui pourraient ne pas nous intéresser.
Pour limiter le processus initial lancé par le point d'entrée, nous pourrions faire:
docker exec CONTAINER ps -1
Je précise 1car le processus exécuté par le point d'entrée est généralement celui avec l' 1id.
Sans ps, nous pourrions toujours trouver les informations dans /proc/1/cmdline(dans la plupart des distributions Linux mais pas toutes). Par exemple :
docker exec CONTAINER cat /proc/1/cmdline | sed -e "s/\x00/ /g"; echo
Si nous avons accès à l'hôte docker qui a démarré le conteneur, une autre alternative pour obtenir la commande complète du processus exécuté par le point d'entrée est:: exécuter ps -PIDoù PID est le processus local créé par le démon Docker pour exécuter le conteneur, par exemple:
ps -$(docker container inspect --format '{{.State.Pid}}' CONTAINER)
Formatage convivial avec docker ps
docker ps --no-truncn'est pas toujours facile à lire.
La spécification des colonnes à imprimer et dans un format tabulaire peut améliorer la situation:
docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"
La création d'un alias peut aider:
alias dps='docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"'