CentOS Stream на практике: ядро три раза за месяц и пакеты из будущего RHEL 8.4

После январского объявления о смерти CentOS 8 мы решили не просто читать документацию по CentOS Stream, а поставить его на живой, но не критичный сервер и посмотреть, как оно себя ведёт. Сервер у клиента выполнял роль внутреннего прокси для разработчиков - нагрузка есть, но падение на час-два не катастрофа. Идеальная площадка.

Прошёл месяц. Пора зафиксировать что увидели.

Как перешли на Stream

Переход с CentOS 8 на CentOS Stream - это не переустановка, а одна команда:

dnf install centos-release-stream
dnf distro-sync

После distro-sync система подтянула обновления до состояния Stream. Всё прошло без единой ошибки - ни одного конфликта зависимостей, ни одного сломанного пакета. Перезагрузка, новое ядро, работает. С технической точки зрения переход прозрачный, и это, пожалуй, единственное, что можно назвать простым в этой истории.

Ядро: три обновления за месяц

Вот где начинается интересное. За неполный месяц ядро обновлялось три раза. На CentOS 8 за тот же период - ни одного (там обновления выходят значительно реже и строго по расписанию точечных релизов).

Сами по себе обновления ядра - не проблема. Проблема в том, что каждое обновление ядра на продакшн-сервере это потенциальная перезагрузка, а перезагрузка - это окно простоя. И если у тебя на сервере что-то специфичное: kernel modules из DKMS, OverlayFS для контейнеров, специфичные параметры загрузки - каждое такое обновление требует проверки что всё ещё работает.

На нашем тестовом прокси последствий не было. Но мы специально взяли простую нагрузку.

Пакеты из будущего

Это самое неочевидное наблюдение. Несколько пакетов в Stream уже несут версии, которых нет в CentOS 8.3 - текущем стабильном релизе. Конкретно заметили это на glibc, systemd и парочке python-пакетов: версии в Stream чуть выше, чем в CentOS 8.3, и судя по всему, это уже то, что войдёт в RHEL 8.4 когда он выйдет.

Это именно то, чем Stream является по замыслу - апстрим перед RHEL, preview следующего минорника. Для разработчика, которому важно проверить совместимость с будущей версией RHEL - отличная штука. Для продакшн-сервера, где «обновление glibc» это событие, которое согласовывается на несколько уровнях вверх - не очень.

Репозитории: нет точки фиксации

На CentOS 8 можно было зафиксироваться на конкретном минорном релизе. В репозиториях типа vault.centos.org лежат снапшоты, и при необходимости можно сказать «хочу CentOS 8.2 и не хочу обновляться до 8.3 прямо сейчас». Это важно для сред с жёсткими требованиями к воспроизводимости.

В Stream такого нет. Stream - это rolling. Ты на последнем состоянии апстрима, и никакого «зафиксируй меня на вчера» не существует. Пакет обновился - всё, предыдущей версии в репо уже нет.

Если ваш процесс предполагает «проверить обновление на тестовой среде с теми же пакетами что в проде, потом прокатить на прод» - эта схема с Stream работает значительно хуже, потому что пока вы проверяете, обновление в репо уже могло смениться следующим.

Что с безопасностью

Обновления безопасности в Stream выходят быстрее, чем в CentOS 8 - логично, это часть архитектуры. Но здесь тоже есть нюанс: патч безопасности может идти в одном пакете с функциональными изменениями. В CentOS 8 и RHEL патчи безопасности как правило бэкпортируются в текущую версию пакета - ты получаешь исправление, но не новую функциональность с непредсказуемым поведением. В Stream это разделение менее чёткое.

Что в итоге

После месяца наблюдений картина следующая:

• Модель обновлений принципиально другая. Stream - не «нестабильный CentOS». Он стабильный, но непрерывно движущийся. Это принципиально другая операционная модель по сравнению с тем, к чему привыкли пользователи классического CentOS.
• Для тестовых и dev-окружений - разумный выбор, особенно если нужно проверять совместимость с тем, что войдёт в следующий RHEL.
• Для продакшна с требованиями к стабильности - не то. Три обновления ядра за месяц, пакеты без фиксации версии и отсутствие vault - это характеристики, которые меняют операционную нагрузку на команду.

Параллельно наблюдаем за AlmaLinux, который вышел в бету в феврале - там архитектура классическая: клон RHEL с задержкой. Для клиентских продакшн-мигросред с CentOS 8 это выглядит перспективнее, но стабильного релиза AlmaLinux нет. Rocky Linux тоже в процессе. Дедлайн конца 2021 года давит, а рынок замен без рисков не сложился.

Стенд с Stream оставляем жить - через несколько месяцев будет видно, сколько раз обновится ядро и насколько сильно разойдутся пакеты с тем, что войдёт в финальный RHEL 8.4.