Контейнеры после Docker: куда движется мир с Podman и что нас ждет в 2026

Революция контейнеризации все-таки состоялась. Мы привыкли упаковывать приложения в контейнеры, а слово «Docker» стало нарицательным, как ксерокс. Но за монополией рано или поздно приходит альтернатива. Тишина вокруг Docker стала оглушительной. После этого сообщество заговорило о безопасности, архитектуре и зависимости от одного вендора.

Из тени вышел Podman. Это был ответ на вопросы, которые раньше боялись или не хотели задавать. Нужен ли нам процесс, который работает с правами root? Можно ли управлять контейнерами иначе и обеспечить безопасность по умолчанию, а не в виде опции?

Разберемся без предвзятости и выясним, что предлагают оба инструмента, где они находятся в 2025 году и что нас ждёт дальше.

Архитектура: демон против бездемонного подхода

Главное различие лежит в самой основе продуктов. Podman, как альтернативный инструмент управления контейнерами, базируется на принципиально иной технологии. Это формирует не только технические, но и идеологические различия.

Docker построен вокруг демона dockerd — это фоновый процесс, который работает с повышенными привилегиями. Когда вы пишете docker run, CLI-утилита не запускает контейнер сама, а даёт команду демону. Демон, обладая правами root, делает всю грязную работу.

Это создает единую точку контроля и отказа. Если демон падает, вы на время теряете управление контейнерами. Уязвимость в демоне открывает путь к захвату всей системы.

Podman пошёл другим путем. В его основе — децентрализованная архитектура. Команда podman run запускает контейнер напрямую, через библиотеку libpod. Процесс работает от имени вашего пользователя. Нет центрального сервера, который можно атаковать.

Это похоже на разницу между центральным сервером и персональными компьютерами. Первый мощный, но его поломка парализует всех. Вторые — независимы, и выход одного из строя не затронет остальных.

Безопасность: rootless как новая норма

В 2025 году запуск контейнеров из-под root — критическая ошибка. Это создает критический риск для всей системы. Идея «безопасность по умолчанию» окончательно победила. Rootless-режим стал обязательной практикой для всех, кто серьезно относится к защите серверной инфраструктуры.

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

Как работает rootless

Оба инструмента используют пространства имён пользователей (user namespaces), чтобы обмануть контейнер. Внутри контейнера процесс может работать от имени root (UID 0). Но ядро хоста прозрачно пробрасывает этот внутренний root-идентификатор на обычный, непривилегированный UID (уникальный идентификатор пользователя) снаружи.

Контейнер внутри работает с правами суперпользователя. Он «считает», что может делать что угодно. Но ядро операционной системы обманывает его. Снаружи контейнер работает с правами обычного пользователя, который его запустил. Все его действия проходят через этот фильтр.

Если злоумышленник найдёт уязвимость и вырвется из контейнера, он окажется не в полной системе, а в ограниченной среде (песочнице) вашего пользователя. Он не сможет удалять системные файлы или мешать другим юзерам.

Podman: rootless из коробки

У Podman этот механизм включен по умолчанию. Вы устанавливаете Podman и сразу можете запускать контейнеры без sudo (команды с повышенными привилегиями). Хранилище образов и контейнеров создаётся в вашем домашнем каталоге (~/.local/share/containers), изолируя работу от действий других пользователей на том же сервере.

Это решает проблему многопользовательских сред. В Docker все, у кого есть доступ к демону (через группу docker), получают эффективные права root на хосте. В Podman пользователь может управлять только своими контейнерами. Он не вправе вмешаться в работу соседа.

Docker: ручная настройка безопасности

Docker проделал большой путь. Его rootless-режим — серьезное достижение. Но он не работает по умолчанию. Системному администратору нужно его сначала установить и настроить.

В rootless-режиме Docker использует дополнительные компоненты, такие как RootlessKit, для эмуляции ряда низкоуровневых функций. Это создаёт определенные проблемы. Например, сетевая связность может быть более ограниченной, а Docker Swarm в rootless-режиме не работает вовсе.

Docker можно обезопасить. Но для этого системному администратору нужно:

