Мы перестали использовать Docker в 2025 году — вот что пришло ему на смену

Мы не ожидали, что откажемся от Docker — пока новая контейнерная система не оказалась быстрее, дешевле и удивительно проще в управлении.

Docker не умер, но это решение с ограничениями, и в 2025 году многие команды от него откажутся.

Мы отошли от Docker как основного решения для контейнеризации. Docker был заменён комбинацией бездемонных рантаймов, облегчённых образов, серверлес-контейнеров и исполнения, ориентированного на edge.

Если ваша система развертывания по-прежнему основана на командах Docker build и Docker run, вы можете платить за устаревшие методы.

Почему мы решили отказаться от использования Docker

Накладные расходы и сложность снова начали незаметно расти.

Мы очень рано начали использовать Docker, ещё на раннем этапе его распространения. Сначала это было захватывающе — волшебный способ упаковать всё в один контейнер и запускать где угодно. Со временем стало очевидно, что у этого есть свои издержки и скрытые «платежи»

Демон Docker, изменения в лицензировании, то, что Docker Desktop потреблял слишком много ресурсов, и связка с конфигурациями Kubernetes вызывали ощущение громоздкости.

Мы обнаружили, что тратим время на:

• Лицензирование, обновления и перерасход ресурсов Docker Desktop
• CI-пайплайны, которые падали из-за проблем с Docker daemon.
• Отладка вопросов типа «Почему этот контейнер не rootless?» или «Почему нельзя запустить это на edge?»
• Сопоставление файлов Compose с средами, которые не соответствовали производственной среде.

Контейнерная экосистема изменилась прямо у нас на глазах.

К 2025 году созрели следующие изменения:

• Kubernetes отказался от Docker runtime за несколько лет до этого, и такие рантаймы, как containerd и CRI-O, стали стандартом.
• Утилиты, такие как Podman, Buildah, nerdctl и containerd, развивались, создавая более легкие и безопасные (более защищенные) контейнеры без демонов, соответствующие спецификациям OCI.
• Бессерверные контейнерные платформы (такие как AWS Fargate, Cloud Run) позволяют развертывать контейнеры без какого-либо управления Docker.
• В связи с появлением периферийных вычислений и актуальностью минимальных сред выполнения, демоны Docker перестали быть полезными.

Но мы задались вопросом: мы используем Docker потому, что он соответствует нашим потребностям, или по привычке?

Чем мы заменили Docker (и почему)

Вот инструменты и подходы, к которым мы перешли, и причины их работы.

1. CLI без демонов + среда выполнения OCI (например, Podman + containerd)

Вместо команд docker run и docker build мы перешли на podman run и buildah.

• Podman — это совместимый с Docker интерфейс командной строки с rootless-контейнерами, без долгоживущего демона.
• containerd/nerdctl позволили убрать промежуточный демон и выполнять OCI-команды напрямую.

Преимущества: быстрый старт, меньший расход памяти, меньше привилегий.

2. Бессерверные контейнерные платформы для сервисов без сохранения состояния

Для многих наших API и фоновых процессов мы перешли на AWS Fargate и Google Cloud Run.

• Мы создавали образы OCI, но теперь развертываем их без управления хостами.
• Автоматическое масштабирование, обновление программного обеспечения и инфраструктура абстрагированы от остального мира.

Преимущества: меньше затрат на инфраструктуру; больше времени на разработку новых функций.

3. Минимальные сборки контейнеров с Buildah/Kaniko

Вместо полноценных Dockerfile-файлов мы начали использовать Buildah для сборки образов в CI: никакого демона, более быстрая сборка, меньший размер образов.

Преимущества: чище пайплайны, меньше сбоев сборки, меньше избыточного кода.

4. Edge / альтернативные рантаймы, для которых Docker не подходит.

В области микросервисов, связанных с edge или приложениями с ультранизкой задержкой, мы экспериментировали с wasm-модулями или лёгкими рантаймами, подходящими для разрабатываемых кейсов. Docker был избыточным решением.

Преимущество: меньше задержка при запуске и меньше расходование ресурсов.

Как мы осуществили миграцию (пошагово)

1. Проведена инвентаризация всех сервисов. Мы составили список всех контейнеров, их рантайм, состояния и требований к масштабированию.
2. Классификация нагрузок: без сохранения состояния, сервисные, периферийные, с большим объемом сохранения состояния. для каждой категории выбирали самый простой рантайм, удовлетворяющий требованиям.
3. Пилотная замена. Мы начали с менее важных сервисов, развернув их с помощью Podman/containerd и Fargate.
4. Переработка конвейеров сборки. Перешли с docker build на CI buildah, kaniko; обновили файлы Compose или скрипты.
5. Мониторинг и сравнение. Мы измерили объем используемой памяти, задержку запуска и стоимость до и после миграции. В одном случае нам удалось сократить накладные расходы на время сборки на 28%.
6. Масштабирование внедрения. Убедившись в эффективности, мы перенесли больше сервисов; устаревшие образы Docker остались для тех редких случаев, когда контроль имел значение.
7. Архивируйте рабочие процессы, использующие только Docker. Мы рассматривали Docker как устаревший продукт — не удаляли полностью, но больше не использовали по умолчанию.

Компромиссы: от чего мы отказались и что приобрели

Прибыль:

• Снижение сложности и стоимости инфраструктуры.
• Ускоренные циклы разработки
• Улучшенная безопасность (отсутствие root-прав, меньшее количество демонов)
• Подходит для современных нагрузок (edge, serverless)

Чем мы пожертвовали:

• Некоторые навыки и мышечная память разработчиков в отношении docker- команд.
• Инструменты экосистемы Docker и интеграция с графическим интерфейсом (хотя существуют и альтернативы)
• Традиционные формы управления состоянием и специализированные контейнеры требуют использования отдельных команд Docker.

Заключительный вывод: стоит ли прекратить использование Docker?

Если вы используете небольшие, бессерверные или менее ресурсоемкие рабочие нагрузки, а стоимость и скорость разработки имеют значение — да, стоит рассмотреть замену.

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

Вопрос не в том, умер ли Docker? Вопрос скорее в том, удовлетворяет ли Docker мои потребности, или я удовлетворяю потребности устаревшего Docker?