Мы работаем над способом выполнения автоматических обновлений для наших серверов на базе RHEL / RHEL.
Первоначальная идея: Используя Puppet, мы отключаем репозитории по умолчанию и указываем на наши собственные. Затем мы используем ensure => latest для пакетов, которые мы хотим обновлять автоматически.
Проблема: Мы видим, что некоторые службы перезапускаются после обновления (да).
Вопрос: Есть ли у кого-нибудь совет, как лучше автоматизировать обновления Linux и стратегии по смягчению автоматического перезапуска служб? Мы бы предпочли решение, включающее Puppet, но, если нам нужно использовать другую службу, это не помешает.
Возможное решение: Я представил решение, в котором реализовано многое из того, что предлагали @ voretaq7 и @ewwhite. Похоже, я пока иду по этому пути. Если у вас есть другие предложения, прокомментируйте или отправьте ответ.
Ваша общая стратегия обновления верна: у вас есть локальное репо (которое, я полагаю, вы тестируете в среде разработки), и вы обновляете все на основе этого (я полагаю, известного хорошего) репо.
Перезапуск службы неизбежен: если базовый код изменился, вам необходимо перезапустить службу, чтобы это изменение вступило в силу. Невыполнение этого требования может привести к худшим последствиям (несинхронизация кода с общей библиотекой, что приведет к сбою приложения).
В моем окружении я считаю квартальные окна исправлений ежеквартальными "ПЕРЕЗАГРУЗИТЕ ВСЕ!" окна тоже. Преимущество такой политики в том, что вы знать что ваши серверы вернутся к работе после перезапуска, и вы знать они будут работать правильно (потому что вы их регулярно проверяете).
Мой лучший совет - составить график выпусков программного обеспечения (возможно, это означает, что вам придется запускать их «вручную» с помощью марионетки) и сообщать вашим пользователям о запланированном техническом обслуживании / времени простоя.
В качестве альтернативы (или как часть этого) вы можете настроить избыточность в своей среде, чтобы можно было перезапустить несколько компьютеров или служб и по-прежнему предоставлять услуги конечным пользователям. Это может не полностью устранить любые сбои, но может помочь минимизировать их.
Дополнительная избыточность также защищает вас в случае отказов оборудования, которые неизбежны в достаточно длительном масштабе времени.
Обязательно ли возникает проблема с перезапуском службы после обновления пакета? Перед развертыванием протестируйте в небольшом масштабе, чтобы увидеть, есть ли какие-либо проблемы. Недавно у меня возникла неприятная проблема с пакетом rpmforge DenyHosts. Он фактически изменил расположение своей конфигурации и рабочих каталогов между версиями обновления yum. Это совершенно нежелательное поведение. Как правило, в одной и той же версии RHEL не так много проблем, но вы никогда не можете быть уверены в этом, не тестируя и внимательно наблюдая за эффектами.
Другой вариант - выборочно обновлять сервисы. Например, вам всегда нужны самые свежие пакеты? Это возвращает нас к пониманию причин запуска обновлений. Какова настоящая цель?
Преимущество собственного репо в том, что вы можете проводить выпуски или развертывания и управлять расписанием. Что делать, если у вас есть поставщик аппаратного периферийного оборудования или программного обеспечения, которому требуется RHEL 5.6 и который не работает ниже 5.7? Это одно из преимуществ управления собственными пакетами.
@Beaming Mel-Bin
Упрощение устранит необходимость использования ssh для инструментов цикла для запуска / остановки марионетки.
Прежде всего, вам нужно изменить свои манифесты, включив в них переменную с именем «noop», значение которой берется из ENC.
Итак, у вас будет что-то вроде этого в классе:
noop => $noop_status
куда noop_status установлен в вашем ENC. Когда вы устанавливаете значение noop_status к true, манифест будет работать только в режиме ожидания.
Если у вас есть 100 или 1000 хостов, вы можете использовать ENC, например Dashboard или Foreman, который позволяет вам массово изменять параметры для многих хостов, наследуя их на уровне «Hostgroup» или «Domain». Затем вы можете установить значение «false» для небольшого количества тестовых хостов, переопределив значение Hostgroup.
При этом любые изменения применяются только к выбранным хостам.
Изменение одного параметра в центральном расположении может повлиять на любое количество хостов без необходимости включать / выключать марионетку с помощью ssh for loop tools. Вы можете разделить хосты на несколько групп для безопасности / управления.
Также обратите внимание, что вместо жесткого кодирования номеров версий пакетов в манифестах вы можете поместить их в ENC. Как и в предыдущем случае, вы можете выборочно применять изменения и управлять развертыванием.
Если вам нужна большая детализация (и сложность), вы можете даже иметь параметры для каждого класса, например noop_status_apacheClass и так далее.
С этим может быть труднее справиться, если вы include занятия в других классах.
Возможное решение, основанное на ответе @voretaq7:
Номера версий жесткого кода пакетов в puppet проявляет и поддерживает пакеты в нашем собственном репозитории.
Когда нам требуется новая версия пакета для чего-то, что он предлагает (например, улучшения безопасности, функций, требуемых нашими клиентами, и т. Д.), Мы загружаем пакет в репозиторий.
Протестируйте обновленный пакет на тестовом сервере.
После проверки обновления используйте что-нибудь вроде func или pssh выключить puppet агент на пораженных узлах.
Обновите puppet манифестирует, чтобы гарантировать, что новая версия пакета установлена на затронутых узлах.
Наконец, запустите puppet agent --onetime && reboot на сервере с помощью func или pssh
Прокомментируйте и дайте мне знать, если вы заметите какие-либо недостатки в этом решении или что-то, что можно упростить.