Из памяти
Контейнер отсутствует в выводе docker ps. Назовите минимум три разные причины.
Состояния, которые нельзя смешивать
created означает, что runtime-объект создан, но основной process ещё не стартовал. running — process работает. exited — process завершился, но container и его метаданные сохранились. removed — runtime-объекта больше нет.
rm исчезнут logs, exit code и runtime config контейнера. Сначала собрать факты, потом очищать.Практика: job с ошибкой
docker run --name failing-job alpine:3.21 \
sh -c 'echo "starting checks"; exit 17'
docker ps --filter name=failing-job
docker ps --all --filter name=failing-jobВ первом списке строки нет: process уже завершился. Во втором container существует со status Exited (17).
docker inspect --format \
'status={{.State.Status}} exit={{.State.ExitCode}} error={{.State.Error}}' \
failing-job
docker logs --timestamps failing-job| Наблюдение | Какой вопрос закрывает |
|---|---|
ps --all | Существует ли container и в каком он состоянии? |
inspect .State | Как process завершился: exit code, OOM, runtime error? |
logs | Что process записал в stdout/stderr до завершения? |
inspect .Config | Какой image, command, env и user действительно использовались? |
docker start --attach failing-job запускает тот же container с той же командой. Результат снова будет 17: restart не исправляет детерминированную причину.
exec не заменяет основной process
docker run --detach --name diagnostic-web nginx:alpine
docker exec diagnostic-web nginx -t
docker exec diagnostic-web cat /etc/nginx/conf.d/default.conf
docker top diagnostic-web
docker stats --no-stream diagnostic-webexec запускает дополнительный process в уже running container. Если основной process завершён, выполнить exec нельзя. Изменения через интерактивный shell полезны для исследования, но не являются воспроизводимым исправлением: fix должен попасть в Dockerfile или конфигурацию.
docker rm failing-job
docker rm --force diagnostic-webПорядок triage для CI
- Найти container, включая stopped:
docker ps --all. - Зафиксировать status, exit code, OOMKilled и error через
inspect. - Собрать stdout/stderr через
logs. - Сверить фактические image, command, env, mounts и network.
- Только после сбора артефактов повторять запуск или очищать окружение.
«Я начинаю не с restart, а с состояния контейнера: ps -a, затем inspect для exit code/OOM и logs для stdout/stderr. После этого сверяю фактический image, command, env, mounts и network с ожидаемой конфигурацией. Так я сохраняю причину сбоя и отделяю проблему приложения от инфраструктуры».
Проверка понимания
Первичные источники
- Docker CLI: container commands — справка по жизненному циклу.
- Docker container inspect — низкоуровневые runtime-данные.
- Docker container logs — stdout/stderr контейнера.
Если вывод отличается, сохраните команды и фактический результат и разберите их с преподавателем.