Docker контейнер падает сразу после запуска как найти причину

[asyncmonk]

Запускаю контейнер командой docker run, он стартует и тут же падает с кодом выхода 1. Никакого вывода нет, или вывод обрывается моментально. docker logs показывает либо пусто, либо пару строк без явной ошибки. Образ собирается без проблем, локально приложение работает. Что вообще смотреть в первую очередь?

[katykat]

Первым делом запусти docker run --rm -it <image> /bin/sh или /bin/bash — войдёшь внутрь и посмотришь, что происходит вручную. Часто причина в том, что ENTRYPOINT скрипт завершается с ненулевым кодом из-за отсутствующей переменной окружения. Провери все обязательные ENV прямо в шелле.

[kickmybox]

У меня была точно такая же история. Оказалось, что в образе был задан USER без нужных прав на директорию, куда приложение пыталось писать логи. Добавил в Dockerfile строку RUN chown -R appuser:appuser /app/logs — и всё поднялось. docker inspect <container_id> покажет с каким пользователем запущен контейнер.

[sleepypanic]

Советую всегда смотреть docker logs --details <container_id> и ещё journalctl если Docker под systemd. Также попробуй docker run --entrypoint='' <image> sleep 3600 — это переопределит entrypoint и контейнер останется живым, можно будет docker exec зайти и спокойно разобраться.

[juniorredteam]

Развёрнутое решение: диагностика падающего контейнера по шагам. Шаг 1 — docker logs <id> сразу после запуска, флаг -f чтобы стримить. Шаг 2 — смотри код выхода через docker inspect <id> --format='{{.State.ExitCode}}'. Код 1 — общая ошибка приложения, код 126 — нет прав на исполнение, код 127 — бинарь не найден, код 137 — убит по OOM. Шаг 3 — docker events в отдельном терминале, пока запускаешь контейнер, покажет системные события. Шаг 4 — если образ на Alpine, то многие bash-скрипты падают потому что нет bash, только sh; поменяй shebang на #!/bin/sh. Шаг 5 — проверь ulimits и доступную память: docker run --memory=512m может убить контейнер если приложению не хватает. Чаще всего проблема в одном из трёх: неверные переменные окружения, права на файлы, отсутствующий бинарь в PATH.

[svelte88]

Ещё момент — если используешь docker-compose, то restart: always маскирует проблему, контейнер крутится в петле рестартов и кажется что работает. Поставь restart: 'no' на время отладки и смотри логи.

[sleepypanic]

Кстати, docker run --log-driver=journald или просто --log-driver=json-file с --log-opt max-size=10m стоит настроить в продакшене, иначе логи либо теряются либо съедают диск. Но это уже отдельная тема.

[mynancy]

Еще частая причина, которую тут не назвали: бинарь собран под glibc, а образ alpine. Падает мгновенно, в логах либо пусто, либо невнятное no such file or directory, хотя файл на месте лежит. Проверяется через ldd на бинарь внутри контейнера или тупо пересборкой с CGO_ENABLED=0, если это go. У меня джун неделю с этим воевал, пока я не глянул FROM в его Dockerfile.

[kingpaul]

@katykat, docker run -it image /bin/sh переопределяет только CMD. Если в образе задан ENTRYPOINT, твой sh уедет в него аргументом и ничего не получится. Надо -entrypoint /bin/sh, иначе человек попробует твой вариант и решит, что совет нерабочий.

[rn2l3x4zop]

@juniorredteam, простыня неплохая, но 139 забыл, это segfault. И 143 это SIGTERM от оркестратора, не ошибка приложения, тоже полезно знать. По формату подозрительно похоже на копипасту из чатгпт, ну да ладно, коды хотя бы верные.