Лучшие практики для автоматических обновлений Linux

Мы работаем над способом автоматического обновления наших серверов на основе RHEL / RHEL.

Начальная идея: используя Puppet, мы отключаем репозитории по умолчанию и указываем на наши собственные. Затем мы используем ensure => latestпакеты, которые мы хотим автоматически обновлять.

Проблема: мы видим, что некоторые службы перезагружаются после обновления (не очень).

Вопрос: Есть ли у кого-нибудь совет о том, как лучше автоматизировать обновления Linux и стратегии по смягчению автоматического перезапуска служб? Мы бы предпочли решение, которое включает в себя Puppet, но, если нам нужно использовать другой сервис, это не нарушает договоренности.

редактировать

Возможное решение: я представил решение, которое реализует многие из предложенных @ voretaq7 и @ewwhite. Похоже, это маршрут, по которому я сейчас иду. Если у вас есть другие предложения, пожалуйста, прокомментируйте или отправьте ответ.

Ваша общая стратегия обновления является разумной: у вас есть локальное репо (которое, как я полагаю, вы тестируете в среде разработчика), и вы обновляете все на основе этого (я полагаю, известного хорошего) репо.

Перезапуск службы неизбежен: если основной код изменился, вам нужно перезапустить службу, чтобы изменения вступили в силу. Невыполнение этого требования может привести к худшим последствиям (не синхронизированный код с общей библиотекой, приводящий к падению приложения).
В моем окружении я считаю квартальные окна исправлений ежеквартальными "ПЕРЕЗАГРУЗИ ВСЕ!" окна тоже. Преимущество такой политики заключается в том, что вы знаете, что ваши серверы будут восстанавливаться после перезагрузки, и вы знаете, что они будут работать правильно (потому что вы регулярно их тестируете).

Мой лучший совет для вас - составить расписание выпусков программного обеспечения (возможно, это означает, что вам придется запускать их «вручную» с помощью puppet), и информировать пользователей о планируемом обслуживании / простоях.
В качестве альтернативы (или как часть этого) вы можете настроить избыточность в своей среде таким образом, чтобы у вас было несколько перезапусков компьютеров или служб, и при этом они могли предоставлять услуги конечным пользователям. Это не может полностью устранить любые сбои, но может помочь минимизировать их.

Добавленная избыточность также защищает вас в случае аппаратных сбоев, которые неизбежны при достаточно длительном масштабе времени.

Обязательно ли проблема с перезапуском службы после обновления пакета? Протестируйте в небольшом масштабе перед развертыванием, чтобы увидеть, есть ли какие-либо проблемы. У меня недавно была ужасная проблема с пакетом rpmforge из DenyHosts . Он фактически изменил расположение своей конфигурации и рабочих каталогов между ревизиями из ням-обновления. Это совершенно нежелательное поведение. Как правило, в одной и той же версии RHEL не так уж много проблем, но вы никогда не сможете быть уверенными без тщательного тестирования и наблюдения за эффектами.

Другим вариантом является выборочное обновление услуг. Например, вам всегда нужны последние пакеты? Это восходит к пониманию ваших причин запуска обновлений. Какова реальная цель?

Преимущество запуска собственного репо заключается в том, что вы можете организовывать релизы или развертывания и управлять расписанием. Что делать, если у вас есть аппаратное периферийное устройство или поставщик программного обеспечения, который требует RHEL 5.6 и сломается ниже 5.7? Это одно из преимуществ управления вашими собственными пакетами.

@ Bee Mel-Bin

Упрощение избавит от необходимости использовать ssh для инструментов цикла, чтобы запустить / остановить кукольный.

Прежде всего вам нужно изменить ваши манифесты, чтобы включить переменную с именем «noop», значение которой получено из ENC.

Таким образом, у вас будет что-то вроде этого в классе:

noop => $noop_status

Где noop_statusустановлено в вашем ENC. Когда вы устанавливаете значение noop_statusв true, манифест будет работать только в режиме noop.

Если у вас есть 100 или 1000 узлов, вы можете использовать ENC, такой как Dashboard или Foreman, который позволяет массово изменять параметры для многих узлов, наследуя их на уровне «Hostgroup» или «Domain». Затем вы можете установить значение «false» для небольшого числа тестовых хостов, переопределяя значение группы хостов.

При этом любые изменения применяются только к выбранным хостам.

Изменение одного параметра в центральном расположении может повлиять на любое количество хостов, без необходимости включать / выключать кукол с помощью ssh для инструментов цикла. Вы можете разделить ваши хосты на несколько групп для обеспечения безопасности / управления.

Также обратите внимание, что вместо жесткого кодирования номеров версий пакетов в манифестах, вы можете поместить их в ENC. Как и выше, вы можете выборочно применять изменения и управлять развертыванием.

Если вы хотите больше детализации (и сложности), вы можете даже иметь параметры для каждого класса, например noop_status_apacheClassи так далее.

Это может быть сложнее, если вы includeзанимаетесь в других классах.

Возможное решение на основе ответа @ voretaq7:

1. Жесткие коды версий пакетов в puppetманифестах и ​​сохраняют пакеты в нашем собственном репозитории.

2. Когда мы требуем, чтобы новая версия пакета выполняла то, что он предлагает (например, улучшения безопасности, функции, требуемые нашими клиентами и т. Д.), Мы загружаем пакет в хранилище.

3. Протестируйте обновленный пакет на тестовом сервере.

4. После тестирования обновления используйте что-то вроде funcили, psshчтобы отключить puppetагент на уязвимых узлах.

5. Обновите puppetманифесты, чтобы убедиться, что новая версия пакета установлена ​​на уязвимых узлах.

6. Наконец, запустите puppet agent --onetime && rebootна сервере, используя funcилиpssh

Пожалуйста, прокомментируйте и дайте мне знать, если вы обнаружите какие-либо недостатки в этом решении или что-нибудь, что может быть упрощено.