Автоматичне провізіонування серверів: cloud-init і user-data

Ручний провізіонінг серверів замість cloud-init: що ламається

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

cloud-init усуває цей розрив — вузол під час першого старту сам застосовує пакети, користувачів, ключі та розмітку дисків із user-data.

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

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

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

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

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

Що дає автоматичний провізіонінг під час старту сервера

Провізіонінг під час старту вузла прибирає ручні кроки між створенням машини та її готовністю прийняти навантаження. Інструкції задаються заздалегідь, і cloud-init застосовує їх під час першого завантаження — без підключення по SSH і правок «на місці».

Час уведення сервера в роботу падає з десятків хвилин до одиниць і перестає залежати від того, хто чергує.

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

Опис живе в репозиторії, проходить рев'ю та версіонується — розходження між вузлами стає видно до інциденту, а не під час нього.

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

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

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

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

Способи автоматизації: cloud-init, образи, конфігурація

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

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

Порядок впровадження: від аудиту до передавання регламентів

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

1. Аудит поточного видавання серверів. Збираємо інвентар: звідки беруться образи, які параметри задаються вручну, де розходяться конфігурації між середовищами. Результат — карта відмінностей і перелік операцій, які прибираємо.
2. Схема провізіонінгу. Розділяємо відповідальність: що запікається в образ, що йде в user-data, що доозначується пізніше. Фіксуємо формат шаблонів, джерела секретів і порядок застосування.
3. Шаблони й модулі. Пишемо багаторазові блоки — мережа, облікові записи, монтування дисків, агенти моніторингу. Одна роль вузла — один шаблон, без розгалужень за іменем хоста.
4. Перевірка на стенді. Проганяємо шаблони на ізольованому контурі: створюємо та перестворюємо вузли, перевіряємо повторний запуск, поведінку за недоступного джерела секретів і за частково застосованої конфігурації.
5. Дослідна група вузлів. Виводимо один сегмент середовища на нову схему та звіряємо з еталоном за складом пакетів, службами й відкритими портами. Помилки правимо в шаблоні, а не на машині.
6. Передавання в експлуатацію. Віддаємо регламенти, схему провізіонінгу та порядок зміни шаблонів: версіонування, перевірку перед викаткою, відкат до попередньої ревізії.

Що залишається в команди: шаблони, схеми, регламенти

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

• Комплект шаблонів і профілів видавання — базові образи, профілі під ролі (веб-вузол, база, брокер) і змінні оточень: нова машина піднімається з готового профілю, а не збирається вручну.
• Схема потоку провізіонінгу — шлях від запиту до готового вузла: де підставляються user-data і метадані, у який момент вузол потрапляє в балансування та моніторинг.
• Політики доступу й ролі — мінімальні права: хто править шаблони, хто лише запускає, хто читає журнали; секрети не зберігаються відкритим текстом у user-data.
• Документація з експлуатації — точки входу та типові збої з порядком дій: не пройшла ініціалізація, вузол не зареєструвався, конфігурація розійшлася з еталоном.
• Регламент зміни шаблонів — правка через гілку та перевірку на тестовому стенді, версіонування профілів, вікно відкату на попередню ревізію.
• Набір перевірок перед викаткою — ідемпотентність повторного запуску, коректність мережевих налаштувань, потрапляння вузла в моніторинг та інвентар.

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

Кейс: видавання серверів прискорилося в кілька разів

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

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

Що змінили

Зібрали бібліотеку декларативних шаблонів під типові ролі — веб-вузол, вузол застосунків, база даних, балансувальник.

cloud-init під час першого запуску сам розмічає диски, ставить пакети, налаштовує користувачів і ключі доступу, піднімає агент моніторингу; відмінності між оточеннями описані змінними в user-data, а не інструкцією для інженера.

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

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

Частка невдалих перших запусків упала з 18% до менш ніж 2%, а решта відмов пов'язані із зовнішніми причинами на кшталт недоступності мережі й розбираються за логами, а не методом проб.

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

Чим первинне налаштування вузла відрізняється від керування конфігурацією?

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

Тут cloud-init забирає user-data з метаданих і виконує її один раз — створює користувачів і ключі, розмічає диск, задає мережу, ставить агента системи керування конфігурацією.

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

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

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

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

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

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

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

Часті технічні питання щодо автоматизації видавання серверів

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

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

Чи можна перевести вже працюючі сервери?

Так, але по одному вузлу. Спочатку фіксуємо поточний стан як шаблон і перевіряємо його на тестовій копії, потім переносимо вузол за вузлом, залишаючи старий образ доступним для відкату. Масова заміна «за один прохід» тут не застосовується.

Хто відповідає за шаблони після здачі?

Шаблони передаємо в репозиторій замовника з історією змін і описом кожного параметра. Правки йдуть через рев'ю за погодженим регламентом — так зміна, що ламає видавання, видна до застосування, а не після.

Як перевіряється відповідність вузла еталону?

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

Що входить у передавання супроводу?

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

Обговоримо вашу задачу автоматизації провізіонінгу

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

На старті достатньо:

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

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

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

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