Комментарий пользователя
Мы хотим отказаться от Docker-демона в пользу Podman для большей безопасности, но у нас десятки проектов описаны в docker-compose.yml. Подскажите, придется ли все переписывать, или можно как-то запустить существующие compose-файлы через Podman?
Ответ специалиста
Привет, Сергей! Переписывать десятки docker-compose.yml не придется. Экосистема Podman изначально проектировалась с прицелом на максимальную обратную совместимость с Docker.
В современных версиях Podman (начиная с 4.6) есть встроенная подкоманда podman compose. По сути, она работает как прокси-обертка: считывает стандартный docker-compose.yml и передает инструкции внешнему провайдеру. В качестве такого провайдера может выступать написанная на Python специальная утилита podman-compose, без которой не обойтись в старых версиях Podman.
Как это выглядит на практике
Достаточно установить в систему сам podman и провайдер — например, пакет podman-compose. После этого вы просто переходите в директорию с вашим старым проектом и вместо привычной команды выполняете:
podman-compose up -d
Инструмент прозрачно обработает манифест, скачает образы и запустит нужные контейнеры. Для подавляющего большинства стандартных проектов — таких как, связка Nginx + Backend + PostgreSQL + Redis — процесс проходит абсолютно бесшовно. Более того, многие администраторы просто прописывают привычные команды в системе, чтобы даже не переучивать мышечную память:
alias docker-compose='podman-compose'
alias docker='podman'
Важный архитектурный нюанс
Несмотря на отличную совместимость, нужно помнить о разнице подходов к сети. Нативный Podman умеет объединять контейнеры в полноценные Kubernetes-подобные поды, где они делят общее сетевое пространство и могут общаться через localhost.
Однако спецификация docker-compose.yml ничего не знает про поды. Поэтому, когда проект запускается через podman compose, инструмент строго следует логике Docker — создает классическую bridge-сеть (виртуальный мост) и подключает к ней контейнеры. Сервисы будут «видеть» друг друга по именам контейнеров — ровно так же, как это было раньше в Docker.
Нюанс по поводу rootless-безопасности
В Podman теряется возможность использовать network_mode: host — контейнеры больше не видят сетевые интерфейсы хоста, и прямой проброс привилегированных портов (80, 443) ломается. Все внутренние сервисы, которые раньше общались через localhost, придется переводить на DNS-имена внутри bridge-сети, а внешний трафик направлять через podman machine или вручную с помощью iptables.
Порой для каждого сервиса придется добавить user: ${UID} — чтобы файлы, созданные контейнером, принадлежали пользователю на хосте, а не root.
