В рамках своей работы я управляю несколькими десятками серверов CentOS 5, используя марионетку для основной настройки. Около половины наших серверов имеют стандартные настройки для размещения различных сайтов django, тогда как остальные представляют собой мешанину приложений.
Я постепенно разбираюсь с нашими методами хостинга, и теперь я подошел к вопросу о том, как управлять обновлениями безопасности на уровне ОС. Я опасаюсь, если cron будет выполнять yum -y update но также не хочу вовремя обходить каждый сервер и проверять каждый пакет с доступными обновлениями, так как это займет некоторое время.
Поэтому мне интересно, есть ли какие-либо хорошие ярлыки или рабочие методы, которые минимизируют связанные с этим риски. и минимизировать количество времени, которое мне нужно потратить. Или, говоря другими словами, существуют ли какие-либо инструменты или методы, которые могут автоматизировать большую часть работы, сохраняя при этом контроль.
Шаги, которые я решил до сих пор:
Также обратите внимание, что я изучил плагин безопасности yum но это не работает на CentOS.
Так как же управлять обновлениями значительного числа серверов CentOS, на которых запущен разнородный массив приложений?
В большинстве моих сред это обычно сценарий кикстарта и пост-установки, который позволяет запустить основную систему и обновить ее на данный момент. Обычно у меня есть локальное репо, которое синхронизируется с зеркалом CentOS ежедневно или еженедельно. Я обычно замораживаю пакет ядра на любой текущий момент на момент установки и обновляю пакеты по отдельности или по мере необходимости. Часто на моих серверах есть периферийные устройства, драйверы которых тесно связаны с версиями ядра, так что это необходимо.
CentOS 5 достигла точки, когда в постоянных обновлениях нет необходимости. Но также имейте в виду, что CentOS 5 сворачивается. Скорость обновлений несколько замедлилась, и природа обновлений больше связана с исправлениями ошибок и меньше касается основных функциональных изменений.
Итак, в этом конкретном случае первое, что вы могли бы сделать, это создать локальное зеркало / репозиторий. Используйте существующее управление конфигурацией для управления доступом к сторонним репозиториям. Возможно, запланировать политику обновления критических или общедоступных служб yum (ssh, http, ftp, dovecot и т. Д.). Все остальное потребует тестирования, но у меня такое ощущение, что большинство сред не работают с полностью обновленными / исправленными системами.
Есть много инструментов, которые могут в этом помочь! Это общая система пакетов и то, какие пакеты идут, куда обрабатывает управление конфигурацией. Эти инструменты обычно охватывают не только yum и rpm, но и сэкономят ваше время и предотвратят множество головных болей!
Самый знакомый мне инструмент - это марионетка, которую я использую для управления практически каждой конфигурацией в моей среде. Вот несколько примеров марионеток для управления yum:
http://people.redhat.com/dlutter/puppet-app.html
В настоящее время доступен ряд инструментов управления конфигурацией, у них довольно большие группы пользователей:
Внедрение их в среду добавит годы к вашей жизни. Это уменьшает количество головной боли из-за плохо настроенных систем и позволяет легко обновлять / обновлять. Большинство этих инструментов также могут предоставлять некоторые функции уровня аудита, которые могут значительно сократить время исправления ошибок конфигурации.
Что касается вашего вопроса о тестировании, я использовал промежуточную среду, на которую мы направляем нагрузку некоторых клиентов (обычно это бета-клиенты или небольшая часть производственного трафика). Обычно мы позволяем этому кластеру запускать новый код как минимум от пары дней до недели (в зависимости от серьезности изменения), прежде чем мы развернем его в производственной среде. Обычно я обнаружил, что эта установка работает лучше всего, если вы попытаетесь выяснить, сколько времени уходит на обнаружение большинства ошибок. В часто используемых системах это может занять несколько часов, в большинстве сред, которые я видел, недели достаточно, чтобы обнаружить даже необычные ошибки в промежуточной стадии / контроле качества.
Одна действительно важная часть тестирования - это репликация данных / использования. Вы упомянули, что у вас есть промежуточные версии большей части вашего производственного оборудования. Есть ли у них идентичные копии производственных данных? Можете ли вы воспроизвести любую производственную нагрузку против него? Можете ли вы даже сделать его частью производственного кластера, используя зеркалирование трафика? Обычно это становится прямым компромиссом между количеством ресурсов, которые бизнес готов потратить на тестирование / QA. Чем больше тестов, тем лучше, постарайтесь не ограничивать себя (в разумных пределах) и посмотрите, что будет поддерживать бизнес (а затем найдите способ сделать на 10% больше).