Docker или Podman: что выбрать

MAATRIX

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

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

Docker с самого начала построен вокруг демона dockerd — фонового процесса с правами root, который держит все контейнеры под собой. Когда вы пишете docker run, CLI-клиент отправляет запрос демону через сокет /var/run/docker.sock, и уже демон форкает и запускает контейнер через containerd и runc. Это удобно: демон помнит состояние, обслуживает API, перезапускает контейнеры с restart: always даже если вы вышли из SSH-сессии.

Но у этого есть цена. Демон — это единая точка отказа и единая точка привилегий. Если у процесса есть доступ к docker.sock, он фактически имеет root на хосте — это классическая проблема, о которой пишут в любом гайде по двухфакторной защите SSH и харденингу: сокет Docker нельзя раздавать кому попало.

Podman спроектирован иначе — он daemonless. Команда podman run сразу форкает дочерний процесс, который запускает контейнер через runc (или crun) напрямую, без посредника-демона. Контейнер становится обычным дочерним процессом podman, а не потомком фонового сервиса. Практическое следствие: systemctl status docker показывает вам процесс, который может рухнуть и уронить всё хозяйство разом, а у podman такой единой точки просто нет — каждый контейнер живёт сам по себе в дереве процессов.

Это не значит, что Podman не умеет автозапуск при перезагрузке — просто механизм другой: через systemd-юниты, которые Podman умеет генерировать командой podman generate systemd, а начиная с относительно новых версий — через встроенный Quadlet (unit-файлы .container в /etc/containers/systemd/).

Rootless-режим: где Podman действительно впереди

У Docker rootless-режим существует уже несколько лет (dockerd-rootless-setuptool.sh install), но это скорее альтернативный режим работы, который нужно осознанно включать, и часть возможностей в нём урезана (например, некоторые сетевые драйверы или проброс низких портов работают иначе). По умолчанию на свежей установке Docker демон всё ещё запускается от root, и обычный пользователь получает доступ к контейнерам только через членство в группе docker — а это членство эквивалентно root-доступу, что регулярно всплывает в статьях про безопасность Linux-серверов.

У Podman rootless — это базовый сценарий использования, а не надстройка. Любой непривилегированный пользователь может выполнить:

podman run -d --name web -p 8080:80 nginx:alpine

и контейнер запустится от его собственного UID, без демона с правами root в принципе. Для проброса портов ниже 1024 без root придётся либо поднять net.ipv4.ip_unprivileged_port_start, либо использовать порт выше — то же самое, впрочем, актуально и для rootless Docker.

Технически это работает через user namespaces и файлы /etc/subuid и /etc/subgid, которые сопоставляют реальному пользователю диапазон UID/GID внутри контейнера:

# проверить, что диапазоны выделены (обычно настраивается автоматически при установке)
grep "$(whoami)" /etc/subuid /etc/subgid

# если пусто — добавить вручную
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 "$(whoami)"

Практическая выгода: если процесс внутри контейнера каким-то образом вырвется наружу (уязвимость в рантайме, неудачный монтированный volume), он окажется не root-ом на хосте, а обычным непривилегированным UID, замапленным в чужой диапазон. Это не серебряная пуля и не отменяет необходимость фаервола и fail2ban, но заметно сужает поверхность атаки по умолчанию, а не только при дополнительной настройке.

Совместимость с Docker CLI и docker-compose

Здесь Podman сделал разработчикам жизнь заметно проще: команды podman почти один в один повторяют docker — podman ps, podman images, podman exec, podman build. Настолько, что многие дистрибутивы прямо предлагают алиас:

alias docker=podman

и в большинстве повседневных сценариев это действительно работает без переписывания скриптов. Есть нюансы: Podman не имеет встроенного podman-compose из коробки — это отдельный пакет (pip install podman-compose или системный пакет в зависимости от дистрибутива), и он не на 100% повторяет поведение официального Docker Compose V2 — иногда встречаются расхождения в обработке depends_on, healthcheck или сложных build-контекстов, особенно в проектах, которые давно не обновлялись.

