Docker: норм или стрем? Разбираемся с местом Docker в современном DevOps-стеке

В конце 2020 года громом грянула новость: Kubernetes объявляет docker-shim устаревшим. Пресса подхватила, заголовки кричали: «Kubernetes бросает Docker!». Это породило массу недопонимания

На деле же Kubernetes никогда не запускал ваши контейнеры напрямую через Docker. Для этого всегда использовался низкоуровневый containerd (или CRI-O), который является частью самого Docker. Docker выступал в роли «менеджера» поверх containerd

Проблема была в том, что Docker не реализовывал напрямую CRI — стандартный интерфейс Kubernetes для работы с контейнерами. Для общения с Docker Kubernetes использовал специальный адаптер, называемый dockershim

➡️ Решение Kubernetes: Убрать этот адаптер и говорить с containerd напрямую через CRI. Это упрощало архитектуру и делало её более стандартной

В итоге с точки зрения разработчика и DevOps-инженера, создающего образы, — ничего не поменялось. Но зачем тогда альтернативы? Podman, Buildah, Kaniko...

Docker — это монолит. Он включает в себя всё:

🌟 Демон (dockerd)
🌟 Сборку образов (docker build)
🌟 Управление контейнерами (docker run)
🌟 Реестр (docker push/pull)
🌟 Оркестрацию (docker-compose, Docker Swarm)

Современная философия Unix — это инструменты, делающие одну вещь, но делающие её хорошо

Вот кто и зачем пришёл на эту сцену:

1️⃣ Podman — «Беспалубный» Docker

Ключевое отличие: не требует демона. Запускает контейнеры от имени пользователя (rootless). Это серьезный плюс для безопасности

Совместимость: CLI почти один в один с Docker. alias docker=podman — и многие даже не заметят разницы

Зачем? Для безопасности, более простой интеграции с systemd и идеологии «без демона»

2️⃣ Buildah — Инструмент для сборки OCI-образов

Ключевое отличие: позволяет собирать образы без Dockerfile и без демона. Даёт тонкий контроль над каждым слоем

Зачем? Для создания минималистичных образов (сборка из scratch) и для CI/CD, где не хочется запускать целый Docker Daemon

3️⃣ Kaniko — Сборка образов в Kubernetes. Хоть и потеряла поддержку, можно использовать форки

Ключевое отличие: Собирает образы контейнеров внутри контейнера или Pod в Kubernetes. Не требует привилегированного доступа (Docker Daemon-less)

Зачем? Идеально для безопасных CI/CD пайплайнов, работающих прямо в Kubernetes. Больше не нужно маунтить /var/run/docker.sock в раннере, что является огромной дырой в безопасности

4️⃣ Nerdctl / containerd — Низкоуровневый контроль

containerd — это и есть та самая среда выполнения, которая теперь используется в Kubernetes по умолчанию. nerdctl — это CLI для работы с ним

Зачем? Для отладки и управления контейнерами прямо на нодах Kubernetes на низком уровне

⚡️ Docker для разработки — бесспорный король

Docker Desktop, простой Dockerfile и docker-compose up — это по-прежнему самый быстрый и удобный способ поднять локальное окружение. Менять это на Podman ради идеологии — часто неоправданная трата времени

Docker в продакшене — уступает место специализированным инструментам

На нодах Kubernetes у вас уже работает containerd. Вам не нужен полноценный Docker.

Для CI/CD использование Docker-in-Docker (dind) или маунта docker.sock считается антипаттерном с точки зрения безопасности. Здесь побеждает Kaniko или Buildah

Для управления контейнерами на серверах (вне K8s) Podman — отличная и более безопасная альтернатива

⏩ Ваши навыки работы с Docker не обесценились

Концепции, которые вы освоили с Docker: образы, слои, volumes, сети, Dockerfile — универсальны. Они переносятся на Podman, Buildah и Kaniko практически один в один. Вы учились не нажимать кнопки в docker, вы учились концепциям контейнеризации

📌 Docker не умер. Он повзрослел и занял свою чёткую нишу. Это как швейцарский нож: он невероятно удобен, когда вам нужно многое сделать быстро и без лишних инструментов (разработка). Но для серьёзной, высоконагруженной и безопасной работы на кухне продакшена шеф-повар будет использовать специализированные ножи: Kaniko для нарезки, Podman для чистки, а containerd — как мощную плиту