Главная/Ограничения Docker/Обзор

Раздел 19. Ограничения Docker

Курс из восемнадцати разделов, объясняющих, как пользоваться инструментом, обязан закончиться разделом о том, когда им пользоваться не нужно. Без этого обучение даёт не инженера, а сторонника технологии.

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

Раздел собирает эти случаи, объясняет механизм каждого и завершается каталогом из шестидесяти двух антипаттернов — с объяснением, почему каждый выглядит разумным и чем оборачивается.

Цели обучения

После раздела учащийся сможет:

назвать ситуации, где контейнеризация увеличивает сложность без соразмерной выгоды;
объяснить, почему изоляция containers недостаточна для недоверенного кода;
объяснить сложности с persistent state и почему база данных в container — отдельное решение, а не умолчание;
назвать, что становится сложнее в отладке, и какие требования это накладывает на observability;
объяснить, почему containers не заменяют virtual machines, configuration management и orchestration;
сформулировать, почему контейнеризация не исправляет архитектурные проблемы приложения;
аргументированно отказаться от контейнеризации в конкретном случае;
распознавать антипаттерны в чужих конфигурациях и называть их последствия.

Предварительные знания

Раздел 11. Production — требования эксплуатации;
Раздел 12. Security — модель угроз и границы изоляции;
Раздел 13. Observability — сложности диагностики;
Раздел 18. Docker и Kubernetes желательно.

Материалы

Где containers усложняют систему
Дополнительный слой абстракции и его цена. Усложнение отладки: новый уровень между кодом и системой. Persistent state и почему он противоречит модели эфемерности. Производительность: сеть, файловая система, GPU и специализированное оборудование. Стоимость поддержки инфраструктуры сборки. Случаи, где обычный systemd-сервис проще и надёжнее.
Границы изоляции
Общий kernel как фундаментальное ограничение. Что означает container escape и почему такие уязвимости появляются регулярно. Недоверенный код: почему containers для него недостаточны и что применяют вместо. Многопользовательские сценарии. Побочные каналы. Когда нужна VM, а когда — отдельная машина.
Когда Docker применять не следует
Систематизированный список: приложения с интенсивным вводом-выводом и жёсткими требованиями к задержкам, десктопные приложения с GUI, задачи, требующие прямого доступа к оборудованию, однократные скрипты, простые статические сайты, окружения, где команда не готова поддерживать инфраструктуру, системы с жёсткими требованиями сертификации. Для каждого случая — механизм и альтернатива.
Каталог антипаттернов
Шестьдесят два антипаттерна с единой структурой: описание, почему выглядит разумным, чем оборачивается, как правильно. Сгруппированы по темам: сборка образов, запуск и lifecycle, данные, сеть, конфигурация и секреты, Compose, эксплуатация, организационные. Полная версия каталога также доступна как справочник.
Практические задания
Аналитические задания раздела.

Практические задания

№	Задание	Тип
1	Проверить собственный проект по каталогу антипаттернов и составить список найденного	обяз.
2	Для трёх найденных антипаттернов написать обоснование исправления с оценкой риска	обяз.
3	Взять задачу из своей практики и аргументированно решить, нужна ли контейнеризация	обяз.
4	Сформулировать, какие требования к observability добавляет переход в containers	доп.
5	Описать сценарий, где контейнеризация базы данных оправдана, и сценарий, где нет	доп.
6	Провести ревью чужого репозитория и написать отчёт с приоритизацией находок	★

Полные формулировки — в exercises.md.

Критерии завершения раздела

Раздел пройден, когда учащийся может без подсказок:

Назвать три ситуации, где контейнеризация ухудшает систему, и объяснить механизм каждой.
Объяснить, почему containers недостаточны для запуска недоверенного кода.
Аргументированно ответить на предложение «давайте всё завернём в Docker».
Найти в чужом репозитории пять антипаттернов и объяснить последствия каждого.
Сформулировать условия, при которых он рекомендовал бы отказаться от Docker в конкретном проекте.

Проверьте себя: Quiz 19.

Что дальше

Это последний раздел курса. Дальше:

Итоговый теоретический тест и практический экзамен;
Проект 4. Production pipeline, если он ещё не выполнен;
Справочники — рабочий материал, к которому возвращаются после курса;
План дальнейшего развития — containerd, Podman, Buildah, Kubernetes, Helm, Linux networking и security.