Есть и более надёжный путь: Podman эмулирует Docker API через podman system service, и тогда уже официальный docker-compose или docker compose от Docker может работать поверх Podman как поверх обычного Docker-сокета:

systemctl --user enable --now podman.socket
export DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock
docker compose up -d

Это неплохой компромисс для тех, кто хочет rootless-безопасность Podman, но не готов отказываться от привычного docker-compose.yml и его экосистемы плагинов. Если вы только настраиваете продакшен на compose — стоит сначала посмотреть пошаговую установку docker-compose на Ubuntu 24.04, она пригодится независимо от того, Docker это будет или Podman поверх него.

Экосистема и объём документации

Тут преимущество однозначно у Docker, и делать вид, что это не так, — нечестно. Docker Hub остаётся основным реестром образов, на который ссылается подавляющее большинство README и Dockerfile в открытых проектах. Официальная документация Docker обширнее, вопросов на Stack Overflow и в тематических чатах на порядки больше, а любая проблема — от «контейнер не пробрасывает порт» до «не работает сеть» — уже наверняка разобрана в готовых гайдах, включая наши: Docker не пробрасывается порт, нет доступа к сети из контейнера.

У Podman документация тоже вполне рабочая (проект курирует Red Hat, и он лежит в основе OpenShift), но объём материалов меньше, а часть гайдов по нишевым случаям — сложные сети, multi-host оверлеи, специфичные volume-драйверы — либо отсутствует, либо требует адаптации под конкретную версию. Если вы застряли в 2 часа ночи с непонятной ошибкой — вероятность быстро нагуглить решение для Docker выше просто в силу размера сообщества.

Отдельный момент — Docker Desktop и связанный тулинг (Docker Scout, BuildKit-фичи, интеграции с CI/CD). У Podman есть Podman Desktop как аналог, но зрелость и охват интеграций пока не догнали оригинал.

Сравнение по критериям

Строка про Kubernetes не случайна: раз Podman не завязан на собственный демон и API, ему проще генерировать pod-манифесты, совместимые с Kubernetes (podman generate kube), что удобно, если вы позже планируете переезд на k3s или полноценный кластер.

Как попробовать Podman на VPS, не ломая существующий Docker

Оба инструмента спокойно живут на одной машине — конфликтов портов или сокетов не будет, если вы не пытаетесь буквально подменить бинарник docker. Порядок действий на Ubuntu/Debian:

sudo apt update
sudo apt install -y podman

# проверить версию и что всё работает без root
podman info
podman run --rm hello-world

На AlmaLinux/RHEL-подобных Podman обычно уже в базовых репозиториях:

sudo dnf install -y podman podman-compose

Дальше имеет смысл прогнать через Podman тот же самый сценарий, что уже крутится у вас в Docker — например, простое веб-приложение с volume и переменными окружения — и сравнить поведение вживую, а не по документации:

podman run -d --name test-app \
  -p 8081:80 \
  -v ./html:/usr/share/nginx/html:ro,Z \
  nginx:alpine

Обратите внимание на суффикс :Z в монтировании тома — это специфика SELinux-меток, которая часто всплывает на RHEL-подобных системах и которой в Docker обычно не требуется явно управлять. Если вы впервые настраиваете сервер под контейнеры с нуля, независимо от выбора между Docker и Podman полезно сначала пройти базовую защиту сервера — фаервол, ограничение SSH, автообновления — контейнерный движок не заменяет эти слои.

Если после теста Podman вас устроил, полный переход выполняется без даунтайма: остановите сервисы в Docker, экспортируйте нужные образы (docker save / podman load) и поднимите те же контейнеры уже через Podman-юниты — сама подмена движка на уже настроенном сервере обычно занимает меньше времени, чем разворачивание проекта заново.

Частые вопросы