Итоговая работа: сервис для команды

Команда принимает небольшой сервис. GET / должен возвращать JSON ровно с двумя полями: message из переменной окружения MESSAGE и status со значением ok. По умолчанию MESSAGE равен Ready for production; при переопределении ответ меняется без пересборки.

{"message": "Ready for production", "status": "ok"}

# Тот же образ с MESSAGE="Runtime wins!":
{"message": "Runtime wins!", "status": "ok"}

Дополнительно процесс работает с UID 65532, HTTP доступен снаружи контейнера, а действующий HEALTHCHECK достигает healthy. Каждое требование имеет своё наблюдение в проверке. Не пытайтесь заменить их одной печатью «ok» в журнал.

Dockerfile задаёт базу python:3.12-alpine, папку /app, COPY . ., значение ENV, USER, проверку здоровья и команду запуска. app.py читает MESSAGE через os.environ, формирует JSON и слушает 0.0.0.0:8000.

В .dockerignore исключите .env и __pycache__/. В этой работе используйте именно COPY всего контекста, чтобы проверить роль исключений. Среда добавит три безвредных контрольных файла: .env и __pycache__/lab-fixture.pyc не должны попасть в образ, а общедоступный lab-context.txt должен оказаться в /app рядом с app.py. Создавать эти контрольные файлы в редакторе не нужно.

# Dockerfile
COPY . .
ENV MESSAGE="Ready for production"
USER 65532:65532

# .dockerignore
.env
__pycache__/

Здесь не требуются pip, apk, скачивание образов или многостадийность. Стандартная библиотека Python уже решает задачу. Так легче связать каждую строку с конкретным требованием и найти причину неуспеха.

Сначала добейтесь сборки и обычного HTTP-ответа. Затем добавьте ограничения: пользователь, healthcheck, чистый контекст. Наконец проверьте чтение MESSAGE. Меняя несколько независимых вещей одновременно, вы усложняете поиск причины ошибки.

Проверка запускает настоящий образ, а не ищет только ключевые слова. Текст USER в комментарии не меняет UID; сообщение, записанное прямо в Python, не реагирует на ENV; всегда успешная проба не показывает работоспособность HTTP. Используйте результаты проверок как список конкретных нарушенных обещаний.

# Вопросы к готовому решению:
# Откуда приходит message?
# Кто выполняет основной процесс?
# Как healthcheck замечает ошибку HTTP?
# Какие файлы COPY не увидит благодаря .dockerignore?

После успеха сохраните эти три файла в свой проект. Для настоящего релиза ещё понадобятся выбранные командой проверки, публикация и эксплуатационные настройки. Итог курса — самостоятельный, проверенный контейнерный сервис с понятными границами ответственности.