• вручную установить и настроить rootless-режим;
• правильно настроить cgroups и делегирование прав;
• переконфигурировать демон для работы без привилегий.

Podman предлагает безопасную конфигурацию сразу после установки. Его архитектура не требует дополнительных настроек для работы в rootless-режиме.

Больше, чем просто rootless — глубина защиты

Безопасность Podman не ограничивается rootless-режимом:

• Меньше прав по умолчанию. Контейнер в Docker изначально получает около 14 System Capabilities — привилегий внутри пространства ядра. Podman по умолчанию выдаёт только 11, следуя принципу минимальных привилегий и отсекая, например, возможность модификации настроек сети.
• Глубокая интеграция с SELinux. В системах вроде RHEL или Fedora Podman автоматически назначает контейнерам SELinux-метки для изоляции. Docker тоже поддерживает SELinux, но часто это требует ручных настроек.
• Аудит и отслеживаемость. Поскольку каждый контейнер — это процесс пользователя, системные журналы и аудиты однозначно показывают, кто именно его запустил. В модели Docker с демоном все действия в журналах проходят как действия пользователя root, что размывает ответственность.

Какая разница для инженера

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

• С Docker по умолчанию: атакующий получает доступ к демону, который работает как root.
• С Docker в rootless-режиме риск снижен. Атакующий остаётся в рамках пользователя, который запустил демон.
• С Podman атакующий попадает в песочницу того пользователя, который выполнил команду podman run. Его возможности строго ограничены. Он не может трогать системные службы, контейнеры других пользователей или критичные файлы хоста.

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

Комментирует Дмитрий Зайцев, CTO Flocktory, программный директор DevOpsConf:

Несмотря на то, что риски атаки в вашу сторону невелики — они есть, и примерно раз в год мы видим уязвимости в разных частях системы (но в основном в runc), которые позволяют зловреду выйти за пределы своего контейнера и получить доступ к докер-демону. Это, в свою очередь, работая от рута, даёт доступ ко всему серверу. Лучше заранее перестраховаться и перейти на решения без центрального демона с рут-доступом.

Дмитрий ЗайцевCTO Flocktory

Комментирует эксперт Лев Прокопьев, технический директор Privesc Technique:

Мило всё это — стандарты, OCI, проверки на деплое. Буду честен: всё это — меры необходимые, но недостаточные. Когда внутри контейнера у вас дырявое приложение, плоская сеть и набор привилегий, которые дают атакующему лёгкий путь к хосту — вы в опасности. Можно ставить любую тулзу, но если в логике приложения заложены возможности вырваться из неймспейса (capabilities, setuid-баги, неограниченные mount/namespace-операции) — вы уже проиграли. Если в сети контейнеров открыт административный интерфейс, а в одном из контейнеров живёт «php-уродец» от племянника подрядчика, который пишет код после двух онлайн-курсов — поздравляю, у атакующего есть не одна, а десятки точек входа. У злоумышленников есть козырь, которого вы не имеете, — время и отсутствие реальных технических возможностей его деанонимизации. А вот e-mail-адреса и пароли ваших разработчиков порой встречаются в логах стиллеров. Вы тюнингуйте CI, но не забывайте, что в наше время паранойя спасает бизнес.

Лев Прокопьевтехнический директор Privesc Technique

Жёсткие факты, без иллюзий:

