Чи здатні засоби управління конфігурацією (Puppet, Chef) постійно оновлювати встановлені пакети?

Це, мабуть, просте питання для тих, хто вже працює з інструментами управління конфігурацією. Чи є інструменти управління конфігурацією, такі як Puppet або Chef, правильний підхід для оновлення встановлених пакетів?

Припустимо, я запускаю ряд серверів, в основному на базі Debian і Ubuntu. Чи полегшують інструменти управління конфігурацією оновлення пакетів, встановлених із сховищ, коли з'являються оновлення безпеки або виправлення помилок?

Зараз я запускаю "без нагляду оновлення", щоб дозволити системам автоматично встановлювати оновлення безпеки, але мені все одно доводиться підключатися до серверів і запускатись aptitude update && aptitude safe-upgradeтак часто. Звичайно, це стає нудно, нудно і схильність до помилок тим більше серверів.

Чи є інструменти, такі як Лялька чи шеф-кухар, правильний підхід до оновлення встановлених пакетів? Чи використовує хтось із вас ці інструменти, щоб уникнути запуску вручну aptitudeабо іншого еквівалента на 15 серверах? Я цілком певний, що відповідь на ці запитання: "Так, звичайно!"

Але де я можу знайти більше інформації про цей конкретний випадок використання? Я ще не встиг поглиблено вивчити лялькових чи шеф-кухарів, а приклади кулінарних книг чи класів лише показують більш-менш тривіальні приклади встановлення одного конкретного пакету, наприклад ssh. Чи є у вас які-небудь ресурси, які рекомендують, крім офіційної документації (я, звичайно, збираюся вивчати документи, коли я знаю, який, якщо такий, інструменти мені підходить).

Лялька (я впевнений, що шеф-кухар теж працює) зв'язується з вашими сховищами програм apt-get / yum . Оскільки вони роблять важке підрахунок того, які пакети доступні, це означає, що це ensure => latestпросто працює для Ubuntu / CentOS / Debian тощо. Поки ви правильно налаштували відповідні файли ( /etc/apt/sources.listтощо).

Ви можете це робити з лялькою, або:

ensure => latest,

або

ensure=> "1.0.2",

щоб вказати останню / потрібну версію. тобто

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

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

Запуск без нагляду оновлень трохи мене лякає, особливо якщо вони оновлюють критичні для місії пакети, ядра, бібліотеки mysql, apache тощо. Особливо, якщо сценарій установки може захотіти перезапустити службу!

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

Я це роблю, щоб підтримувати виділений репортаж Yum (для Redhat / Fedora / CentOS; сховище APT для Debian / Ubuntu), який містить пакети, які мені важливі для певного сайту. Це, як правило, залежність самого додатка (Ruby, PHP, Apache, Nginx, бібліотеки тощо) та критично важливих для безпеки пакетів.

Після цього налаштування (як правило, ви можете просто відобразити потрібні пакети з репо-версії для початку), ви можете використовувати синтаксис Putpet "забезпечити => останній", щоб переконатися, що всі ваші машини будуть в курсі репо.

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

Автоматизація версій пакунків настійно спонукає вас привести всі ваші виробничі системи в синхронізацію, оскільки підтримка декількох репостів і пакетів для різних дистрибутивів, версій та архітектур ОС дуже забирає багато часу і може призвести до різного роду незрозумілих проблем і несумісностей.

Всі ці поради однаковою мірою стосуються дорогоцінних каменів Ruby, яєць Python та інших пакетних систем, які ви можете використовувати.

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

Хоча Лялька / шеф-кухар є можливими претендентами на цю функціональність, для того, щоб вони постійно оновлювали все в системі, потрібні або спеціальні типи, або перелік кожного пакета (включаючи базові системні бібліотеки, такі як libc6), як ресурси ensure => latest. У конкретному випадку автоматизованих оновлень пакунків ви можете заглянути в cron-aptпакет, який також виконує те, що ви хочете.

Це питання давнє, але я думав, що відповів би актуально, оскільки наявна відповідь тоді була недоступною.

Якщо ви використовуєте лялечку чи шеф-кухаря, загляньте в колектив. Це дуже приємний інструмент хлопців-лялечок, який дозволяє надсилати команди групам серверів. http://docs.puppetlabs.com/mcollective/

Він також має підходящий плагін, який можна використовувати для оновлення apt на будь-якій кількості серверів: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Я усвідомлюю, що це трохи пізно для вашого початкового питання, але тут це в дусі "краще пізно, ніж ніколи".

Я використовую Cfengine 3 для цього на декількох серверах. Я вказую явний перелік пакунків для автоматичного оновлення, уникаючи таким чином оновлення всіх пакетів, не будучи при цьому трохи уважним. Він чудово працює, а cfengine 3 дуже легкий.

Ось фрагмент обіцянки з моєї конфігурації cfengine:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

Сподіваюся, це допомагає.

Я погоджуюся з Джонатаном. Підхід Cfengine 3 приємний тим, що ви можете контролювати всі аспекти управління пакунками без необхідності перекодувати на низькому рівні.

Ми використовуємо лялечку + apt-датер.

Ви також можете використовувати засоби управління пакетами, такі як Canonicals Landscape, який призначений для управління та моніторингу систем Ubuntu / Debian. Він управляє декількома системами, дозволяє оновлювати їх одночасно і надає деякі основні можливості моніторингу.

Оновлення безпеки

Як правило, я вважаю, що найпростіше використовувати Ansible або подібне, щоб налаштувати надійний пакет без нагляду оновлень для Ubuntu / Debian (або yum-cronдля RHEL / CentOS). Ви можете використовувати лялечку, шеф-кухаря або інші інструменти, але я обговорю тут.

• unattended-upgrades можна використовувати для одночасного оновлення безпеки, якщо ви хочете, що набагато простіше, ніж щодня виконувати команду через Ansible.

• unattended-upgradesщодня доглядає за автоматичними оновленнями і зазвичай обмежується лише оновленнями безпеки (для підвищення стабільності). Якщо сервер потребує перезавантаження після оновлення, цей інструмент може автоматично перезавантажитися в певний час.

Якщо ваші перезавантаження є складнішими, вони unattended upgradesможуть надіслати вам електронну пошту, а також створити /var/run/reboot-requiredтак, щоб Ansible (або подібні) могли керувати перезавантаженнями у відповідний час (наприклад, прокатка перезавантажень кластеру веб-серверів або серверів БД, щоб уникнути простоїв, чекаючи кожного щоб сервер став доступним на певному порті TCP перед продовженням).

Ви можете використовувати ролі Ansible, такі як jnv.unattended-модернізації для систем Ubuntu / Debian, або простий, але ефективний geerlingguy.security , який також охоплює RHEL / CentOS (і затверджує конфігурацію SSH).

Якщо швидкі оновлення безпеки є менш важливими, ви можете спершу пройти тестовий процес на менш важливих серверах і запустити unattended-upgradeкоманду, як тільки тести покажуть, що проблем немає - однак, в моїх випадках виправлення безпеки, орієнтовані на сервер, доволі рідко. досвід.

Загальні оновлення

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

У минулому я бачив, що aptitude safe-upgradeвикликає серйозні проблеми на серверах, тому краще не запускати це автоматично, тоді як оновлення безпеки, як правило, досить безпечні.