80+ серверов с CentOS 6: составляем дорожную карту миграции на CentOS 8
После выхода CentOS 8 начали планировать миграцию парка CentOS 6 и CentOS 7. Главная боль - Python 2-зависимости и старые RPM-репозитории без пакетов для восьмёрки.
С выходом CentOS 8 организации планируют миграцию с CentOS 7 (поддержка до 2024) и CentOS 6 (EOL ноябрь 2020)
CentOS 8 вышел неделю назад, и у нас теперь есть живой дистрибутив вместо бета-сборок и release notes. В июле делали аудит парка и составляли первые впечатления. На прошлой неделе гоняли тестовый стенд и смотрели как ведёт себя AppStream в реальности. Теперь пришло время честно ответить на вопрос: как нам мигрировать 80+ серверов, часть из которых на CentOS 6, и не сломать при этом то, что работает.
Результат - не готовый план миграции, а скорее дорожная карта с белыми пятнами. Вот что мы знаем, что нет, и где больше всего вопросов.
Инвентаризация: что у нас есть
Прошлись по managed-парку и разложили серверы по трём корзинам.
CentOS 6 - меньшая часть, но самая горящая. Ноябрь 2020-го - EOL. Это 14 месяцев. На этих машинах живут: несколько PHP 5.x-приложений, один демон собственной сборки с зависимостью от Python 2.6, пара MySQL 5.1 (да, мы тоже удивляемся), и упомянутый уже в прошлых постах оракуловый клиент, который никто не торопится пересобирать. In-place апгрейд с шестёрки до восьмёрки не поддерживается - только чистая установка. Это означает: разворачиваем новые машины, переносим данные, переключаем трафик.
CentOS 7 - основная масса. До 2024-го времени формально достаточно, но для новых инсталляций уже начали использовать восьмёрку. Старые серверы так и будут жить на семёрке - трогать их будем при плановых работах или когда накопится достаточно поводов. In-place апгрейд через leapp теоретически возможен, но мы его тестировали на стенде - не всё гладко.
CentOS 8 - несколько новых серверов, развёрнутых с нуля за последнюю неделю после релиза. Здесь всё ожидаемо.
Две главные проблемы
Оба вопроса мы ожидали, но реальный масштаб понял только после аудита.
Python 2 - глубже, чем казалось. На CentOS 6-машинах Python 2.6 - это системный Python, и вокруг него накопилось: cron-скрипты, мониторинговые агенты, Fabric-деплои, один самописный парсер логов. Часть скриптов написана с #!/usr/bin/python без явной версии. На CentOS 8 этого симлинка нет. Формально можно поставить python2-пакет из AppStream, но тогда мы просто переносим проблему: Python 2 без обновлений безопасности на новой системе - не решение.
Реальная работа - переписать или заменить каждый скрипт. Это не один день. На некоторые из них смотреть страшно: автор уволился, документации нет, тесты отсутствуют. Будем работать в связке с командами заказчиков.
Сторонние RPM-репозитории - это отдельная история. За годы работы с CentOS 6/7 накопились кастомные .repo-файлы от вендоров: мониторинговые агенты, специфичные версии nginx, драйверы сетевых карт, криптографические библиотеки. Прошлись по каждому - картина смешанная.
Часть репозиториев уже имеет пакеты для RHEL 8: Percona, Elastic, Zabbix-агент. Другие - только объявили о планах или молчат. Один вендор на прямой вопрос о поддержке CentOS 8 ответил «работаем над этим» без сроков. Там у заказчика специфичная железка с проприетарным драйвером - придётся ждать или искать альтернативу.
Что с leapp на CentOS 7
Leapp - инструмент от Red Hat для in-place апгрейда с RHEL 7 до RHEL 8. Для CentOS адаптирован community. На нашем стенде запустили на двух тестовых машинах - чистой семёрке и более «населённой» с несколькими сервисами.
На чистой машине leapp отработал без сюрпризов. На «населённой» выдал список inhibitors - блокировок, которые надо разобрать до апгрейда. Больше всего блокировок - от тех же сторонних репозиториев и Python 2-пакетов. Хорошая новость: leapp честно показывает что сломается до того как что-то трогает. Плохая: список на реальных серверах будет длиннее, чем на тестовом стенде.
Пока решение по leapp не принято. На ряде серверов in-place апгрейд может быть быстрее чем поднять новую машину и перенести данные. На других - предпочтём чистую инсталляцию.
Дорожная карта по приоритетам
Разложили серверы по волнам.
Волна 1 - CentOS 6, срочные. Машины с понятным составом сервисов и без сложных зависимостей. Разворачиваем новые серверы на CentOS 8, переносим конфиги и данные, переключаем. Цель: закрыть до конца года, не ждать следующего лета.
Волна 2 - CentOS 6, сложные. Серверы с Python 2-зависимостями и «живыми» проприетарными компонентами. Здесь сначала работа с кодом, потом переезд. Параллельно - переговоры с вендорами по поддержке CentOS 8.
Волна 3 - CentOS 7. Плановая миграция по мере плановых работ или появления потребности в возможностях восьмёрки. Не горит, но держим в уме.
Где мы сейчас
План набросан, приоритеты расставлены, белые пятна обозначены. Волна 1 стартует на этой неделе - с самого простого сервера. Это не героизм, это разумный подход: отработать процесс на малом, прежде чем идти в сложное.
Главный урок из аудита - миграция CentOS 6 это не технический вопрос «как поднять CentOS 8», это в значительной мере вопрос «кто и когда разберётся с Python 2-скриптами» и «когда вендор X выпустит пакеты для восьмёрки». Инфраструктурная часть, честно говоря, проще.