Podman против Docker в 2026 году: что выбрать для сервера

В 2026 году контейнеры на сервере — это уже не вопрос «Docker или что-то ещё», а вопрос эксплуатации. Docker остаётся привычным стандартом с огромной экосистемой, Podman предлагает работу без демона, rootless-режим по умолчанию и нативную интеграцию с systemd. Обе системы понимают OCI-образы и запускают одни и те же контейнеры, поэтому выбор редко бывает техническим запретом. Ниже — практическое сравнение без маркетинга.

Архитектура: демон против fork/exec

Docker запускает контейнеры через долгоживущий демон dockerd, который работает от root. Клиент docker общается с ним по сокету /var/run/docker.sock; доступ к этому сокету фактически равен доступу к root. Podman не имеет демона: команда podman сама создаёт контейнер через runc или crun, а затем завершается. Отсюда следует всё остальное — другой подход к автозапуску, другой способ работы с сокетом и другая модель безопасности.

sudo apt install podman podman-compose
podman --version
podman info --format '{{.Host.Security.Rootless}}'
podman run --rm -d --name web -p 8080:80 nginx:alpine
podman ps --format 'table {{.Names}} {{.Ports}} {{.Status}}'

В Fedora и RHEL Podman уже установлен. В Debian и Ubuntu пакет есть в штатных репозиториях, но версия может отставать. Первый запуск от обычного пользователя должен сразу дать rootless-контейнер — главное отличие от Docker, где rootless включается отдельно.

Rootless и subordinate UID

Rootless-режим использует пользовательские пространства имён: внутри контейнера процесс может быть root, но на хосте это непривилегированный пользователь. Для этого в /etc/subuid и /etc/subgid должен быть выделен диапазон UID.

grep "$USER" /etc/subuid /etc/subgid
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 "$USER"
podman system migrate
podman unshare id

Если диапазона нет, podman run завершится ошибкой о newuidmap. Команда podman unshare id показывает, как выглядит отображение внутри пространства имён. В rootless есть ограничения: порты ниже 1024 требуют настройки ядра или проброса, а часть файловых операций с правами может вести себя иначе, чем в Docker от root. Зато компрометация контейнера не даёт доступа к демону с правами root.

Совместимость с Docker CLI и Compose

Podman намеренно повторяет синтаксис docker, поэтому большинство команд заменяются механически. Для инструментов, которые ищут docker, есть пакет podman-docker с обёрткой и сокетом.

podman run --rm -it alpine sh
podman build -t app:test .
podman images
podman logs -f web
podman exec -it web sh

С Compose сложнее. Podman Compose — отдельная реализация на Python, она поддерживает базовые сценарии, но отстаёт от docker compose по полям, healthcheck-условиям и сборке. Второй путь — сокет Podman и настоящий docker compose:

systemctl --user enable --now podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker compose up -d
docker compose ps

Этот способ удобен при миграции: compose-файл остаётся прежним, но контейнеры создаёт Podman. Сокет живёт в пользовательской сессии и должен быть включён для нужного пользователя, а не глобально.

Автозапуск: Quadlet вместо docker run

В Docker типичный ответ — restart: always в compose или systemd-юнит, сгенерированный вручную. В Podman современный способ — Quadlet: файл .container в ~/.config/containers/systemd, из которого systemd генерирует юнит. Это надёжнее, чем podman generate systemd, и переживает перезагрузку.

# ~/.config/containers/systemd/web.container
[Unit]
Description=Web container
After=network-online.target

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
Volume=web-data:/usr/share/nginx/html:Z
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

После создания файла выполните systemctl —user daemon-reload и systemctl —user start web. Юнит называется по имени файла без расширения. Директива AutoUpdate=registry включает обновление по метке io.containers.autoupdate=registry, а таймер podman-auto-update.timer выполняет его по расписанию. В Docker аналог — watchtower или внешний скрипт, что добавляет ещё один контейнер и его права.

systemctl --user daemon-reload
systemctl --user start web
systemctl --user status web
systemctl --user enable --now podman-auto-update.timer
podman auto-update

Сеть, порты и тома

Docker по умолчанию создаёт bridge-сеть и использует iptables. Podman использует netavark и aardvark-dns, а в rootless-режиме — slirp4netns или pasta. На практике это значит, что проброс портов работает так же, а вот обращения к хосту из контейнера требуют внимания: localhost внутри контейнера — это сам контейнер, а не сервер.

podman network create backend
podman run -d --network backend --name db -e POSTGRES_PASSWORD=example postgres:16-alpine
podman network inspect backend
podman volume create web-data
podman volume ls

Для SELinux на Fedora и RHEL монтирование каталога требует суффикса :Z или :z, иначе контейнер получит отказ доступа. Это частая причина «в Docker работало, в Podman нет». Тома с именами переносятся между системами, но пути томов на хосте отличаются, поэтому при миграции проверяйте резервные копии данных, а не только конфиги.

Безопасность и ограничения ресурсов

Rootless Podman убирает главный риск Docker — root-демон и сокет. Но это не делает контейнер песочницей: ядро общее, а ошибки в приложении остаются ошибками. Полезные практики одинаковы для обеих систем.

• Запускайте контейнеры от непривилегированного пользователя внутри образа, если приложение это позволяет.
• Ограничивайте память и CPU: в Podman это работает при cgroups v2.
• Не монтируйте docker.sock или podman.sock внутрь контейнера без крайней необходимости.
• Используйте :Z для SELinux и read-only монтирования там, где запись не нужна.
• Сканируйте образы и обновляйте базовые слои, а не только свой код.

podman run -d --memory=512m --cpus=1.5 --read-only --tmpfs /tmp --tmpfs /var/cache/nginx --tmpfs /var/run nginx:alpine
podman inspect web --format '{{.HostConfig.Memory}}'
podman stats --no-stream

Когда что выбирать

Docker разумнее, если у вас большой compose-стек, CI, завязанный на docker build и DinD, или команда привыкла к Docker Desktop. Экосистема и документация всё ещё шире. Podman разумнее на серверах RHEL и Fedora, в rootless-сценариях, когда нужен автозапуск через systemd без демона, а также если вы хотите снизить привилегии контейнеров по умолчанию.

При миграции действуйте по чек-листу: проверьте subuid, перенесите тома, замените restart-политики на Quadlet, настройте сокет для compose, обновите пути в мониторинге и только потом выключайте Docker. Не направляйте DOCKER_HOST на Podman, если в системе одновременно работает dockerd.

Итог

В 2026 году Podman — зрелый выбор для сервера, особенно там, где ценятся rootless-режим и systemd. Docker остаётся удобнее для разработки и больших compose-стеков, и его экосистема никуда не делась. Технически оба запускают OCI-образы, поэтому миграция возможна, но требует внимания к сокету, томам, SELinux и автозапуску. Если сервер новый и вы готовы освоить Quadlet, начинайте с Podman; если важна совместимость с существующими CI и инструментами, оставляйте Docker.