Найкраща практика автоматизованих оновлень Linux

Ми працюємо над способом автоматичного оновлення наших серверів на базі RHEL / RHEL.

Початкова ідея: За допомогою Puppet ми відключаємо сховища за замовчуванням і вказуємо на власні. Потім ми використовуємо ensure => latestдля пакетів, які хочемо автоматично оновлювати.

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

Питання: Хтось має поради щодо того, як краще автоматизувати оновлення та стратегії Linux щодо пом’якшення автоматичного перезавантаження послуг? Ми вважаємо за краще рішення, яке включає Лялечку, але, якщо нам потрібно скористатися іншою службою, це не є зловмисником угод.

Редагувати

Можливе рішення: я подав рішення, яке реалізує багато з запропонованих @ voretaq7 та @ewwhite. Схоже, це маршрут, яким я зараз проходжу. Якщо у вас є інші пропозиції, будь ласка, прокоментуйте або надішліть відповідь.

Ваша загальна стратегія оновлення є здоровою: у вас локальне репо (яке, я вважаю, ви тестуєте в середовищі розробників), і ви оновлюєте все, що базується на цьому (я вважаю, відоме хороше) репо.

Повторний запуск послуги неминучий: Якщо базовий код змінився, вам потрібно перезапустити службу, щоб ця зміна набула чинності. Якщо цього не зробити, це може призвести до гірших наслідків (запуск коду не синхронізований із спільною бібліотекою, що призводить до збою програми).
В моєму середовищі я вважаю, щоквартальні патч-вікна є щоквартальними "перезавантажте всі речі!" вікна теж. Перевагою такої політики є те, що ви знаєте, що ваші сервери відновляться після перезавантаження, і ви знаєте, що вони працюватимуть належним чином (адже ви регулярно їх тестуєте).

Моя найкраща порада для вас - запланувати випуск програмного забезпечення (можливо, це означає, що вам доведеться запускати їх "вручну" з маріонетками) та консультувати своїх користувачів щодо запланованого обслуговування / простою.
Крім того, (або як частина цього) ви можете налаштувати надмірність у своєму оточенні, щоб ви могли перезапустити кілька машин або служб і все-таки надавати послуги кінцевим користувачам. Це може не повністю усунути будь-які збої, але це може допомогти їх мінімізувати.

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

Чи обов'язково виникає проблема з перезапуском послуги після оновлення пакета? Перевірте в невеликому масштабі перед тим, як розгорнути, щоб перевірити, чи є проблеми. Нещодавно у мене виникли неприємні проблеми з пакетом rpmforge DenyHosts . Він фактично змінив розташування своєї конфігурації та робочих каталогів між ревізіями від yum оновлення. Це абсолютно небажана поведінка. Як правило, в межах однієї редакції RHEL виникає не так багато проблем, але ви ніколи не можете бути впевнені, не тестуючи і уважно спостерігаючи за ефектами.

Інший варіант - вибіркове оновлення послуг. Вам завжди потрібні останні пакети, наприклад? Це повертається до розуміння ваших причин запуску оновлень. Яка реальна мета?

Перевага запуску власного репо полягає в тому, що ви можете проводити поетапні випуски чи випуски та керувати розкладом. Що робити, якщо у вас є апаратний периферійний або постачальник програмного забезпечення, для якого потрібна RHEL 5.6 і вона працює під 5.7? Це одна з переваг управління власними пакетами.

@Beaming Мель-Бін

Спрощення позбавить від необхідності використання ssh для петельних інструментів для запуску / зупинки маріонетки.

Перш за все, вам потрібно буде змінити свої маніфести, щоб включити змінну під назвою "noop", значення якої отримується з ENC.

Тож у класі ви мали б щось подібне:

noop => $noop_status

Де noop_statusвстановлено ваш ENC. Коли ви встановите значення noop_statusдля того true, маніфест буде працювати тільки в режимі Nööp.

Якщо у вас є 100s або 1000s хостів, ви можете використовувати ENC, як Dashboard або Foreman, який дозволяє вам змінювати параметри маси для багатьох хостів, успадковуючи їх на рівні "Hostgroup" або "Domain". Потім ви можете встановити значення "false" для невеликої кількості тестових хостів, переосмисливши значення Hostgroup.

Завдяки цьому будь-які зміни застосовуються лише до вибраних хостів.

Зміна одного параметра в центральному розташуванні може вплинути на будь-яку кількість хостів, без необхідності вмикати / вимикати ляльку за допомогою ssh для інструментів циклу. Ви можете розділити своїх хостів на кілька груп для безпеки / управління.

Також зауважте, що замість жорсткого кодування номерів версій пакету в маніфестах ви можете помістити їх у ENC. І так само, як вище, ви можете вибірково застосовувати зміни та керувати розкрутками.

Якщо ви хочете більше деталізації (і складності), ви навіть можете мати параметри класу, наприклад noop_status_apacheClassтощо.

Це може бути важче керувати, якщо ви includeнавчаєтесь в інших класах.

Можливе рішення на основі відповіді @ voretaq7:

1. Номери версій жорсткого коду в puppetманіфестах і підтримують пакунки у нашому власному сховищі.

2. Коли ми вимагаємо, щоб нова версія пакета робила щось, що він пропонує (наприклад, покращення безпеки, функції, необхідні нашим клієнтам тощо), ми завантажуємо пакунок у сховище.

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

4. Після тестування оновлення використовуйте щось на кшталт funcабо psshвідключіть puppetагент на уражених вузлах.

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

6. Нарешті, запустіть puppet agent --onetime && rebootна сервері за допомогою funcабоpssh

Будь ласка, прокоментуйте і повідомте мене, якщо ви виявите будь-які недоліки в цьому рішенні або що-небудь, що може бути спрощене.