Налаштування SaltStack: де розходиться конфігурація серверів
Поки серверів десяток, конфігурацію тримають у голові: розходження ловляться на око під час розбору інциденту. На сотні машин це перестає працювати — хтось правив ліміти вручну, хтось доставив пакет з іншого репозиторію, і до репозиторію ці правки вже не повернулися.
Дрейф конфігурації рідко виглядає як поломка. Спочатку розходяться версії бібліотек, потім шляхи до сертифікатів, потім порядок встановлення пакетів — і стенд, учора був копією бойового контуру, перестає відтворювати поведінку.
Діагностика перетворюється на ручне порівняння двох живих машин, бо еталонного опису налаштувань не існує.
Окрема історія — розходження налаштувань між серверами однієї ролі. Один тримає кеш, другий — чергу: конфіги виросли зі спільного шаблону, але розійшлися по дрібницях на кшталт кількості робочих процесів і порогів спрацювання.
У разі відмови першої машини навантаження переїжджає на другу, і та падає з іншої причини — розбір затягується на години.
Автоматизація налаштування серверів знімає саму можливість такої правки: цільовий стан описується декларативно і застосовується до групи машин, а не до конкретного хоста.
Налаштування SaltStack будується на states, pillar і grains — вони фіксують, чим одна роль відрізняється від іншої, а застосування показує, що саме змінилося. Розбираємо, як це закривається.
Єдине джерело конфігурації: що змінюється в експлуатації
Стани замість інструкцій: конфігурація перестає бути набором команд, які пам’ятають два інженери, і стає описом цільового вигляду вузла — пакети, файли, запущені служби.
Керування станами ідемпотентне: повторний прогін не ламає сервер, а приводить його до описаного вигляду, тому розходження налаштувань між вузлами перестає бути нормою.
Типова зміна — правка одного файлу стану: перевірка на тестовому контурі, потім розкатка на групу вузлів за хвилини.
Раніше це були послідовні заходи на кожен хост через SSH з ризиком пропустити крок; тепер час типової зміни вимірюється десятками хвилин, а правка залишається в історії репозиторію разом з автором.
Відновлення сервера з нуля йде з базового стану та ролі, а не за чек-лістом. Час відновлення сервера скорочується до десятків хвилин і не залежить від того, хто з чергових на зміні: за того самого коду результат однаковий.
Частка ручних операцій падає, а разом із нею зникає клас відмов «на одному сервері налаштування є, на іншому забули». Дрейф виявляється регулярною перевіркою і приводиться до цільового вигляду, а не живе до наступного інциденту.
Передбачуваність експлуатації в тому, що стан стендів описано в одному місці: SaltStack стає не «ще однією технологією», а точкою, з якої видно, чим стенди відрізняються один від одного.
Порівняння підходів до налаштування SaltStack: режими роботи
Що саме порівнюємо
Режим роботи визначає, де зберігається єдина версія станів і звідки вузол їх забирає. Від цього залежать точка відмови, швидкість збіжності й те, наскільки просто зловити розходження між майданчиками. Нижче — три схеми, які трапляються на практиці, з обмеженнями кожної.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Локальний запуск без керуючого сервера | Одиничні вузли, ізольовані сегменти, первинне налаштування машини | База станів роз’їжджається по вузлах: загальної картини немає, кожен сервер оновлюється окремо, цілісний відкат подивитися ніде |
| Централізований керуючий вузол | Парк на одному майданчику, потрібна єдина база станів і спільний журнал застосованих змін | Керуючий сервер стає єдиною точкою відмови й вузьким місцем при зростанні парку: видача станів на віддалені сегменти йде із затримкою |
| Гібридна схема з кількома майданчиками | Розподілений парк, вимоги до ізоляції контурів | Складніше тримати версії станів синхронними: потрібні узгодження змін, моніторинг розходжень і регламент, хто розкатує правку першим |
Гібридна схема майже завжди виявляється компромісом: вона знімає залежність від одного керуючого вузла, але переносить навантаження на дисципліну роботи зі станами.
Ми обираємо режим за ціною розходження конфігурацій — якщо розходження між майданчиками призводить до різної поведінки сервісу, економія на керуючому вузлі обходиться дорожче.
Порядок упровадження: від розбору парку до передачі регламентів
Налаштування SaltStack — це не встановлення агентів, а перенесення ручних дій в описані стани, які застосовуються відтворювано.
Помилка в одному спільному стані розходиться по всьому парку одразу, тому порядок робіт тут важливіший за швидкість: спочатку інвентаризація й схема ролей, потім опис станів, перевірка на тестовому контурі та поетапне введення в експлуатацію.
-
Інвентаризація серверів. Збираємо топологію: хости, їхні ролі, операційні системи та служби, що вже описано, а що налаштовано руками. На виході — карта парку та список розходжень до усунення.
-
Схема ролей і цільових груп. Визначаємо, за якими ознаками стани адресуються хостам і як розділяються середовища, — від цього залежить, чи можна змінювати одну роль, не зачіпаючи решту парку.
-
Опис станів. Спільне виносимо в базові стани, відмінності середовищ — у підставлювані дані. Кожен стан перевіряємо на повторне застосування: другий прогін не повинен змінювати нічого.
-
Тестовий контур. Розгортаємо копію парку, де стани проганяються спочатку без застосування змін, потім із застосуванням і відкатом до попереднього опису, — так помилки ловляться до продакшену.
-
Введення в експлуатацію. Спочатку спостерігаємо за розходженнями без змін, потім підключаємо невелику групу хостів, далі весь парк. Регулярне застосування за розкладом фіксує дрейф конфігурацій.
-
Передача регламентів. Віддаємо документацію: як додати роль, де змінювати дані середовища, як читати звіт про застосування і як відкотитися в разі розходження.
Що передаємо на руки: стани, схеми та політики доступу
Усі зміни конфігурації живуть у репозиторії SaltStack, а не в історії листування і не в голові чергового інженера.
Тому передача — це не розмова «поясніть, як тут усе влаштовано», а набір артефактів, за якими нова людина в команді піднімає сервер з нуля і повторює будь-яке налаштування без автора.
Що залишається у вашому репозиторії:
- Набори станів — описи ролей серверів: пакети, конфігураційні файли, сервіси та порядок застосування. Повторний прогін не ламає вже налаштований вузол.
- Схема керуючих вузлів — топологія керуючого та підпорядкованих вузлів, довіра між ними, точки відмови й порядок перемикання в разі недоступності.
- Розділення середовищ — де живуть чернетки, де продуктивні дані та як стан проходить шлях між ними.
- Політики доступу та ролі операторів — хто читає стани, хто править, хто застосовує на продуктивних вузлах; права видані за мінімально необхідним обсягом.
- Регламент змін — правка перевіряється на тестовому контурі, потрапляє в репозиторій через узгодження і лише потім розкатується.
- Документація — карта репозиторію, опис змінних за середовищами, інструкції з типових операцій і розбору збоїв.
- Порядок відновлення — як заново зібрати керуючий вузол із репозиторію, якщо його втрачено.
Після передачі інженери змінюють конфігурацію без нас: додають роль, викочують правку, відкочують невдалу зміну за журналом. Ми залишаємося на зв’язку для складних випадків, але залежності від автора налаштування більше немає.
Розбір упровадження: метрики до і після на парку серверів
Парк замовника — близько двох сотень віртуальних і фізичних машин, які налаштовувалися вручну і частково самописними скриптами. Розходження накопичувалися роками: правку вносили на одному вузлі й забували перенести на інші, а фактичний стан перевіряли обходом по серверах.
Нижче — що показали заміри перед кейсом упровадження та через пів року після передачі в експлуатацію.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час виведення сервера в роботу | 3–4 години ручних операцій | 25 хвилин, руками — лише реєстрація вузла |
| Усунення розходження налаштувань | 40–60 хвилин на вузол | 3–5 хвилин одразу на всю групу |
| Частка вузлів із розходженням | близько третини парку | поодинокі, знаходяться автоматично |
| Кількість відмов через налаштування за квартал | 9–12 інцидентів | 2, обидва поза зоною керування |
| Ручні правки на вузлах | постійні, без обліку | лише через опис стану |
Працювали на SaltStack: стан вузлів описується декларативно, майстер-сервер роздає його групам за ознаками заліза та ролі, а розходження видно порівнянням опису з фактом. Це дало головне — правка з’являється в одному місці й доїжджає до всіх машин, а не живе в чиїйсь пам’яті.
Передача в експлуатацію включала регламент змін, розмежування прав на опис станів і порядок перевірки на тестовій групі перед розкаткою на весь парк.
Чергова зміна розбирає відмову за зрозумілим алгоритмом, а не відновлює налаштування з пам’яті — тому кількість відмов через налаштування й тримається на низькому рівні.
Що робити, якщо частину серверів уже налаштовано вручну
Ручне налаштування не переписують наосліп — спочатку його описують. З вузлів знімають фактичний стан і перетворюють його на декларації, нічого поки не застосовуючи. Поки опис лише читає систему і показує розходження, працюючі сервіси не зачіпаються.
Опис поточного стану починається з інвентаризації: встановлені пакети, увімкнені служби, вміст конфігураційних файлів, права та власники, записи в планувальнику.
Ці дані фіксуються як база — далі кожна зміна звіряється з нею, і одразу видно, що саме відійшло вбік від початкового вигляду.
Перехідний період зручніше вести в режимі спостереження: опис проганяється без застосування, вузли звітують про розходження, але їхній стан не змінюється. Так випливають правила, які конфліктують із живою ручною настройкою, — до того, як вони щось зламають.
Поступовий перевід іде за групами однотипних вузлів, а не цілком. На кожному кроці зберігається зворотна сумісність: попередні скрипти й ручні правки продовжують працювати, поки новий опис не підтвердить, що стан вузла з нуля відтворюється на чистій машині.
SaltStack бере вузол під керування останнім кроком, коли опис звірено з реальністю і всі розходження пояснено. Після цього будь-яка ручна правка або потрапляє в опис, або затирається під час наступного прогону — вузол перестає бути унікальним, а його стан можна підняти заново.
Часті технічні сумніви перед стартом робіт
Сумніви перед стартом майже завжди ті самі, і вони по суті. Нижче — короткі відповіді по суті: як влаштовано налаштування SaltStack у частині стійкості, доступу та передачі супроводу.
Чим керована конфігурація відрізняється від набору скриптів?
Скрипт виконує команди й не знає поточного стану вузла. Декларація описує цільовий стан і приводить до нього вузол під час кожного прогону: повторний запуск безпечний, розходження видно у звіті, а не спливають у момент відмови.
Як захищено керуючий вузол?
Керовані вузли автентифікуються за ключами, доступ до керуючого вузла обмежено списком адрес і окремим обліковим записом без інтерактивного входу. Секрети зберігаються поза репозиторієм і роздаються точково.
Чи можна змінювати конфігурацію без простою?
Стани застосовуються спочатку на тестовий стенд, потім на бойові вузли по одному — сервіс продовжує відповідати на запити. Відкат — це повторне застосування попередньої версії, а не відновлення з резервної копії.
Як розмежовуються права доступу?
Ролі описують, хто бачить і змінює лише свої вузли: розробка не отримує прав на інфраструктуру, черговий — на секрети. Кожне застосування стану потрапляє в журнал з автором і часом.
Що потрібно, щоб передати супровід своїй команді?
Репозиторій станів, опис ролей і схем середовищ, інструкція з типових змін і розбір з вашими інженерами. Доступи передаються вам, підтримка потрібна лише на період перших правок.
Обговоримо вашу задачу: з чого почати розбір парку
Щоб розмова була предметною, а не оглядовою, нам достатньо поточного зрізу парку — за ним уже видно, які ролі потрібні, де вузькі місця і скільки етапів займе переведення машин на SaltStack.
- Склад парку: скільки серверів, які операційні системи та їхні мажорні версії, де розміщені — власні стійки, хмара чи змішано.
- Ролі машин: веб-вузли, бази даних, черги, кеш, балансувальники, службові сервери — з приблизною кількістю на кожну групу.
- Як конфігурація ставиться зараз: ручні правки, скрипти, попередні системи керування, наскільки фактичний стан машин збігається з репозиторієм.
- Доступи й обмеження: як видаються права, чи є сегменти без виходу назовні, де зберігаються секрети та ключі.
- Вікна робіт: коли допустимі перезапуск служб і перезавантаження вузлів, які періоди не можна чіпати.
- Вимоги до відкату: чи потрібна перевірка результату на пілотній групі і як швидко має повертатися попередня конфігурація.
Далі ми повертаємося з оцінкою та планом: розбивка на етапи, пілотна група, порядок переведення решти машин і критерії приймання. Старт проєкту має сенс із пілота — він розкриває реальні обмеження парку раніше, ніж ми торкаємося продуктивних вузлів.
Опишіть задачу в зручному вигляді, хай навіть чернеткою, — цього достатньо, щоб обговорити її предметно.
