Якщо ви запускаєте автоматичні оновлення

Я запускаю виробничі веб-сервери Centos. Хочу знати, яка найкраща практика для запуску оновлень. Чи потрібно автоматизувати це за допомогою yum-cron або yum-updatesd? Або існує небезпека порушення сайтів оновлень, тому було б краще оновитись на тестовому сервері, а потім запускати оновлення вручну щотижня?

Більшість серверів використовують лише офіційні сховища, але деякі мають атомне сховище для модулів PHP, які інакше недоступні. Що найкраще в цьому випадку? чи можу я встановити, щоб використовувати лише Atomic для модулів PHP? Я не хочу, щоб все поновлювалось на краєвидних матеріалах в Atomic, я б довіряв скоріше Centos (або насправді Red Hat), щоб мої сервери були стабільними та безпечними.

Існують плюси і мінуси в обох напрямках, і вам дійсно потрібно працювати над архітектурою системи, щоб знати, який спосіб найкраще підходить для вас. Незалежно від маршруту ви повинні зрозуміти, чому ви вибрали цей метод та які недоліки, щоб ви могли їх компенсувати.

Ось деякі речі, які слід врахувати:

• Оновлення безпеки завжди слід застосовувати так чи інакше, і швидше, ніж пізніше. Якщо з вашого сервера з будь-якої причини своєчасно не застосовуються оновлення безпеки, зафіксуйте звички системного адміністратора.

• Оновлення distro зазвичай є хорошими, особливо якщо вони з офіційних джерел. Якщо вам неприємно застосовувати їх, можливо, ви не використовуєте кращий дистрибутив для своїх потреб. Ви повинні використовувати дистрибутив, який відповідає вашій методології. Іншими словами, той, якому ви можете довіряти оновлення, що вам найбільше цікавлять. Якщо вони рухаються занадто швидко або вносять зміни програмного забезпечення, які порушують ваші речі, ви, ймовірно, використовуєте інший дистрибутив.

• Оновлення можуть порушити ваші речі. Перехід на новіше програмне забезпечення може порушити ваш код, якщо ви використовували застарілі функції або просто писали погані речі. Вам слід розглянути архітектуру системи, яка дозволяє протестувати ваш продукт на оновленнях, перш ніж запускати їх у виробничі системи.

• Якщо ви використовуєте функції автоматичного оновлення, у вас завжди повинен бути спосіб повернутися до відомих робочих конфігурацій. Повні знімки системи можуть врятувати життя, якщо якесь оновлення порушує ваш продукт у виробничій системі.

Це не вичерпний перелік, лише кілька речей, щоб задуматися. Зрештою, це не рішення, яке ніхто може прийняти за вас. Ти адміністратор. Знайте свої системи. Знай свою дистрофію.

Я погоджуюся на 100% з тим, що Калеб уже сказав. Ще кілька урізків, що стосуються CentOS, від мене:

Розподіл базується на RedHat та його виправленнях. Ці виправлення перевірені дуже добре, і за останні 4 роки, коли ми використовували CentOS 5 з 50+ серверами, ніколи не було поганого виправлення.

АЛЕ: Хоча ми кожен день автоматично застосовуємо всі виправлення до серверів, які працюють лише з дистрибутивом, ми завантажуємо виробничі сервери (після оновлення glibc або ядра) лише після того, як у нас в цій конфігурації через кілька днів були запущені тестові системи.

Для інших сховищ ми відображаємо їх до каталогу інсценізацій. Ці виправлення спочатку застосовуються до тестових серверів. Якщо буде доведено, що нічого не порушується, ми активуємо каталог постановок і копіюємо його у виробничий сховище.

Автоматичне виправлення має побічний ефект, що часто виправляти патч-компоненти - тому якщо ви неправильно налаштували їх після запуску, то перезапуск буде невдалим.