Практика: контейнер сообщает о здоровье

Коллеги запускают ваш образ на тестовом стенде. Им нужен сигнал, что сервер уже принимает HTTP-запросы. Исходный сервис работает, но образ пока не содержит проверки здоровья. Измените Dockerfile, сохранив ответ {"message":"Hello, Docker!"}.

Редактор содержит три настоящих файла сборки. После отправки они попадут в отдельную временную машину: там Docker соберёт образ и запустит контейнер. Команды из теории не нужно вставлять в app.py; ваша задача здесь — изменить рецепт сборки.

# К существующему Dockerfile нужно добавить HTTP-проверку.
# Используйте Python из базового образа.
# Порт приложения: 8000.

Проверка должна действительно обратиться к http://127.0.0.1:8000/. Используйте urllib.request.urlopen: при сетевой ошибке или HTTP-ошибке исключение приведёт к ненулевому завершению Python. Не перехватывайте исключение с последующим успешным выходом.

Задайте --interval=5s --timeout=10s --start-period=10s --retries=2. Такой профиль оставляет запас для учебной среды и позволяет обнаружить недоступность сервера за несколько проверок. Сохраните CMD запуска сервера: команда здоровья не заменяет основной процесс, а запускается дополнительно.

CMD ["python", "app.py"]
# HEALTHCHECK — отдельная инструкция, а не аргумент CMD.

Если сборка не прошла, до проверки HTTP дело ещё не дошло: начните с Dockerfile. Если образ собрался, но сервер не отвечает, проверьте журнал приложения и адрес прослушивания. Если HTTP правильный, а здоровья нет — вернитесь к команде пробы.

После успешной попытки объясните своими словами, почему внешний запрос и внутренний healthcheck нужны вместе. Сервер, слушающий только loopback, может пройти внутреннюю пробу и остаться недоступным другим контейнерам. В этой задаче такое решение не считается готовым.

HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()