Налаштування серверів через Puppet: керування конфігурацією під ключ

Puppet керування конфігурацією: де ламається ручне налаштування

Агент Puppet через заданий інтервал отримує від сервера каталог — опис того, яким вузол має бути: пакети, вміст файлів, власники й права, запущені служби, правила фільтрації. Усе, що не описано в маніфестах, для системи або невидиме, або позначається як зайве й видаляється.

Тут і починається дрейф конфігурацій: правка, зроблена руками на живому сервері, живе рівно до наступного запуску агента.

Інженер гасить аварію вночі: піднімає ліміт з’єднань у конфізі, дописує завдання в розклад, змінює шлях до сертифіката. Сервіс відповідає, завдання закрито, в маніфести не потрапило нічого — доступу до репозиторію під рукою не було.

Через кілька годин агент приводить файл до еталона й повертає відмову, але про причину тепер пам’ятає тільки листування в чаті.

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

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

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

Нижче розбираємо, як дрейф закривається: єдині маніфести на всі контури, контроль фактичного стану вузлів, звіти агента про розбіжності та порядок, за якого ручна правка стає винятком, а не нормою.

Що дає єдине джерело правди для парку серверів

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

Фактичний стан машини звіряється з описом під час кожного запуску, і розбіжність усувається автоматично.

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

Частка ручних операцій скорочується до поодиноких — типові зміни, як-от облікові записи, сертифікати або параметри служб, розсилаються одним застосуванням на весь парк.

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

Стійкість до відмов зростає окремо: вузол можна перестворити з нуля й отримати рівно ту саму конфігурацію, що була до збою.

Ми налаштовуємо керування конфігурацією через Puppet: опис стану живе в системі контролю версій, кожна зміна проходить погодження, а звіти про застосування дають аудит — хто, коли і що змінив на конкретній машині.

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

Способи опису стану серверів: порівняння підходів

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

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

Puppet закриває всі робочі режими, тому питання не «що взяти взагалі», а «що взяти для конкретного парку». Нижче — варіанти, між якими реально обирають.

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

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

Етапи впровадження: від аудиту парку до передачі в експлуатацію

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

1. Аудит парку серверів. Збираємо список вузлів, операційні системи, версії пакетів, відкриті порти й фактично запущені служби. На виході — карта розбіжностей між тим, що має бути, і тим, що є.
2. Інвентаризація стану. Фіксуємо конфігураційні файли, залежності між сервісами та «ручні» правки, які хтось вносив напряму. Це вихідна точка для опису бажаного стану.
3. Схема ролей і модулів. Розкладаємо конфігурацію на ролі — балансувальник, застосунок, база, кеш — і профілі всередині них. Вузол отримує роль цілком, модулі перевикористовуються, дублювання виключено.
4. Налаштування керівного контуру. Розгортаємо сервер керування Puppet, налаштовуємо видачу сертифікатів, шифрування даних і журналювання. Кожне застосування пишеться у звіт: видно, хто, коли і що змінив.
5. Тестовий контур. Стенд повторює бойовий за складом ролей. Спочатку прогін без застосування змін, потім із застосуванням — ловимо конфлікти й перевіряємо, що повторний запуск нічого не змінює.
6. Пілот на обмеженій групі. Виводимо кілька вузлів, заміряємо час застосування й поведінку сервісів під час перезапуску, відпрацьовуємо сценарій відкату до попередньої ревізії.
7. Передача в експлуатацію. Розширюємо хвилями за групами з контролем розбіжностей, після чого віддаємо команді документацію за ролями, регламент підключення нових вузлів, доступи й порядок оновлення модулів.

Артефакти впровадження: модулі, ролі, регламенти, звіти

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

• Модулі та ролі — дерево модулів Puppet розкладено за призначенням: загальносистемні налаштування, веб-шар, бази даних, моніторинг. Ролі збирають із них готові типи серверів.
• Маніфести й шаблони — декларативний опис стану з параметрами замість вписаних значень. Новий вузол піднімається зміною змінної, а не правкою коду.
• Документація по парку серверів — перелік вузлів із ролями, змінними та залежностями: видно, яка правка яку групу машин зачепить.
• Регламент змін — як правка потрапляє в основну гілку, хто її перевіряє і в якому порядку вона йде на тестовий контур, а потім на продакшн.
• Порядок відкату — які версії конфігурації зберігаються, як повернути попередній стан групі вузлів і що робити, якщо сервер розійшовся з описом.
• Звіти про стан — регулярний зведення: скільки вузлів у цільовому стані, які зміни застосувалися, де розбіжності та помилки.
• Інструкція з експлуатації — типові операції: додати вузол, змінити змінну, вивести сервер із ролі.

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

