РЕД ОС 7.3 + Podman: тестируем rootless-контейнеры как замену Docker в CI/CD

РЕД ОС 7.3 официально попала в реестр отечественного ПО - это само по себе уже событие для клиентов, которые обязаны работать в реестровом стеке. Но нас в этом релизе зацепило другое: нативный Podman из коробки и rootless-контейнеры как первоклассная функция, не надстройка. Взяли стенд и потратили несколько дней на то, чтобы разобраться, насколько это готово к реальной CI/CD-нагрузке.

Зачем вообще Podman вместо Docker

Контекст для тех, кто впервые слышит: Docker работает через демон с правами root - dockerd крутится как системный сервис, и все команды docker run идут через него. Podman архитектурно другой: демона нет, каждый podman run запускает контейнер напрямую как дочерний процесс вызывающего пользователя. Это называется rootless-режим - контейнер работает под обычным пользователем без sudo.

Для госзаказчиков в контексте требований ФСТЭК это интересно само по себе: атака на контейнер не даёт автоматически root на хосте. Для нас как интегратора это интересно ещё и потому, что именно такой подход хотят видеть при аудитах.

Что проверяли

У одного из клиентов - региональный госзаказчик с активным переходом на РЕД ОС - есть небольшой GitLab с парой десятков пайплайнов. Пайплайны строят Docker-образы, гоняют тесты внутри контейнеров и пушат в приватный registry. Задача: понять, можно ли пересесть на Podman без переписывания всего.

Стенд: РЕД ОС 7.3, GitLab Runner в shell-режиме, пайплайны из реальных проектов клиента.

Что работает сразу

Базовые команды совместимы на уровне CLI:

• podman build читает обычный Dockerfile без модификаций - большинство наших тестовых файлов прошли без единого изменения.
• podman run с теми же флагами, что и docker run. Маппинг портов, тома, переменные окружения - синтаксис идентичен.
• podman push / podman pull работают с registry через стандартный OCI-формат. Подключили наш Harbor - без сюрпризов.

Алиас alias docker=podman - это не шутка из документации, это реально рабочий приём для скриптов, которые зовут docker в явном виде.

Где пришлось покопаться

Bind-маунты и пользователи внутри контейнера. В rootless-режиме работает user namespace remapping: uid 0 внутри контейнера маппируется на uid текущего пользователя снаружи. Это ломает сборки, где Dockerfile делает COPY --chown=root:root или запускает что-то от root с ожиданием реальных прав на хосте. У нас таких было три образа - пришлось разобраться с каждым отдельно. В двух случаях хватило убрать лишний --chown, в одном переписали часть Dockerfile.

--privileged и системные вызовы. Один из пайплайнов строил образ, которому нужен /dev/fuse - Podman в rootless не даёт --privileged в том же объёме, что Docker. Это не баг, это сознательное решение. Решение - либо добавлять --device /dev/fuse явно и разрешать нужные capabilities, либо переосмыслить, зачем вообще нужен fuse в сборочном контейнере.

Сети в rootless. По умолчанию rootless Podman использует slirp4netns вместо bridge-сети. Это работает, но медленнее и без возможности напрямую достучаться до контейнера с хоста через IP (только через маппинг портов). Для CI/CD это обычно не проблема, но если у вас есть сценарий с несколькими контейнерами, которые должны видеть друг друга по DNS, - нужен podman network create и явное подключение.

docker-compose - отдельная история. Есть podman-compose - Python-утилита, которая реализует subset Compose-синтаксиса. Несложные docker-compose.yml работают. Сложные - с depends_on по условию, со специфическими network-настройками - надо проверять руками. У клиента два compose-файла из пяти потребовали правки.

Про CI/CD в GitLab Runner

GitLab Runner в shell-режиме с Podman работает. Команды в .gitlab-ci.yml просто меняются с docker на podman - или добавляется алиас в before_script. DinD (Docker-in-Docker) - отдельный разговор: его типичный подход через docker:dind сервис здесь не нужен, потому что Podman и так не требует демона. Сборка идёт прямо из shell runner-а без привилегированного режима контейнера раннера. Это одно из главных практических преимуществ.

Общее впечатление

Podman в РЕД ОС 7.3 - это рабочий инструмент, не игрушка. Для новых проектов, где Dockerfile пишется с пониманием rootless-ограничений, разница с Docker минимальна. Для переноса существующих пайплайнов нужна итерация: пройтись по каждому Dockerfile и docker-compose.yml, найти места с предположением о root-доступе.

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

Мы пока в середине переноса клиентских пайплайнов. Расскажем, что ещё вылезет.