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 единственный вариант, который можно пробовать в реальных условиях.