AlmaLinux 8.5 vs Rocky Linux 8.5: выбираем корпоративный стандарт после CentOS 8 EOL

31 декабря 2021 года CentOS 8 официально ушёл в EOL. Для нас это не было неожиданностью - мы начали первую волну миграции ещё в сентябре, и к концу года большая часть серверов уже стояла на Rocky 8.4. Но тогда мы выбирали под давлением дедлайна и конкретного клиента. Сейчас, когда оба дистрибутива дошли до 8.5 и у нас накопилось несколько месяцев реальной эксплуатации, время зафиксировать позицию: что считать корпоративным стандартом на новых проектах.

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

AlmaLinux 8.5 вышел в ноябре 2021, Rocky Linux 8.5 - в декабре. Оба закрывают RHEL 8.5 и несут тот же набор изменений: обновлённый Go 1.17, PHP 8.0 в AppStream, Python 3.9 по умолчанию в ряде окружений, улучшения SELinux-политик. Разница между ними на уровне пакетов по-прежнему минимальна - в этом и состоит их смысл существования.

Интереснее другое: в 8.5 у обоих появился нормальный Secure Boot для кастомных ядер, а AlmaLinux добавил ELevate - инструмент для in-place апгрейда с CentOS 7/8 и Oracle Linux. Rocky в этом плане пока отстаёт, их migrate2rocky умеет только конвертацию с CentOS 8, но не вертикальный апгрейд. Это не приговор, но фиксируем как факт.

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

У нас к этому моменту несколько сред: часть серверов уже на Rocky 8.4 (мигрировали осенью), часть - на AlmaLinux 8.4/8.5 (два клиента выбрали Alma ещё летом по собственным соображениям). Это дало неплохую базу для сравнения в реальных условиях.

Нагрузочные тесты делали на идентичных виртуалках в нашем тестовом контуре: PostgreSQL 14 под pgbench, nginx под wrk, Java-сервис под JMeter. Цифры приводить не будем - они слишком зависят от конфигурации железа и смысла в этом контексте немного. Важнее наблюдение: разница в производительности между Alma 8.5 и Rocky 8.5 в пределах погрешности измерений. Ожидаемо - ядра одинаковые, libc одинаковая, оба строят из тех же SRPM что и RHEL.

Совместимость RPM-пакетов проверяли по нескольким категориям:

• EPEL - работает одинаково на обоих, собирается для el8 без дистрибутивной привязки.
• Сторонние enterprise-репозитории - Zabbix, Grafana, InfluxDB, официальные PostgreSQL-репо. Все явно поддерживают RHEL 8 / el8, что означает работу на обоих дистрибутивах без патчей.
• Проприетарные агенты - DataDog, CloudWatch, несколько вендорских мониторинг-агентов. Здесь небольшой нюанс: часть вендоров пишет «поддерживается на RHEL 8 и CentOS 8», без упоминания Rocky или Alma. На практике всё работает, но техподдержку вендора при проблемах придётся убеждать воспроизвести на RHEL 8.
• Наши Ansible-роли - около восьмидесяти ролей, накопленных за несколько лет. Тестировали на обоих дистрибутивах - разницы нет. Роли написаны под ansible_os_family == 'RedHat' и ansible_distribution_major_version == '8', и оба дистрибутива отвечают ровно так, как ожидается.

Где реальное отличие

Не в пакетах и не в производительности. Отличие в том, что AlmaLinux и Rocky имеют разную организационную структуру, и это влияет на несколько практических вещей.

Скорость выхода обновлений безопасности. В 2021 году AlmaLinux несколько раз выходил с патчами раньше Rocky - разрыв был небольшим, от нескольких часов до пары дней, но был. По нашим наблюдениям за осень это сохраняется. Для большинства задач это несущественно. Для сред с жёсткими SLA по патчингу - стоит мониторить.

Errata и CVE-трекинг. У AlmaLinux errata публикуются в машиночитаемом формате через AlmaLinux Errata, и это подхватывает Zabbix и ряд SIEM-систем напрямую. Rocky тоже ведёт errata, но инфраструктура немного моложе. Кто использует автоматический патч-аудит по CVE через errata-каналы - у Alma это работает чище прямо сейчас.

Сертификация для российских регуляторов. Ни один из них не сертифицирован ФСТЭК. Для КИИ-клиентов это закрывает вопрос: там придётся смотреть на Astra Linux или РЕД ОС. AlmaLinux и Rocky - это история про некритические сервисы или про инфраструктуру, где регуляторная сертификация ОС не требуется формально.

На чём остановились

На AlmaLinux 8.5 как новом стандарте для проектов, где нет принудительного выбора дистрибутива со стороны клиента.

Причины:

• ELevate - возможность in-place апгрейда на будущие минорные версии выглядит ценно. Rocky такого инструмента нет, и неизвестно когда появится.
• Errata-инфраструктура зрелее и лучше интегрируется с нашим стеком мониторинга уязвимостей.
• CloudLinux за спиной - у AlmaLinux есть коммерческий спонсор с многолетним опытом поддержки RHEL-совместимых дистрибутивов. Rocky строит инфраструктуру с нуля, и это видно в скорости реакции на некоторые запросы сообщества.

Это не значит, что Rocky хуже технически. Серверы, которые мы мигрировали на Rocky 8.4 осенью, продолжают работать и мы их не трогаем - сопровождение смешанного парка нас не пугает, и Rocky как выбор вполне жизнеспособен. Просто для новых проектов нужен один стандарт, и мы выбрали.

Посмотрим, как оба проекта поведут себя к лету - к тому моменту накопится больше данных по стабильности патч-цикла и по тому, насколько активно сообщество вокруг Rocky нарастает. Если картина изменится - зафиксируем.