Rocky Linux 8.4 в продакшне: первая волна миграции 30 серверов CentOS 8

Rocky Linux 8.4 официально объявлен production-ready - команда RESF завершила полный цикл тестирования совместимости с RHEL 8.4, включая бинарную совместимость пакетов и ABI. Для нас это не просто новость из RSS: примерно в этот момент мы закрыли первую волну миграции у производственного клиента - порядка тридцати серверов CentOS 8.

CentOS 8 уходит в EOL в конце декабря 2021. У клиента - несколько десятков серверов смешанного профиля: веб, БД, мониторинг, вспомогательные сервисы. Откладывать смысла не было, а после июльского пилота на параллельных стендах решение было принято в пользу Rocky - в основном по политическим соображениям клиента, не техническим.

Инструмент: migrate2rocky

Официальный скрипт migrate2rocky.sh от RESF делает in-place конвертацию: меняет репозитории, GPG-ключи, заменяет специфичные пакеты дистрибутива и перегружает систему на новое ядро. Всё это без переустановки.

Схема использования минимальная:

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
bash migrate2rocky.sh -r

Флаг -r означает «переключи на Rocky». После завершения скрипта и перезагрузки cat /etc/redhat-release должен показывать Rocky Linux release 8.4. На большинстве серверов так и было. На меньшинстве - пришлось разбираться.

Подводные камни: что встретили вживую

Мы прошли через несколько категорий проблем - перечислим то, что потребовало реального времени, а не то, что описано в README.

Сторонние репозитории с жёсткой привязкой к CentOS. Несколько серверов имели настроенные .repo-файлы с $releasever или явной строкой /centos/8/ в baseurl. После смены дистрибутива эти репозитории начинали 404-ить или вообще отказывались работать. Решение - перед миграцией проверить все /etc/yum.repos.d/*.repo и заменить CentOS-специфичные пути на нейтральные или Rocky-совместимые.

Zabbix-агент с пакетом из CentOS-репозитория Zabbix. Официальный репо Zabbix поддерживает RHEL-based дистрибутивы корректно, но на нескольких серверах был поднят старый способ установки через отдельный CentOS-таргетированный пакет. Мигратор его не тронул, но после перезагрузки zabbix-agent зачем-то не хотел стартовать. После переустановки через актуальный Zabbix repo всё заработало.

SELinux и кастомные политики. На двух серверах были самописные .te-файлы - локальные SELinux-политики. Сами модули пережили миграцию, но на одном сервере после обновления ядра контекст файлов на нестандартных путях съехал. Команда restorecon -Rv /opt/app решила проблему, но без понимания что произошло можно потратить час на поиск «почему приложение не стартует».

Пакеты, установленные вручную с --nodeps. Редкость, но встречается: кто-то когда-то поставил rpm без проверки зависимостей. Мигратор в таких случаях мог либо зависнуть на этапе разрешения конфликтов, либо оставить систему в полумигрированном состоянии. Проверять заранее: rpm -Va 2>/dev/null | grep "^..5" - покажет файлы с неожиданными изменениями.

Ядро от CentOS оставалось в grub. Сам скрипт не удаляет старые ядра. После миграции в grub2-editenv list видно, что загрузился Rocky-kernel, но CentOS-ядро в меню висит. Не критично, но вводит в ступор при следующем просмотре: rpm -qa | grep kernel возвращает несколько версий. Старое ядро убирается через dnf remove kernel-<старая версия>.

Сертификаты CA из пакета ca-certificates. На CentOS и Rocky этот пакет разный по списку bundle. В нескольких приложениях с корпоративными CA пришлось после миграции пересобрать доверенное хранилище через update-ca-trust.

Что сделали для автоматизации

Прогнать тридцать серверов по одному вручную - неразумно. Мы выкатывали через Ansible с простой структурой: pre-check playbook, затем вызов migrate2rocky.sh, затем post-check.

Pre-check проверял:

• наличие подозрительных .repo-файлов
• пакеты без правильного RPM-источника
• свободное место (скрипту нужно место под временные rpm)
• версию CentOS (только 8.x, не 7)

Post-check проверял:

• cat /etc/redhat-release
• статус основных сервисов клиента
• наличие /etc/yum.repos.d/Rocky*.repo
• доступность репозитория командой dnf repolist

Серверы, прошедшие оба чека без алертов, считались мигрированными. Те, что упали на post-check, шли на ручной разбор.

Итог первой волны

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

Rocky 8.4 на этих серверах ведёт себя как ожидалось - то есть практически неотличимо от RHEL 8.4. Никаких сюрпризов в поведении сервисов, SELinux-политики штатные работают, EPEL подключился без вопросов.

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