CentOS 4.2 и yum cron: раскатываем патчи на двадцати серверах без ручного захода

В феврале вышел CentOS 4.2 - очередной point release с накопленными backport-патчами безопасности от Red Hat. Само по себе событие рутинное, но оно стало хорошим поводом наконец разобраться с тем, что нас давно беспокоило: у нас под управлением около двадцати Linux-серверов, и каждый раз накатывать обновления руками - это просто теряемые часы.

Осенью мы уже настраивали автоматические обновления для небольшого Linux-парка - запись об этом есть в блоге. Но тогда речь шла о нескольких машинах и довольно простой схеме: обновляй ночью, присылай отчёт. На двадцати серверах с разными ролями такой подход начинает нервировать. Один неудачный патч к ядру или к openssl - и здравствуй, ручной обход стойки.

Что изменили

Решили построить нормальный конвейер: три окружения с задержкой между ними.

Тестовый стенд. Это несколько виртуалок с конфигурациями, близкими к боевым - разные роли: веб, база, dns, почта. Сюда новые пакеты из репозитория попадают сразу после того, как CentOS зеркало их публикует. Yum cron запускается ночью, утром смотрим что прилетело, проверяем что сервисы живы. Два-три дня наблюдения.

Препрод. Группа серверов, которые обслуживают не критичные боевые нагрузки или используются для тестирования клиентских сценариев. Они получают обновления через 24 часа после того, как те прошли на тестовом стенде без инцидентов. Здесь уже есть реальная нагрузка, и если что-то сломается - видно сразу, но последствия управляемые.

Прод. Основной парк. Задержка относительно тестового стенда - 48 часов. Автоматически обновляются только пакеты из категории security. Всё, что помечено как bugfix или enhancement, идёт в ручной режим - смотрим по ситуации.

Схему можно нарисовать так:

CentOS mirror
      |
   [test]  -- ночь --> проверка руками
      |
  +48h -> [preprod] -- мониторинг 24h
      |
  +48h -> [prod]   -- только security

Никаких экзотических инструментов - просто yum cron с разными конфигами и внутреннее зеркало репозитория, которое мы подняли ещё раньше. Зеркало даёт один источник истины: все три окружения тянут пакеты с него, а не с публичных зеркал CentOS напрямую. Заодно это снижает зависимость от доступности внешних серверов.

Что пришлось решить

Несколько неочевидных моментов, которые выяснились в процессе.

Заголовки yum.conf. У каждой группы серверов - свой yum.conf с отдельным baseurl, указывающим на соответствующий подкаталог зеркала. Зеркало организовано так, что пакеты сначала попадают в incoming, потом через скрипт перекладываются в test, через сутки - в preprod, ещё через сутки - в prod. Это несложно, но надо было один раз сесть и написать.

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

Уведомления. Yum cron умеет слать почту с результатом - включили. На тестовом стенде письмо приходит с полным списком установленного. На проде - только если что-то пошло не так (ошибка установки, недоступность репозитория). Иначе почту можно перестать читать уже через неделю.

Блокировки пакетов. Для нескольких серверов есть пакеты, которые трогать нельзя - специфические версии PHP или mysql-libs, которые клиент зафиксировал под конкретное приложение. Для них в yum.conf прописан exclude. Про эти исключения пришлось завести отдельный список в документации - иначе через три месяца никто не вспомнит, почему на этом сервере mysql не обновляется.

Первый прогон с CentOS 4.2

С выходом 4.3 конвейер прошёл первый нормальный прогон. Тест получил пакеты и обновился сам - утром посмотрели отчёт, всё чисто. Через двое суток прод получил то же самое. Руками никуда не заходили.

Для нас это принципиальная разница - раньше двадцать серверов означали двадцать SSH-сессий. Теперь это утренний просмотр одного письма. Пока схема отработала один раз, делать далеко идущие выводы рано. Но первое впечатление - именно так оно и должно работать.

Для клиентов, где мы ведём управляемую инфраструктуру, это меняет SLA на патч-менеджмент: критические CVE теперь закрываются предсказуемо, без зависимости от того, есть ли у инженера свободное окно на этой неделе.