TL-DR
docker ps --no-truncи docker inspect CONTAINERпредоставить точку входа, выполняемую для запуска контейнера, в соответствии с переданной командой, но это может пропустить некоторые части, например, ${ANY_VAR}потому что переменные среды контейнера не печатаются как разрешенные.
Чтобы преодолеть это, docker inspect CONTAINERесть преимущество, поскольку оно также позволяет извлекать переменные env и их значения, определенные в контейнере, из Config.Envсвойства.
docker psи docker inspectпредоставить информацию о выполненной точке входа и ее команде. Часто это скрипт точки входа оболочки ( .sh), а не «настоящая» программа, запускаемая контейнером. Чтобы получить информацию об этом, запросите информацию о процессе с помощью psили /proc/1/cmdlineпомощью.
1) docker ps --no-trunc
Он печатает точку входа и команду, выполненную для всех работающих контейнеров. Хотя он печатает команду, переданную точке входа (если мы ее передаем), он не показывает значения переменных env docker (таких как $FOOили ${FOO}).
Если наши контейнеры используют переменные env, этого может быть недостаточно.
Например, запустите альпийский контейнер:
docker run --name alpine-example -e MY_VAR=/var alpine:latest sh -c 'ls $MY_VAR'
При использовании docker -ps, таких как:
docker ps -a --filter name = alpine-example --no-trunc
Это печатает:
КОНТЕЙНЕР ID ИМИДЖ КОМАНДА СОЗДАННЫЕ СТАТУС ИМЕНА ПОРТ
5b064a6de6d8417 ... alpine: последняя "sh -c 'ls $ MY_VAR'" 2 минуты назад Exited (0) 2 минуты назад alpine-example
Мы видим, что команда передана точке входа: sh -c 'ls $MY_VAR'но $MY_VAR на самом деле она не разрешена.
2) docker inspect CONTAINER
Когда мы проверяем контейнер alpine-example:
docker inspect alpine-example | grep -4 Cmd
Команда также есть, но мы все еще не видим значение переменной env:
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
],
Фактически, мы не могли видеть интерполированные переменные с этими командами докера.
В качестве компромисса мы могли бы отдельно отобразить переменные команды и env для контейнера с проверкой докера:
docker inspect alpine-example | grep -4 -E "Cmd|Env"
Это печатает:
"Env": [
"MY_VAR=/var",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
]
Более подходящим способом было бы использовать --formatфлаг, docker inspectкоторый позволяет указывать атрибуты JSON для рендеринга:
docker inspect --format '{{.Name}} {{.Config.Cmd}} {{ (.Config.Env) }}' alpine-example
Что выводит:
/ alpine-example [sh -c ls $ MY_VAR] [MY_VAR = / var PATH = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin]
3) Получить запущенный процесс из самого контейнера для запуска контейнеров
Точка входа и команда, выполняемые Docker, могут быть полезны, но в некоторых случаях этого недостаточно, поскольку это «только» сценарий точки входа оболочки ( .sh), который отвечает за запуск реального / основного процесса.
Например, когда я запускаю контейнер Nexus, команда выполняется и показывается для запуска контейнера "sh -c ${SONATYPE_DIR}/start-nexus-repository-manager.sh".
Для PostgreSQL это так "docker-entrypoint.sh postgres".
Чтобы получить больше информации, мы можем выполнить на работающем контейнере
docker exec CONTAINER ps aux.
Это может напечатать другие процессы, которые могут не интересовать нас.
Чтобы сузить начальный процесс, запущенный точкой входа, мы могли бы сделать:
docker exec CONTAINER ps -1
Я указываю, 1потому что процесс, выполняемый точкой входа, как правило, с 1идентификатором.
Без psэтого мы все еще могли бы найти информацию /proc/1/cmdline(в большинстве дистрибутивов Linux, но не во всех). Например :
docker exec CONTAINER cat /proc/1/cmdline | sed -e "s/\x00/ /g"; echo
Если у нас есть доступ к узлу докера, который запустил контейнер, другой альтернативой для получения полной команды процесса, выполняемого точкой входа, является:: execute, ps -PIDгде PID - это локальный процесс, созданный демоном Docker для запуска контейнера, такой как:
ps -$(docker container inspect --format '{{.State.Pid}}' CONTAINER)
Удобное форматирование с помощью Docker PS
docker ps --no-truncне всегда легко читать.
Указание столбцов для печати и в табличном формате может сделать это лучше:
docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"
Создать псевдоним может помочь:
alias dps='docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"'