Контейнер не отвечает: где искать причину

На тестовом стенде запрос зависает. Не начинайте с пересборки: она изменит исходные условия. Сначала запишите адрес запроса, время, ожидаемый результат и имя контейнера. В примерах он называется qa-api; команды выполняются в вашем терминале с Docker, а не в редакторе Python.

docker ps -a помогает заметить завершившийся контейнер. Затем прочитайте последние сообщения приложения. Параметры --tail и --since ограничивают объём; --timestamps позволяет сопоставить ошибку со временем запроса. Python traceback полезнее догадки «Docker сломался».

docker ps -a
docker logs --tail 50 --timestamps qa-api
docker logs --since 5m qa-api

Если журнал пуст, это ещё не доказательство отсутствия ошибки: программа могла не писать в стандартные потоки. Для своих диагностических сообщений используйте print(..., flush=True) или запуск python -u app.py. Docker не превращает произвольные файлы журналов в вывод docker logs.

Подробнее: docker logs в документации Docker.

Журнал описывает взгляд приложения, а inspect показывает состояние и настройки контейнера. Например, ненулевой код завершения подтверждает, что процесс завершился с ошибкой; причина всё ещё требует чтения журнала. Поле OOMKilled помогает проверить гипотезу о нехватке памяти.

docker inspect --format '{{json .State}}' qa-api
docker inspect --format '{{json .NetworkSettings.Ports}}' qa-api
docker exec qa-api python -c "import os; print(os.getcwd())"

exec запускает дополнительный процесс в уже работающем контейнере. Здесь мы проверяем рабочую папку; это не новый контейнер и не новая сборка. Если основной процесс остановился, exec не поможет: вернитесь к состоянию и журналу. В минимальном образе может не быть bash или curl, поэтому выбирайте заведомо доступный Python.

Не исправляйте исходник вручную через exec как постоянное решение. Такая правка не попадёт в Dockerfile и потеряется при создании следующего контейнера. Зафиксируйте причину в проекте, соберите новый образ и повторите тот же запрос.

Подробнее: docker inspect в документации Docker.

Подробнее: docker exec в документации Docker.

docker stop просит основной процесс завершиться: по умолчанию отправляет SIGTERM, ждёт установленное время и лишь затем применяет SIGKILL, если процесс не вышел. Возможность закончить текущую работу должна поддерживать сама программа. Команда не гарантирует, что любое приложение успеет сохранить данные.

docker stop --timeout 10 qa-api
docker inspect --format '{{.State.Status}} {{.State.ExitCode}}' qa-api

docker kill по умолчанию сразу отправляет SIGKILL. Это полезный отдельный сценарий аварийного завершения, но он не проверяет корректное выключение. Для QA это два разных теста: «завершение по запросу» и «внезапное прерывание». В отчёте укажите команду, время и поведение незавершённых запросов.

Форма CMD ["python", "app.py"] запускает Python без лишней оболочки между Docker и приложением. Однако сама по себе она не добавляет обработчик сигнала. Наш небольшой учебный сервер нужен для HTTP-проверок; полноценную стратегию завершения разрабатывают отдельно.

Подробнее: docker stop в документации Docker.

Подробнее: docker kill в документации Docker.