О моем восприятии Docker-а

Для тех, кто мог подумать, что я, по каким-то причинам, пытаюсь своими постами выставить Docker в негативном свете. Это далеко не так. Docker - это именно тот проект, с которого началась массовая популярность контейнеров. Docker - это исторически первая удачная упаковка разрозненных фич контейнирзации (Linux namespaces, cgroups, etc) в законченный продукт. Вклад Docker в эту область индустрии просто неоценим. Но у этой медали есть и обратная сторона... Я вижу как минимум 2 проблемы и постоянно пытаюсь обратить на них внимание коллег по цеху.

Во-первых, благодаря своей первоначальной популярности, слово _docker_ для среднестатистического программиста в какой-то момент стало синонимом слова _container_. В то время, как с технической точки зрения было бы корректно говорить "мое приложение выполняется в контейнере", люди традиционно говорят "мое приложение работает в докере". И в этом нет ничего страшного, ровно до тех пор, пока на основе этого искаженного понимания предметной области начинают приниматься технические (в частности архитектурные) решения.

Во-вторых, everything out of the box подход к проблеме контейнеризации, принесший докеру такой стремительный первоначальный успех (что может быть проще, чем yum install docker; docker build .; docker run), оказался и его слабой стороной. Docker старается решить проблемы запуска контейнеров (docker run/exec), управления образами (docker build/push/pull), оркестрирования (docker compose/swarm) и пр. Но далеко не все клиенты Docker заинтересованы сразу во всех его возможностях, в то время, как реализация всех этих фич в одном куске софта налагает как архитектурные (большой демон, управляющий другим демоном), так и операционные (демон еще и запущен под root) издержки. К счастью, кроме Docker существуют и друге проекты, решающие как целиком задачу контейнеризации, так и ее отдельные изолированные подзадачи (podman для управления контейнерами; runc для создания и запуска контейнеров; buildah и skopeo для работы с образами; containerd и cri-o как реализации container runtime для Kubernetes; Kubernetes - как оркестратор; в конце концов kata containers как альтернативный подход к изоляции). И, возвращаясь к первому пункту, для того, чтобы осмысленно начать пользоваться всеми преимуществами этих проектов, необходимо четко представлять зоны отвественности каждого из них.

На мой взгляд, самая сильная сторона Docker сейчас в его применимости в процессе разработки. Установить и начать использовать Docker на локальной машине - проще простого (для контраста попробуйте развернуть локальный Kubernetes cluster). Но если создание образов и выполнение контейнеров в Docker не будет совместимо с конечным окружением, где эти контейнеры выполняются в бою, Docker потеряет и свое последнее преимущество. Благо сейчас каждый из аспектов в этой области стараются завернуть в формальную спецификацию (OCI runtime spec, OCI image spec, Kubenetes CRI spec, etc), и Docker принимает активное участие в этих начинаниях.