Этап 10 - Production Docker
Production Docker — это не больше commands. Это predictable artifacts, observable containers, recoverable data и repeatable deployment.
Production workflow
Production-ready image должен быть маленьким и явным. Он содержит runtime и application files, а не compilers, test reports, source directories, package caches или local credentials. Slim Debian images часто предсказуемы для Java. Alpine меньше, но musl-related compatibility issues могут удивить команду.
CI build
tests and scan
push image tag
VPS pulls tag
container restarts
logs and metrics monitored
Logs, health и deployment
Logging должен идти в stdout и stderr. Docker, host или logging agent могут собрать эти streams и отправить в centralized storage. Если application пишет только в files внутри container, logs могут исчезнуть при замене container.
VPS workflow все равно должен быть artifact-based. CI собирает image, запускает tests, сканирует его, публикует immutable tag, а server скачивает этот tag. Deployment через build на server или latest усложняет rollback и investigation.
Размер image — operational тема
Размер image — не косметическая метрика. Большие images дольше скачиваются, замедляют deployment, занимают больше disk и обычно содержат больше packages, в которых могут быть vulnerabilities. Smaller images проще переносить и проще анализировать.
Но самый маленький не всегда лучший. Alpine может быть отличным для одних workloads, но Java teams иногда предпочитают Debian slim, потому что compatibility предсказуемее. Правильный production выбор — самый маленький image, который остается understandable, compatible и supportable для команды.
Multi-stage builds — обычный путь: build выполняется с full toolchain, затем в final image копируются только runtime artifacts.
Observability до incident
Production containers должны быть observable до того, как что-то сломается. Logs должны идти в stdout и stderr. Metrics должна собирать platform или agent. Health checks должны проверять реальную readiness condition, а не только существование process.
Health check, который запускает только echo ok, почти бесполезен. Лучше вызывать endpoint, который подтверждает, что application может отвечать на requests и, если нужно, достигать critical dependencies.
Deployment завершен только тогда, когда команда видит, что запущено, healthy ли оно и как сделать rollback.
Где работают production containers
В production containers работают на servers или orchestration platforms, а не на ноутбуке разработчика. VPS — самая простая server model: вы подключаетесь по SSH на server, устанавливаете Docker там, скачиваете images там и запускаете containers там.
Registry — мост между CI и production. CI собирает image и делает push. Server делает pull. Это убирает небезопасный pattern, когда developer собирает что-то локально и вручную копирует в production.
Для больших систем Kubernetes или другой orchestrator заменяет ручные docker run или Compose commands. Но Docker concepts остаются важными: images — artifacts, containers — runtime processes, logs идут в stdout/stderr, persistent data нужно обрабатывать осознанно.
Команды: запустить и проверить
Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.
docker build -t registry.example.com/api:${GIT_SHA} .
docker push registry.example.com/api:${GIT_SHA}
docker compose pull && docker compose up -d
docker logs -f api
Таблица для ориентира
| Тема | Что означает | Практический вывод |
|---|---|---|
| Slim image | Small runtime artifact | Меньше transfer и attack surface |
| Health check | Real readiness signal | Process running недостаточно |
| Immutable tag | Точная deployed version | Rollback и audit становятся возможны |
Review production readiness
Перед тем как считать Docker setup production-ready, проверьте пять вещей: image tag immutable, logs выходят из container, health checks проверяют реальную readiness, для data есть backup и restore procedures, deployment не зависит от ноутбука разработчика.
Частая production ошибка — считать Docker самим deployment. Docker упаковывает и запускает containers. Надежный production workflow все равно требует CI, registry, monitoring, rollback и operational discipline.
Контрольная точка
Завершайте курс, когда можете проследить одно изменение от commit к image tag, от image tag к running container и от running container к logs, metrics, health checks и rollback.
Практика: production trace
Проследите один production release от commit до running container. Выпишите commit hash, image tag, registry location, server pull command, health check, log destination и rollback command. Если один пункт отсутствует, production support будет зависеть от памяти, а не от repeatable workflow.