Docker ломает не контейнеры, а дисциплину: 6 ошибок, которые бьют по продакшену

Docker ломает не контейнеры, а дисциплину: 6 ошибок, которые бьют по продакшену

Docker удобен, пока образ не начинает жить своей жизнью. В арб-командах чаще всего проблемы не в самом рантайме, а в том, как собирают и запускают контейнеры: лишние слои, секреты в образе, случайные права на файловую систему.

• Делать один «универсальный» образ для всего. В итоге тащишь лишние зависимости, раздуваешь attack surface и усложняешь ci_cd.
• Копировать секреты в image или в build context. Это потом всплывает в логах, кешах и артефактах.
• Запускать контейнер от root без нужды. Если процессу не нужна привилегия — не давай её.
• Игнорировать healthcheck и graceful shutdown. Тогда orchestration видит контейнер живым, а приложение уже в деградации.

Ещё один частый косяк — собирать образ без минимизации: один и тот же пакет ставится в runtime и build-стадии, а старые файлы остаются внутри. Для таких кейсов лучше multi-stage сборка, чёткий .dockerignore и явное разделение build/runtime окружения. Это не про «красоту», а про предсказуемость в kubernetes и monitoring.

Проверь свой Docker-пайплайн по трём пунктам: образ должен быть повторяемым, контейнер — не требовать лишних прав, а запуск — нормально переживать рестарт и сетевые сбои. Тогда devops меньше тушит пожары, а observability показывает реальную картину, а не мусор.