Как устранять проблемы с окружением при работе с Docker

Что проверяют

Есть ли у кандидата процедура отладки, а не набор заклинаний. Интервьюер хочет услышать, как человек локализует слой, где сломалось: образ, конфигурация, сеть или сам код.

Как отвечать

Порядок диагностики:

1. docker compose ps и docker compose logs -f <service>: контейнер упал сразу или крутится в рестарт-петле, что в последних строках.
2. docker compose config: печатает итоговую конфигурацию после подстановки переменных из .env. Половина случаев «переменная не подхватилась» видна прямо тут.
3. Зайти внутрь: docker compose exec app sh для живого контейнера, docker compose run --rm app sh если контейнер падает на старте.
4. docker inspect для смонтированных томов, сетей и итогового набора Env.

Типичные причины:

• Переменные: ARG доступен только во время сборки, ENV в рантайме. Значения, которые вкомпилируются в артефакт при сборке, надо передавать через build.args, а не через environment, иначе они просто не доедут.
• Сеть: внутри контейнера localhost это сам контейнер. К соседнему сервису обращаются по имени сервиса из compose (db:5432), к хост-машине через host.docker.internal. EXPOSE ничего не публикует наружу, публикует ports.
• Тома: bind-mount кода поверх рабочего каталога перекрывает то, что положил Dockerfile, включая установленные внутрь site-packages или node_modules. Отсюда классическое «при сборке всё поставилось, а в рантайме модуля нет».
• Кэш слоёв: поменяли requirements.txt, а слой установки взялся из кэша, потому что копирование файла шло после копирования кода. Правильный порядок: COPY requirements.txt, установка, затем COPY . .. Проверка гипотезы: сборка с --no-cache.
• Архитектура: образ, собранный на Apple Silicon, на amd64-сервере падает с exec format error. Лечится --platform linux/amd64 или мультиарх-сборкой через buildx.
• Права: файлы, созданные root-процессом внутри контейнера, не редактируются на хосте. Решается ключом user: в compose или непривилегированным пользователем в образе.
• Готовность зависимостей: depends_on без condition: service_healthy ждёт только старта контейнера, а не готовности Postgres принимать соединения.

Профилактика: пин базового образа по тегу с версией или digest вместо latest, лок-файл зависимостей, .dockerignore, чтобы локальный .venv не уезжал в образ, healthcheck у сервисов, один и тот же образ в CI и на проде.

Где спотыкаются

Ограничиваются ответом «посмотрю логи и пересоберу с --no-cache». Пересборка чаще прячет причину, чем находит: реальная разница обычно в переменных сборки против рантайма или в томе, перекрывшем содержимое образа.