CentOS 8 на горизонте: аудит парка перед миграцией и первое знакомство с модульностью AppStream

В мае Red Hat выпустил RHEL 8, и вместе с ним объявил, что CentOS 8 появится осенью. Сроки относительно конкретные, пакет изменений - большой. После того как в 2014-м мы готовились к CentOS 7 - тогда главным сюрпризом был systemd - решили не ждать RC и начать аудит парка заранее.

На managed-инфраструктуре у нас живёт смесь CentOS 6 и CentOS 7. CentOS 6, если кто забыл, уходит в EOL в ноябре 2020-го - это уже скоро. CentOS 7 поживёт до 2024-го, но вопрос о новых инсталляциях встаёт уже сейчас.

Что меняется в восьмёрке

Изменений накопилось прилично. Пробежимся по тому, что уже видно из документации RHEL 8 и публичных бета-сборок.

DNF вместо YUM. Технически yum в RHEL 8 остаётся как симлинк на dnf, так что привычные команды не сломаются. Но под капотом - другой инструмент с другой логикой разрешения зависимостей. Для большинства сценариев прозрачно, но если где-то в плейбуках или скриптах есть прямые вызовы yum с нестандартными флагами - надо проверить.

Python 3 по умолчанию. В RHEL 8 нет симлинка /usr/bin/python - он не указывает ни на что. Есть /usr/bin/python3 и /usr/bin/python2, выбор явный. Это ломает любой скрипт, который начинается с #!/usr/bin/python без указания версии. Таких скриптов в унаследованных окружениях - немало.

AppStream и модульность - это главное, что требует осмысления.

AppStream: что это и почему непривычно

В RHEL/CentOS до восьмёрки всё было просто: есть базовый репозиторий, пакеты в нём обновляются редко и консервативно. Хочешь свежую версию nginx или nodejs - подключай сторонний репозиторий (EPEL, SCL, vendor repo) и молись, чтобы зависимости не конфликтовали.

AppStream меняет эту модель. Теперь репозиторий делится на два слоя:

• BaseOS - ядро системы, glibc, systemd, стандартная база. Обновляется консервативно, как раньше.
• AppStream - приложения и рантаймы в виде модулей. Один модуль может иметь несколько потоков (streams): например, nodejs:10 и nodejs:12 сосуществуют в одном репозитории.

Модуль - это группа пакетов с явной версионной привязкой. Команда dnf module enable nodejs:12 активирует нужный поток, и дальше dnf install nodejs ставит именно его. Без включения модуля dnf install nodejs вообще не найдёт пакет - он есть только через модуль.

На первый взгляд логично. На второй - вопросы начинаются.

Первый: модуль включается на уровне системы, не на уровне пакета. Если включили python36, то python 3.6 получают все. Если нужны разные версии рядом - либо контейнеры, либо придётся изучить как это устроено с профилями.

Второй: в Ansible модуль dnf поддерживает работу с AppStream-модулями начиная с Ansible 2.8. У нас часть клиентов ещё на 2.7. Это не катастрофа, но аудит плейбуков нужен.

Третий: SCL (Software Collections), которые мы использовали для свежих Python и Ruby на CentOS 7, в RHEL 8 официально не поддерживаются. AppStream должен их заменить. Значит, всё что у нас стоит через SCL - кандидат на переезд в AppStream или в контейнер.

Что мы нашли при аудите

Прошлись по серверам под управлением. Картина предсказуемая.

CentOS 6-машины - их немного, но они есть. На них крутятся старые PHP-приложения, пара демонов собственной сборки и один оракуловый клиент, который пересобирать никто не горит желанием. С этими серверами разговор отдельный: до ноября 2020-го придётся либо мигрировать приложения, либо переводить в контейнеры, либо разговаривать с клиентом о рисках работы на EOL-системе.

CentOS 7-машины - основная масса. Здесь ситуация спокойнее по срокам, но поинтереснее по составу. Нашли:

• Пакеты из SCL: python3, ruby24, rh-nginx116 - всё придётся переосмыслить при переходе на 8-ку.
• Несколько плейбуков с yum вместо package - модуль package в Ansible абстрагирует менеджер, yum - нет. На CentOS 8 такой плейбук упадёт или отработает через симлинк, но лучше починить заранее.
• Скрипты с #!/usr/bin/python - два нашли в cron-задачах. Один клиентский, один наш собственный, написанный лет пять назад.
• Кастомные yum.repos.d-файлы с репозиториями, которые могут не иметь RHEL 8-совместимых сборок. Нужно проверять каждый.

Где мы сейчас

Осень - это примерно через два-три месяца. CentOS 8 как релиз появится, скорее всего, вскоре после RHEL 8. У нас нет иллюзий, что мигрировать на него нужно в день релиза - мы так не делаем. Но к тому моменту когда придёт время первой новой инсталляции, хочется понимать что нас ждёт.

Параллельно с аудитом изучаем как AppStream-модульность ведёт себя в реальности - не только по документации. Для этого поднят тестовый стенд на RHEL 8 Beta. Первые наблюдения - модульность работает, но документация отстаёт от реальности: некоторые вещи приходится выяснять опытным путём.

По итогам оформим что-то похожее на то, что делали перед миграцией с HCL1 на HCL2 в Terraform: инвентаризация → список breaking changes → план работ. Пока на стадии инвентаризации.