Вы запускаете Docker контейнер, а он моментально завершает работу с загадочным кодом 1. Ни логов, ни понятных сообщений — только разочарование и потраченное время. Код выхода 1 в Docker — это общий индикатор ошибки, означающий, что что-то пошло не так внутри контейнера. Но не отчаивайтесь! В этой статье мы разберемся, как систематически находить корень проблемы и возвращать ваши контейнеры к жизни.
Что на самом деле означает код 1?
Когда Docker контейнер завершает работу с кодом 1, это означает, что основная команда (CMD или ENTRYPOINT), указанная в Dockerfile, завершилась с ошибкой. В мире Unix-подобных систем код возврата 0 означает успех, а любое другое число (обычно 1) — неудачу. Сам по себе код 1 не говорит, что именно сломалось, но указывает направление для расследования.
Код выхода — это значение, которое процесс возвращает операционной системе при завершении. В Docker это значение "пробрасывается" наружу, позволяя вам понять, что контейнер завершился аварийно.
Систематическая диагностика: Пошаговый план
Шаг 1: Проверка логов контейнера
Первое и самое очевидное действие — посмотреть логи упавшего контейнера:
docker logs [container_id_or_name]Если контейнер завершился слишком быстро, добавьте флаг --details или попробуйте запустить его в интерактивном режиме с флагом -it, чтобы увидеть вывод в реальном времени.
Шаг 2: Запуск в интерактивном режиме
Запустите контейнер с интерактивной оболочкой, чтобы исследовать его изнутри:
docker run -it --entrypoint=/bin/sh your_image:tagИли для уже существующего контейнера:
docker run -it --entrypoint=/bin/bash your_image:tagЭто позволит вам вручную выполнить команду ENTRYPOINT/CMD и увидеть ошибку своими глазами.
Шаг 3: Проверка прав доступа и владельцев файлов
Одна из самых частых причин — проблемы с правами доступа внутри контейнера. Убедитесь, что:
- Исполняемые файлы имеют флаг выполнения (chmod +x)
- Пользователь в контейнере (часто указывается через USER в Dockerfile) имеет права на чтение/запись необходимых файлов
- Подключаемые volumes имеют корректные права
Используйте команду docker run -it --entrypoint=/bin/ls your_image:tag -la /path/to/directory для проверки прав доступа к конкретным файлам и директориям.
Шаг 4: Анализ зависимостей и переменных окружения
Проверьте, все ли зависимости установлены корректно:
- Обновлены ли пакеты в образе?
- Не конфликтуют ли версии библиотек?
- Корректно ли заданы переменные окружения (ENV)?
- Не отсутствуют ли необходимые файлы конфигурации?
Распространенные причины и их решения
1. Ошибка в команде ENTRYPOINT/CMD
Проверьте синтаксис в Dockerfile. Опечатка в пути или имени команды — классическая причина кода 1.
2. Отсутствующие файлы или директории
Если скрипт или приложение ссылается на несуществующий файл, контейнер мгновенно упадет. Используйте команды find или ls для проверки существования критических файлов.
3. Проблемы с подключением к внешним сервисам
Контейнер может пытаться подключиться к базе данных, API или другому сервису, который недоступен. Добавьте логику ожидания (wait-for-it, dockerize) или проверьте настройки сети.
4. Нехватка памяти или ресурсов
Ограничения памяти (--memory) или невозможность выделить ресурсы могут приводить к мгновенному падению. Проверьте настройки docker daemon и параметры запуска.
Продвинутые техники отладки
Если стандартные методы не помогают, переходите к тяжелой артиллерии:
- strace: Установите strace в контейнер и запустите команду через него, чтобы увидеть системные вызовы
- Упрощение Dockerfile: Создайте минимальный воспроизводимый пример, постепенно добавляя компоненты
- Проверка healthcheck: Убедитесь, что healthcheck не завершает контейнер при "нездоровом" состоянии
- Анализ слоев образа: Используйте
docker history your_image:tagдля понимания структуры образа
Для сложных случаев используйте docker events для мониторинга событий Docker в реальном времени или инструменты вроде ctop для визуального анализа контейнеров.
Профилактика будущих проблем
Лучшее решение — предотвращение:
- Всегда добавляйте корректную обработку ошибок в скрипты ENTRYPOINT
- Используйте multi-stage builds для создания минимальных и безопасных образов
- Внедряйте linting для Dockerfile (hadolint)
- Пишите интеграционные тесты для контейнеров
- Используйте .dockerignore для исключения ненужных файлов
FAQ: Часто задаваемые вопросы
Как быстро узнать причину падения контейнера?
Используйте комбинацию docker logs и запуска с интерактивной оболочкой. Если контейнер падает мгновенно, добавьте sleep infinity в конец CMD для исследования.
Почему контейнер работает локально, но падает на продакшене?
Частые причины: разные версии образов, отличия в переменных окружения, разные volumes или сетевые настройки, ограничения ресурсов на продакшн-сервере.
Как отладить контейнер, если в нем нет bash или sh?
Создайте отладочный образ на основе alpine или busybox и скопируйте в него содержимое проблемного контейнера, либо используйте docker cp для извлечения файлов.
Код 1 vs код 137 vs код 255 — в чем разница?
Код 1 — общая ошибка приложения. Код 137 обычно означает, что контейнер был убит (SIGKILL), часто из-за нехватки памяти. Код 255 — ошибка выполнения команды или проблемы с системными вызовами.
Можно ли автоматизировать диагностику?
Да, используйте скрипты, которые проверяют логи, метрики ресурсов и здоровье контейнеров. Инструменты вроде Prometheus + Grafana или специализированные SaaS-решения могут помочь в мониторинге.