ADG Оставить заявку
Блог Инфраструктура 5 мин чтения

AlmaLinux 1.0 вышел: переводим первый CentOS 8 без переустановки

AlmaLinux OS 1.0 стабилен. Прогоняем almalinux-deploy.sh на тестовом сервере CentOS 8 и разбираем что скрипт делает, где может споткнуться и что проверять после.

Контекст момента

AlmaLinux OS 1.0 стабильный релиз - бинарно совместимый клон RHEL 8, первый GA без приставки beta

В феврале мы разворачивали AlmaLinux бету на стенде и заключили: пакеты совпадают, SELinux ведёт себя одинаково, но рекомендовать бету клиентам рано. Сегодня CloudLinux объявил AlmaLinux OS 1.0 - первый стабильный релиз без приставки beta. Пора переходить от стендов к делу.

Что изменилось по сравнению с бетой

Если коротко: теперь это GA. Релиз соответствует RHEL 8.3, репозитории подписаны GPG-ключом фонда AlmaLinux, официально заявлена поддержка до 2029 года. Для нас важнее другое - вместе с релизом появился almalinux-deploy.sh, скрипт in-place миграции с CentOS 8 на AlmaLinux прямо на работающей системе без переустановки.

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

Что делает скрипт внутри

Перед запуском мы прочитали almalinux-deploy.sh - это принципиально, прежде чем запускать что-то с правами root на живой системе. Скрипт делает следующее:

  • Проверяет окружение. Смотрит, что запускается именно на CentOS 8, что архитектура x86_64 (или aarch64), что работает из-под root.
  • Устанавливает almalinux-release. Этот пакет тянет GPG-ключи и конфиги репозиториев AlmaLinux вместо CentOS.
  • Удаляет centos-specific пакеты. В первую очередь centos-release, centos-gpg-keys, centos-linux-repos и подобное. Именно в этот момент система перестаёт знать о CentOS.
  • Запускает dnf distro-sync. Это основное действие: синхронизировать все установленные пакеты с тем, что есть в AlmaLinux-репозиториях. По факту - заменить CentOS-сборки на AlmaLinux-сборки там, где пакеты пересобраны, и оставить как есть там, где они идентичны.
  • Проверяет результат. После синхронизации смотрит, не осталось ли пакетов из CentOS-репозиториев.

Всё это логируется, скрипт при любой нетривиальной ошибке останавливается, а не пытается проехать через неё.

Как прошло на практике

Запуск:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
bash almalinux-deploy.sh

Скрипт отработал без ошибок. Основное время ушло на distro-sync - качал и переставлял пакеты. После перезагрузки:

# cat /etc/os-release
NAME="AlmaLinux"
VERSION="8.3 (Purple Manul)"
ID="almalinux"
...

Сервер поднялся, репозиторий работал, всё что было до - осталось на месте. Субъективно: ощущение что переустанавливал систему, но без переустановки.

Где могут быть проблемы

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

Сторонние репозитории и пакеты. Если в системе стоят пакеты из репозиториев, которые знают только centos или rhel как идентификатор платформы - distro-sync их не тронет, они останутся с CentOS-провенансом. Это не катастрофа, но при следующем dnf update они могут вести себя неожиданно. Нужно проверить dnf list --installed и посмотреть, что осталось с отметкой @ не от AlmaLinux-репозиториев.

Агенты и ПО, проверяющие /etc/os-release. Это мы ещё в феврале отмечали: ряд вендорских агентов жёстко смотрит на ID=centos в os-release. На AlmaLinux там будет ID=almalinux. У клиента с этим сервером стоял Zabbix-агент из официального репозитория Zabbix - он нормально переживает смену дистрибутива, потому что ставился не через метапакет привязанный к CentOS. Но если у вас другой вендор - надо проверять.

DKMS и самодельные модули ядра. После distro-sync ядро может обновиться (у нас так и произошло - RHEL 8.3-версия AlmaLinux несла чуть более свежий kernel patch). Если в системе есть DKMS-модули - Virtualbox Guest Additions, специфичные сетевые драйверы - они потребуют пересборки. Скрипт их не трогает, но после перезагрузки на новом ядре они могут не загрузиться.

/etc/yum.repos.d/ с ручными файлами. Скрипт чистит стандартные CentOS-репы, но если там лежат кастомные .repo файлы, ссылающиеся на зеркала CentOS - они останутся и будут ломать dnf после того, как CentOS-зеркала перестанут отвечать (а к концу 2021-го так и будет).

После миграции: что проверить

После перезагрузки пробежались по стандартному чеклисту:

  • rpm -qa | grep centos - убедиться что не осталось centos-пакетов
  • dnf check - нет ли сломанных зависимостей
  • dnf update - система обновляется из AlmaLinux-репозиториев корректно
  • sestatus - SELinux в enforcing, политика та же
  • Запуск основного сервиса и проверка что он функционирует

Всё прошло чисто. Единственный мелкий момент - /etc/motd остался с CentOS-заглушкой, но это косметика.

Что дальше

Один тестовый сервер - это один тестовый сервер. Следующий шаг - аналогичная процедура на чуть более нагруженном стенде, ближе к реальному продакшн-профилю. Хотим посмотреть как ведут себя системы с большим количеством сторонних пакетов и SELinux-политиками под реальной нагрузкой сразу после миграции.

По клиентам в managed-сопровождении пока продолжаем собирать инвентаризацию CentOS 8 машин и оценивать сложность каждого случая. Тех, где окружение простое и предсказуемое - AlmaLinux через almalinux-deploy.sh выглядит рабочим путём. Там, где много кастомного - будем смотреть отдельно.

Rocky Linux ещё в процессе и GA у них нет. Пока AlmaLinux единственный вариант, который можно пробовать в реальных условиях.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.