Кейс: як пішов клас відмов через розбіжності між середовищами

Вихідна точка

Парк із кількох десятків вузлів обслуговували вручну: налаштування переносили за чек-листами, частину правок вносили прямо в робочому контурі. Аудит показав розбіжності між середовищами більш ніж за тридцятьма позиціями — версії пакетів, параметри служб, права на каталоги.

Відновлення вузла, що впав, займало від трьох до п’яти годин, і результат щоразу трохи відрізнявся від сусіднього сервера того самого призначення.

Описали стан у Puppet: для кожного типу вузлів з’явилася роль, набір модулів і окремий шар даних під середовище. Загальні правила винесли нагору, а відмінності тесту й робочого контуру залишилися тільки в значеннях параметрів — код конфігурації став єдиним для всього парку.

Що показали метрики

• Час відновлення вузла — з 3–5 годин до 15–20 хвилин: вузол піднімається застосуванням ролі, ручних кроків не залишилося.
• Частка автоматизованих налаштувань — з 55% до 99%; залишок — це ліцензії та дані, які свідомо не тримаємо в репозиторії.
• Розбіжності між тестовим і робочим контуром — з понад тридцяти позицій до нуля; відхилення тепер ловить перевірка перед викочуванням, а не черговий після інциденту.

Пішов цілий клас відмов, який раніше списували на «дивацтва оточення»: незбіг параметрів служб, забутий пакет, розбіжні права. Відкат теж став передбачуваним — конфігурація версіонується, і повернення вузла до попереднього стану займає хвилини разом з історією змін.

Чим Puppet відрізняється від ручних скриптів розгортання

Ручний скрипт відповідає на питання «команда виконалася чи ні», а керування конфігурацією — на питання «чи збігається фактичний стан сервера з описаним».

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

Звідси й ідемпотентність змін: опис можна застосовувати скільки завгодно разів, і результат той самий. Якщо пакет уже потрібної версії, служба запущена, а конфіг збігається із шаблоном — не виконується жодна дія, прогін завершується без змін.

Це те, що дозволяє тримати однакові сервери десятками й не боятися повторного запуску на бойовому вузлі.

Порядок застосування теж влаштований інакше. Скрипт виконується згори вниз, і вся логіка послідовності лежить на авторові: не поставив залежність перед викликом — отримав падіння на чистій машині.

Puppet будує граф зв’язків між ресурсами й сам визначає черговість, тому конфігурація переноситься на новий вузол без переписування під нього.

Ще один сценарій, де порівняння підходів очевидне, — дрейф конфігурації. Хтось поправив параметр руками під час розбору аварії, скрипт про це не дізнається й під час наступного запуску нічого не виправить. Регулярний прогін повертає вузол до описаного стану й показує, що саме відхилилося.

Коли достатньо скриптів: один-три сервери, разове налаштування, немає вимоги відтворюваності й немає другого інженера, який має отримати той самий результат. Щойно вузлів стає більше й потрібна перевірка фактичного стану, ручні скрипти перетворюються на джерело розбіжностей.

Часті технічні сумніви перед початком робіт

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

Що з серверами, які налаштовані руками?

Переписувати їх наосліп не потрібно: стан знімається, описується й переноситься поступово. Різнорідний парк закриваємо окремими модулями під кожен випуск систем, а вузли з ручним налаштуванням беремо під керування останніми, коли решта вже стабільна.

Чи є обмеження в підходу?

Є, і проговорюємо їх до старту: вузли, де зміни вносять лише через веб-інтерфейси, і розгортання з жорстким порядком кроків погано описуються декларативно. Такі місця виносимо за контур керування й позначаємо явно — інакше конфігурація почне розходитися з реальністю.

Що відбувається після передачі?

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

Обговоримо задачу: з чого почати наведення порядку

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

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

Що потрібно від вас для старту:

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

Далі — пілотний контур на кількох вузлах: спочатку прогін у режимі перевірки без застосування змін, звірка розбіжностей із поточним станом, потім застосування й відкат.

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