• Демонстрация standard-compliance и добавление проверок в CI — это полезно, но недостаточно.
• Архитектурные решения движков — лишь часть картины; реальная опасность — в приложениях и в политике привилегий.
• Плоская сеть + доступные админ-панели = тривиальная возможность для lateral movement в вашей инфраструктуре.
• Непроверенный код в образах, секреты в Dockerfile/контексте сборки, неограниченные capability — прямой путь к компрометации хоста.
• Нет ничего зазорного в том, чтобы смотрeть публичные образы на Docker Hub, но если вы тупо его скопировали и не проанализировали (например, с помощью https://github.com/wagoodman/dive), при наличии уязвимости у автора образа или при переиспользовании его конфигураций вы можете подарить атакующим точку входа».

Совместимость: Podman учится говорить на языке Docker

Огромная заслуга Docker — стандарт OCI (Open Container Initiative). Спецификации OCI Runtime и Image Format способны переносить контейнеры между разными системами. Образы, созданные в Docker, работают в Podman через общий формат. Это снимает главный барьер для миграции.

Podman понимает команды Docker. Алиас alias docker=podman у программистов стал мемом, но он реально работает. Большинство базовых команд выполняются одинаково благодаря совместимой CLI-структуре.

Но есть нюансы. Сложные сценарии, особенно связанные с сетью или volumes, могут вести себя по-разному. Прямая замена не всегда срабатывает при использовании специфических флагов или параметров монтирования.

Инструмент podman-docker заменяет бинарник Docker на Podman на системном уровне. Это помогает тестировать Podman в существующих CI/CD-пайплайнах без их переписывания, обеспечивая прозрачную замену.

Docker Compose — отдельная история. Podman долгое время не имел полноценной альтернативы. Сейчас есть podman-compose — реализация на Python, которая всё ещё догоняет по функциональности оригинал. Для простых случаев хватает, но для сложных композиций с несколькими сетями и томами могут возникнуть проблемы с совместимостью.

Комментирует Дмитрий Зайцев, CTO Flocktory, программный директор DevOpsConf:

Это момент, на котором смена решения часто буксует. Docker Compose — буквально стандарт-дефакто для большинства ci-пайплайнов мира. В итоге на Podman и прочие аналоги легко и просто уходят в рантайме, где нужно только запускать контейнеры. А CI остаётся жить с Докером и проблемами, которые вызывает там docker in docker (добавьте ещё пару слоёв in docker по вкусу).

В 2025 году Podman 4.x значительно улучшил совместимость с Compose через нативную поддержку Podman Compose. Однако если ваш пайплайн завязан на специфические функции Docker Compose V2, такие как расширения профилей или кастомные интерполяции, переход потребует дополнительного тестирования и адаптации конфигурационных файлов.

Производительность: битва за миллисекунды и мегабайты

В спорах о производительности контейнерных движков много мифов. Энтузиасты любят сравнивать синтетические бенчмарки, но в реальной работе разница часто незаметна.

Запуск контейнера. Podman, благодаря отсутствию демона, избавляется от одного сетевого hop'а при коммуникации CLI с движком. На практике это экономит десятки миллисекунд. Для человеческого восприятия разница неощутима. Но в автоматизированных пайплайнах, где запускаются тысячи контейнеров последовательно, это может дать небольшой накопительный эффект.

Потребление памяти. Архитектура без демона означает отсутствие постоянно висящего в памяти dockerd. Это экономит от 50 до 100 МБ оперативки. На сервере с десятками гигабайт RAM — это капля в море. Однако для embedded-систем, edge-устройств или стесненных сред каждый мегабайт на счету.

Сетевой стек. И Docker, и Podman в 2025 году используют CNI для настройки сети. Оба поддерживают rootless-сети через slirp4netns. Пропускная способность и задержки практически идентичны. Разницу можно заметить только в очень специфических сценариях с интенсивным сетевым трафиком.

Время сборки образов. Здесь Docker с BuildKit пока сохраняет небольшое преимущество за счет кэширования и параллельного выполнения слоев. Podman тоже развивает свою систему сборки, но для очень больших образов разница может составлять 5-10%.

Вывод по производительности простой. Не она должна быть решающим фактором выбора. Разница не настолько велика, чтобы из-за нее менять инструмент. Гораздо важнее архитектурные особенности и экосистема.

Экосистема: что вокруг них выросло

Docker — это целая вселенная. Docker Hub, Docker Desktop, Docker Scout, BuildKit. Огромная инфраструктура для разработки, сканирования образов и управления уязвимостями.

Podman Desktop — относительно молодой проект для macOS и Windows. Он предлагает графический интерфейс для управления контейнерами и подами и в ближайшее время способен догнать по базовой функциональности Docker Desktop. Но экосистема плагинов и интеграций пока скромнее.

Docker Hub остаётся крупнейшим реестром образов. Podman легко с ним работает. При этом вокруг Podman уже выросла собственная инфраструктура. Проекты по сканированию образов, такие как trivy, интегрируются с Podman не хуже.

Если вы завязаны на конкретные сервисы Docker вроде Scout или Build Cloud, переход на Podman будет болезненным. Если вы используете только базовые функции, разницы не заметите.

Поддержка Pod: группа контейнеров как единое целое

Изначально Podman задумывался как инструмент для работы с подами. Pod — это группа контейнеров, которые разделяют общее сетевое пространство, volumes и другие ресурсы.

Концепцию популяризировал Kubernetes. Podman позволяет создавать и управлять подами на одной машине. Это мощный инструмент для локальной разработки под Kubernetes.

Вы можете описать pod в YAML и запустить его через podman play kube. Это ближе к продакшен-окружению, чем отдельные контейнеры через Docker Compose.

Docker не имеет нативной поддержки пода. Есть сторонние плагины, но они не стали мейнстримом. Если ваша цель — Kubernetes, Podman даёт более точную эмуляцию его поведения.

Что выбрать в 2025 году: практические рекомендации

Сложно сказать однозначно, какой инструмент лучше. Всё сводится к вашим задачам, окружению и философии.

Выбирайте Docker, если:

• ваша команда привыкла к нему — переобучение обойдётся дороже гипотетических выгод;
• вы плотно используете Docker Desktop на macOS/Windows — его экосистема пока богаче;
• ваши CI/CD пайплайны завязаны на специфические фичи Docker Engine или Docker Compose V2;
• вы активно используете Docker Scout, Build Cloud и другие проприетарные сервисы вендора.

Смотрите в сторону Podman, если:

• безопасность — ваш приоритет: rootless-архитектура из коробки более эффективна;
• вы разрабатываете для Kubernetes: возможность работать с подами на локальной машине — ощутимый плюс;
• вы работаете в средах, где недопустимы демоны с правами root (строгие корпоративные политики, госсектор);
• вы используете RHEL, Fedora, CentOS Stream, где Podman предустановлен и считается стандартом де-факто;
• вам нравится философия Unix-way: одна программа — одна задача.

Гибридный подход тоже возможен. Разработчики используют Docker Desktop на ноутбуке, а на продакшен-серверах крутится Podman. Инструменты оркестрации вроде Kubernetes скрывают разницу между Docker и Podman. Платформа работает с обоими движками через стандартные интерфейсы, поэтому пользователю не нужно задумываться о выборе.

Комментирует Лев Прокопьев, технический директор Privesc Technique:

Таблетка:

1. Пересмотрите необходимость каждой capability. Если контейнеру не нужен CAP_SYS_ADMIN — удалите её. Пройдитесь по списку и вычёркивайте всё лишнее — философия «минимальных прав» обязательна.
2. Бизнес-логика под нож. Любая операция, которая запрашивает информацию из внешних сервисов (за эксплуатацию которых вы платите), запускает исполняемые файлы, делает mounts или управляет сетью, — должна быть проверена на предмет злоупотреблений. Логика должна быть проста, предсказуема и проверяема. Если читали новости недавно, наверняка видели, как в недавнем голосовании за изображение на купюре массово эксплуатировали недостатки верификации пользователей на основном сайте ЦБ. Несложно догадаться, что именно сотрудники регулятора получили жёсткую обратную связь и теперь придётся тратить бюджет не только на устранение тривиальных уязвимостей, но и на антикризисный PR.
3. Сегментируйте сеть. Никаких «все входят ко всем». Сетевой доступ по принципу least-privilege: management-interfaces — только из доверенных подсетей через jump-hosts и VPN, не из контейнерной сети.
4. Запретите админ-панели в открытом доступе. Если сервис нужен только для админов — закройте его за IP-фильтрами, MFA и надёжными механизмами контроля доступа.
5. Проверьте supply-chain. Кто собирает образы, какие зависимости подтягиваются, есть ли секреты в CI-контексте. Подпишите и верифицируйте артефакты.
6. Runtime-защита и аудит. Включите SELinux/AppArmor, seccomp-профили, логирование действий пользователей и процессов. Аудит должен показывать, кто и что запустил.
7. Тестируйте логику, а не только окружение. unit/integration + fuzzing + SAST/DAST по бизнес-логике — баги в логике ищутся иначе, чем уязвимости в движке. Разберитесь уже с Burp Professional — Postman круто, но это инструмент QA-шника.
8. Не доверяйте подрядчику по умолчанию. Код сторонних разработчиков — предмет проверки, а не слепого доверия. Code review, dependency-pinning, CVE-сканирование образов.
9. Автоматизируйте инцидент-реакцию. Планы, playbooks, тестовые срабатывания. Чем быстрее вы сокращаете время обнаружения, тем меньше у атакующего «времени в руке».
10. Домашнее задание. Возьмите SAST, например semgrep, и напишите к нему MCP-оснастку; поставьте в Ollama условный Qwen3-Coder и натравите на ваш код в тестовой среде промптом. Его задача — не просто найти уязвимости и пройти ваш compliance, а буквально «раскурочить» код: найти все потенциальные недостатки, внешние библиотеки, которые можно заменить нативным кодом, проверить весь пользовательский ввод и то, как он фильтруется, сделать анализ конфигураций и переменных окружения. И ещё важный нюанс — LLM не должна опрашивать о задаче каждые n секунд: RAG должен передавать завершённую задачу в LLM.

Прогноз на 2026: универсализация и специализация

Мир не стоит на месте. К 2026 году границы между инструментами продолжат размываться. Эти прогнозы — экстраполяция текущих трендов в развитии инструментов:

1. Полная совместимость. Podman добьёт оставшиеся проблемы с Docker Compose. Мы увидим почти прозрачную взаимозаменяемость для 95% сценариев. Стандарт OCI победит.
2. Рост Podman в корпоративном секторе. Благодаря усилиям Red Hat и IBM, Podman будет все чаще появляться в крупных компаниях. Особенно там, где есть сильная команда Linux и требования безопасности.
3. Docker сосредоточится на SaaS. Бизнес Docker будет смещаться в сторону платных облачных сервисов: реестры, сканирование уязвимостей, управление образами. Движок Docker Engine может стать более открытым и модульным.
4. Война за десктоп. Podman Desktop будет активно развиваться, догоняя по удобству Docker Desktop. Возможно, появление новых GUI-инструментов, которые работают поверх обоих движков.
5. Ниша для новых игроков. Появятся инструменты, созданные под специфические сценарии: WebAssembly-контейнеры (Wasm), крайне легковесные среды. Нишевые решения для edge-устройств и IoT.

К 2026 году вопрос «Docker или Podman?» может потерять остроту. Как сегодня мы не спорим, использовать ли vim или nano. Инструменты станут взаимозаменяемыми кирпичиками в более крупных системах. Вашим основным интерфейсом будет не CLI docker или podman, а платформа оркестрации или платформа разработки.

Комментирует Лев Прокопьев, технический директор Privesc Technique:

Вкратце: сложно не любить Podman и не кайфовать от rootless-режима из коробки, но если ваша архитектура и приложения позволяют “выйти наружу” — вы создаёте идеальные условия для тихой и долговременной компрометации. Можете ставить все даты деплоя в зеленый CI-статус — злоумышленник же ставит себе цель не «поймать красный билд», а жить в вашей сети месяцами, собирая деньги, данные и аргументы для дальнейшей эскалации. Не устраняете уязвимости и не режете привилегии — значит, вы просто откладываете неизбежное. Разберитесь с этим сейчас, иначе красивые диаграммы по стандартам станут вашим приговором.

Самый правильный подход в 2025 году — знать оба инструмента. Поэкспериментировать с Podman в pet-проекте. Установить Podman Desktop рядом с Docker. Прочувствовать разницу.

Выбор контейнерного движка становится сугубо прагматичным решением, основанным на конкретных требованиях проекта, а не на трендах в сообществе. Будущее за стандартами, а не за имплементациями.