РЕД ОС 9.1: проверяем podman 5 и обновлённый crun с нашими Compose-манифестами

РЕД ОС 9.1 вышел на прошлой неделе. Релиз минорный, но в changelog есть кое-что интересное для тех, кто использует этот дистрибутив в контейнерных инфраструктурах: podman обновился до пятой версии, а container runtime переехал с runc на актуальный crun. Это закрывает довольно заметный разрыв с upstream RHEL 9.x, который жил с podman 5 уже несколько месяцев, пока РЕД ОС держалась на четвёртой ветке.

У нас несколько проектов, где РЕД ОС используется как базовая ОС на узлах с rootless-контейнерами - не Kubernetes, а именно podman с Compose-манифестами через quadlet или systemd-сервисы. Это нишевая история, но она живёт в определённом классе задач: изолированные рабочие места, dev-окружения на сертифицированных ОС, пара legacy-сервисов, которые ещё не переехали в кластер.

Что изменилось в container stack

Ключевые изменения в 9.1 с точки зрения контейнеров - три.

Podman 5. Главное в нём относительно четвёртой ветки - доработанный netavark (он стал дефолтным сетевым стеком ещё в podman 4, но в пятом его переписали) и улучшенная обработка rootless-сетей. В четвёртом podman rootless-режим на RHEL-производных регулярно давал неожиданности с subuid/subgid при определённых конфигурациях SELinux. В пятом это исправлено более системно, а не патчами поверх.

crun вместо runc. Вот это интереснее. crun написан на C, значительно легче по памяти и быстрее по времени запуска контейнера, чем runc (который на Go). На практике разница в startup time заметна на контейнерах, которые живут секунды, - короткоживущие задачи, cron-подобные воркеры. На долгоживущих сервисах разницы в рантайме нет никакой.

Обновлённые образы в реестре. РЕД ОС поставляет собственный реестр образов, и base-образы теперь пересобраны с учётом новых библиотек. Это важно, если вы тянете registry.red-soft.ru/redos/9.1 как FROM - у него другой digest.

Как тестировали

Взяли четыре Compose-манифеста из реальных проектов и прогнали на тестовой ВМ с РЕД ОС 9.1. Манифесты разные по характеру:

• веб-приложение с nginx, PHP-FPM и PostgreSQL (три контейнера, rootless)
• сервис обработки очередей с несколькими воркерами (podman pod)
• инструментальный стенд с Prometheus, Grafana и экспортёрами
• legacy-сервис с несколькими монтированиями через bind-mount и специфичными uid-маппингами

Три из четырёх запустились без изменений в манифестах. Проблемы нашлись в четвёртом - и они интересные.

Пограничные случаи

uid/gid маппинги в rootless при миграции с podman 4. Одна из служб в legacy-манифесте явно задавала user: "1001:1001" в compose и монтировала том с файлами, владелец которых на хосте был тоже uid 1001. В podman 4 это работало через определённую интерпретацию subuid-маппинга. В podman 5 логика немного изменилась: rootless-контейнер теперь более строго разграничивает namespace uid и host uid. Файлы оказались недоступны - контейнер поднялся, но при первом обращении к тому получил permission denied.

Лечится добавлением :U к опции volume (это указывает podman самостоятельно сделать chown под namespace uid) или явным relabel через :z/:Z. Второй вариант срабатывает только если включён SELinux и relabeling разрешён - на нашем стенде именно этот путь и использовали.

healthcheck с --start-period и crun. В одном из манифестов был healthcheck с --start-period: 30s. В сочетании с crun и конкретной версией compose-спецификации, которую использует podman 5, параметр start-period не всегда применялся корректно - контейнер мог получить unhealthy до истечения периода. Воспроизвелось стабильно на коротких start-period. Это похоже на баг в конкретной версии podman 5, который уже есть в upstream tracker, а не в crun. Временное решение - убрать start-period и увеличить initial delay через другие параметры, либо задать healthcheck через systemd-юнит, минуя compose.

Образы из docker.io без явного реестра. В podman 5 поведение при неявном указании реестра стало строже. Манифест с image: nginx:1.25 без явного docker.io/library/nginx:1.25 теперь даёт предупреждение и может зависнуть на выборе реестра в неинтерактивном режиме. В production-манифестах мы всегда указываем полный путь до реестра - это хорошая практика вне зависимости от версии podman, но в старых тестовых манифестах такое встречалось.

Что с SELinux

Отдельно стоит сказать: SELinux в РЕД ОС 9.1 по умолчанию включён в enforcing-режиме, и политики для container stack обновлены вместе с podman 5. Это правильно, но означает, что при первом запуске контейнеров с нестандартными монтированиями можно получить AVC-отказы там, где podman 4 пропускал. Диагностика стандартная - ausearch -m avc -ts recent плюс audit2allow для выработки разрешения. Ничего нового, но закладывать время на первый запуск стоит.

Где сейчас

Три из четырёх манифестов переехали на 9.1 без проблем. Четвёртый с uid-маппингами потребовал правки в docker-compose.yml и примерно час на диагностику. Это не катастрофа, но и не «просто обновите, всё само заработает».

Разрыв с upstream RHEL в части container stack закрыт - это хорошая новость для тех, кто ориентируется на совместимость с RHEL-экосистемой. Podman 5 сам по себе стабильнее и быстрее на коротких задачах, crun работает без замечаний. Пограничные случаи, описанные выше, встретятся не у всех - только если у вас нестандартные uid-маппинги или healthcheck-и с start-period в rootless-режиме.