Первые итоги миграций CentOS 8: три на Alma, одна на Rocky

Когда Rocky Linux вышел в GA 21 июня, мы запустили параллельные миграции для двух клиентов - один на AlmaLinux, второй на Rocky Linux. К этой неделе обе завершены. Вместе с миграциями, которые делали в марте-апреле, итого за первое полугодие у нас четыре в-живую-переведённых окружения: три на AlmaLinux и одно на Rocky Linux. Самое время зафиксировать, что реально вышло - без стендов, на клиентском железе.

Как это выглядело в сумме

Три AlmaLinux-миграции шли через almalinux-deploy.sh, одна Rocky-миграция - через migrate2rocky.sh. Профили серверов разные: внутренние репозитории пакетов, CI-раннеры, один сервер мониторинга и один с ролью файлового хранилища, подключённого к внешней СХД по iSCSI.

По итогам: все четыре системы после миграции поднялись, основные сервисы заработали. Но «без проблем» это не назвать - в трёх из четырёх случаев что-то требовало ручного вмешательства.

Что работает хорошо

Сам скрипт миграции. И almalinux-deploy.sh, и migrate2rocky.sh написаны аккуратно - с проверками на каждом шаге и остановкой при ошибке. Ни разу не получили ситуацию «скрипт прошёл, система сломана». Если скрипт останавливается - он говорит где и почему. Это важно: на живом сервере клиента хочется именно такого поведения, а не тихого проезда через ошибку.

SELinux. Во всех четырёх случаях политики перенеслись без нареканий. Enforcing остался enforcing, типы контекстов совпали, AVC-дёрганий после перезагрузки не было. Это приятный сюрприз - SELinux-конфигурация на CentOS 8 и на AlmaLinux/Rocky идентична по существу, и скрипты это корректно сохраняют.

Базовые системные сервисы. systemd, rsyslog, crond, sshd - всё поднялось штатно. Никакой постмиграционной магии с юнитами не потребовалось.

Где были проблемы

Сторонние репозитории - главная точка боли. Это мы предупреждали ещё в марте, но теперь есть конкретика. На двух серверах стояли пакеты из Remi и EPEL. После миграции dnf update на одном из них выдал конфликт: Remi-репозиторий определял платформу по ID=centos в /etc/os-release, не находил его, и часть пакетов оказывалась в подвешенном состоянии - формально установлена, но репозиторий её не видит как «свою».

Решение стандартное: зайти на сайт Remi, проверить что есть отдельные .repo-файлы для AlmaLinux/Rocky (они есть), поставить нужный remi-release пакет под новый дистрибутив, прогнать dnf distro-sync повторно. Не катастрофа, но неожиданностью это не должно быть - нужно проверять до миграции, какие сторонние репозитории стоят и есть ли у них поддержка нового дистрибутива.

EPEL вёл себя лучше - там ID_LIKE в os-release у обоих дистрибутивов содержит rhel и centos, и EPEL это подхватывает. Но и тут лучше проверять явно, а не рассчитывать что само разберётся.

Ядерные модули и СХД - отдельная история. Сервер с iSCSI-подключением к внешней СХД преподнёс подарок. После миграции и перезагрузки хранилище не поднялось: модуль ядра для multipath-устройств пересобрался некорректно. Корень проблемы простой - при distro-sync ядро обновилось (AlmaLinux нёс более свежий патч-уровень, чем был на CentOS 8), а DKMS-модуль под новое ядро не пересобрался автоматически.

Потребовалось: ребут в старое ядро через GRUB, ручная пересборка модуля через DKMS, проверка что multipath видит устройства, ребут в новое ядро. В итоге полчаса вместо пяти минут, и ещё минут двадцать нервов у клиента пока разбирались что происходит.

Вывод простой: если на сервере есть DKMS-модули (драйверы СХД, сетевые карты с проприетарными драйверами, что угодно) - это нужно проверять до миграции и явно планировать пересборку после.

Сравнение AlmaLinux и Rocky по ощущениям

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

migrate2rocky.sh чуть более многословен в выводе, чем almalinux-deploy.sh - логирует чуть больше шагов. Это мелочь, но при отладке приятно. По результату миграции разницы нет: та же логика переключения репозиториев, тот же dnf distro-sync, тот же итоговый набор пакетов.

Rocky 8.4 стартовал с базой RHEL 8.4, тогда как наши AlmaLinux-серверы поднимались ещё на 8.3. Это означает, что на Rocky-сервере dnf distro-sync дополнительно подтянул изменения с 8.3 до 8.4. Прошло без проблем, но это нужно учитывать при планировании окон обслуживания.

Что добавили в чеклист

По итогам четырёх миграций у нас появилось несколько пунктов, которых раньше в чеклисте не было:

• Инвентаризация сторонних репозиториев до старта. dnf repolist и dnf list installed | grep -v @ - смотреть что установлено не из базовых репозиториев.
• Проверка DKMS-модулей. dkms status перед миграцией. Если есть что-то кроме стандартных - планировать пересборку отдельно.
• Проверка /etc/yum.repos.d/ на кастомные .repo-файлы. Скрипт чистит стандартные CentOS-репы, кастомные остаются.
• Явная проверка Remi и аналогов. Для каждого стороннего репозитория - убедиться что есть версия под AlmaLinux/Rocky перед миграцией, а не после.

Что дальше

Основная волна CentOS 8 EOL - конец года. У нас ещё несколько клиентов в очереди. У части из них окружения попроще - там по той же схеме. У двух клиентов есть специфика: проприетарные агенты мониторинга, которые жёстко проверяют дистрибутив по os-release, и именно с ними предстоит разговор с вендором об официальной поддержке AlmaLinux/Rocky.

По клиентам в managed-сопровождении продолжаем вести миграции. Инструменты работают, практика накапливается. Главное - не считать это «нажал кнопку и готово». Нажал кнопку, потом полчаса проверяешь всё что может пойти не так.