Розробка Terraform-провайдера: де рветься автоматизація
Поки внутрішні сервіси описують вручну — у вікі, таблиці або нотатці поруч із кодом, — інфраструктура живе окремо від цього опису. Зміну вносить інженер через панель керування, а в документі вона з'являється через тиждень або не з'являється взагалі.
Уже через два-три релізи ніхто не може впевнено сказати, яка конфігурація зараз у бойовому контурі й чому вона саме така.
Розбіжність конфігурації та реальності розкривається в найнезручніший момент: під час відкату, під час перенесення на інший контур, під час розбору інциденту. Скрипт, який «завжди працював», спирається на ручну правку піврічної давності, про яку не пам'ятає навіть її автор.
Відновлення перетворюється на археологію, а підняти бойовий контур з нуля виявляється довше, ніж погодити вікно простою.
Розробка Terraform-провайдера закриває це інакше: внутрішні сервіси описуються декларативно, тим самим способом, що й хмарні ресурси, і потрапляють у єдине джерело правди інфраструктури. Будь-яке відхилення плану від фактичного стану видно до застосування, а не після.
Ручна правка перестає бути безіменною — вона або потрапляє в опис, або відкочується наступним застосуванням.
Далі розбираємо, як це влаштовано: які сутності варто виносити в ресурси та джерела даних, як вибудувати автоматизацію керування інфраструктурою без ручних правок і що робити з уже накопиченою розбіжністю.
Що дає єдиний шар керування внутрішніми сервісами
Свій провайдер перетворює внутрішні сервіси на такий самий декларативний ресурс, як хмарні: єдиний шар керування, де опис сервісу живе в репозиторії, застосовується через Terraform і проходить перевірку коду. Далі — вимірювані наслідки, які видно вже першого тижня роботи.
Єдиний опис замість ручних правок
Джерело правди одне: середовища сервісу, права, секрети та точки моніторингу описані в одному файлі. Будь-яка зміна проходить план застосування, і розбіжність між описом і реальним станом видно до викочування, а не після збою.
Новий сервіс виводиться за шаблоном: підготовка середовища займає одне застосування замість днів ручних операцій, а цілий клас відмов — «поправили руками й забули зафіксувати» — зникає.
Розмежування прав і середовищ за замовчуванням
Ролі, межі середовищ і рівні доступу зашиті в сам провайдер, а не в інструкцію у вікі. Розробник описує сервіс, але не може видати собі зайві права або зачепити чуже середовище — спроба відсікається на етапі плану.
Відновлення після збою стає застосуванням відомого опису: середовище піднімається з конфігурації за хвилини, а не збирається з пам'яті чергового, і результат збігається з початковим.
Передбачувані зміни середовищ, менше ручних операцій, швидше виведення нового сервісу та відновлення — це ефекти одного шару, а не набору розрізнених скриптів.
Порівняння підходів: скрипти, шаблони, обгортка чи власний шар
Що вибрати, визначає не смак, а кількість внутрішніх сервісів, які потрібно описувати декларативно, і те, хто підтримуватиме ці описи через півроку. Нижче — реальні альтернативи, між якими обирають команди, з їхніми обмеженнями.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні скрипти та інструкції | Разовий стенд, один-два сервіси | Стан не відстежується, середовища розходяться, відкат вручну |
| Шаблони конфігурації | Типові сервіси з рідкісними відмінностями | Копії правлять руками, план змін не перевіряється |
| Обгортка над готовим інструментом | Єдиний вхід поверх наявного ядра | Не керує життєвим циклом ресурсу, частина параметрів недоступна |
| Власний шар автоматизації з нуля | Модель ресурсів унікальна, готові засоби не підходять | Стан, імпорт і відкат робляться власними силами |
| Доопрацювання відкритого рішення | Модель близька до готової, не вистачає частини можливостей | Залежність від зовнішнього коду, правки переносяться під час оновлень |
Коли достатньо шаблонів і скриптів
Поки сервісів небагато, середовищ два, а конфігурація змінюється раз на квартал, зв'язка «шаблон плюс інструкція» обходиться дешевше й читається швидше.
Межа настає, коли копій стає більше, ніж людей: розбіжності між середовищами шукають руками, а відновлення стенда після збою перетворюється на окрему задачу.
Коли без власного шару не обійтися
Якщо у сервісу власний життєвий цикл, залежності між об'єктами й правила, яких немає в готових засобах, ні шаблон, ні обгортка їх не втримають.
Тоді й починається розробка Terraform-провайдера: описуємо ресурси, перевірки перед застосуванням та імпорт уже наявних об'єктів, щоб зміни проходили передбачувано, а стан не розходився з реальністю.
Етапи роботи: від аудиту інфраструктури до передачі коду
Роботу ведемо короткими ітераціями: спочатку фіксуємо те, що зараз робиться вручну, потім переносимо це в провайдер і перевіряємо на тестовому контурі. Такий порядок дозволяє змінювати інфраструктуру без зупинки сервісів і не залишає команду сам на сам із незрозумілим кодом.
Що фіксуємо на вході
Розбираємо перелік сервісів, середовищ і ролей доступу: що створюється руками, що вже автоматизовано, де описи розходяться з фактичним станом. Окремо збираємо обмеження — правила безпеки, порядок погодження змін, вимоги до аудиту.
На виході отримуємо карту ресурсів і список прогалин у доступах, а не загальний опис «як усе влаштовано».
- Аудит інфраструктури та доступів: інвентаризація сервісів і прав, звірка реального стану з описами.
- Схема цільового опису: які сутності стають ресурсами та джерелами даних, як вони пов'язані між собою.
- Розробка й налаштування провайдера: реалізація ресурсів, імпорт наявних об'єктів, коректна обробка змін і видалення.
- Перевірка на тестовому контурі: створення, зміна та відкат на копії середовища, звірка плану з очікуваним результатом.
- Дослідна експлуатація: команда працює через новий інструмент на обмеженій ділянці, ми супроводжуємо й правимо за зауваженнями.
- Передача й навчання команди: розбір коду, порядок розгортання й оновлення, регламент розбору збоїв.
Як перевіряємо результат перед здачею
Здаємо не «працюючий скрипт», а відтворюваний цикл: план змін збігається з очікуваним, повторний запуск не породжує зайвих операцій, відкат повертає конфігурацію в попередній стан. Окремий критерій готовності — команда замовника сама проводить типову зміну без нашої підказки.
Артефакти в репозиторії: код, схеми, регламенти, доступи
Здаємо не лише працюючий код, а й увесь контур, який дозволяє вашій команді жити з ним без нас: від опису сервісів до інструкцій для чергової зміни. Нижче — що саме залишається в репозиторії після завершення робіт.
Код і опис інфраструктури
- Вихідний код Terraform-провайдера з описом кожного ресурсу та джерела даних: які параметри обов'язкові, які обчислюються, як обробляються конфлікти під час зміни.
- Конфігурації середовищ — роздільні набори параметрів та ізольовані стани, щоб перевірка не могла зачепити промисловий контур.
- Готові модулі для типових сервісів: підключення нового сервісу зводиться до кількох рядків замість копіювання чужого файлу цілком.
- Набір перевірок і приклади використання — пісочниця, де видно, як ресурс поводиться під час створення, зміни та видалення.
Схеми та регламенти для команди
- Схеми зв'язків між сервісами, середовищами та зовнішніми системами: на одній сторінці видно, що від чого залежить і що зачепить зміна.
- Політики доступу й ролі — хто читає стан, хто змінює, хто застосовує зміни в промисловому контурі; розмежування зашите в код і перевіряється автоматично.
- Регламент змін: порядок випуску нової версії, правила зворотної сумісності та процедура відкату.
- Інструкції для чергової зміни: типові відмови, як відрізнити їх від збою інфраструктури і що робити покроково.
Кейс: 40 сервісів під керуванням Terraform замість ручних правок
До нас прийшла команда, у якої 40 внутрішніх сервісів жили в кількох середовищах, і кожне середовище збиралося руками. Ми перевели все на єдиний опис інфраструктури на Terraform і розробили провайдер під внутрішні сервіси — для тих сутностей, під які готових ресурсів не було.
Що було до
Виведення нового сервісу займало два-три дні: інженер заводив мережу, балансувальник, бази, черги та права за інструкцією на 30 кроків. На реліз припадало 15-20 ручних правок, і частина з них розходилася з тим, що вже працювало в проді — середовища поступово роз'їжджалися.
Відновлення після збою впиралося в те, що актуальну конфігурацію ніхто точно не знав: її збирали за логами й опитуваннями сервісів. Близько половини інцидентів припадало не на помилку в коді, а на розбіжність налаштувань.
Що стало після
Сервіс описується файлом у спільному репозиторії, а провайдер приводить інфраструктуру до потрібного стану. Виведення нового сервісу скоротилося до 40 хвилин, ручних правок на реліз залишилися одиниці замість 15-20, і всі вони проходять перевірку як код.
Відновлення середовища та відкат ідуть з опису, а не з пам'яті інженера: збійну конфігурацію повертаємо за хвилини замість годин. Клас відмов «конфігурація роз'їхалася між середовищами» пішов — розбіжності видно на етапі перевірки плану до застосування, а не на проді.
Що робити, якщо інфраструктура вже описана вручну?
Переписувати все одразу не потрібно — саме на цьому такі проєкти й зупиняються. Уже налаштовані вручну середовища продовжують працювати, а опис вводиться поруч: спочатку він лише читає поточний стан і будує план змін, нічого не застосовуючи. Поки план показує розбіжності, керування залишається в людей.
Перший крок — імпорт наявних ресурсів: кожен об'єкт прив'язується до опису й потрапляє у файл стану, але сама конфігурація не змінюється. Мета етапу — порожній план: отже, опис точно збігається з реальністю і наступний запуск не знесе працююче середовище. Розбіжності розбирають по одній — зазвичай це атрибути, виставлені вручну й забуті.
Порядок переведення підпорядкований радіусу ураження. Першими йдуть сервіси без стану та зовнішнього трафіку — черги, кеші, стенди: помилка там коштує перезапуску, а не простою. Потім мережі, балансування та права доступу, далі сховища з даними. Те, що тримає трафік, переводиться останнім і по одному — тоді відкат обмежений одним компонентом.
Покрокове включення виглядає так: сервіс описано, імпортовано, план порожній — лише після цього керування передається опису, а ручні правки через інтерфейс закриваються.
Між кроками фіксуємо результат: скільки об'єктів під керуванням, які розбіжності пішли, скільки сервісів пройшло звірку з порожнім планом. Так перехід іде без зупинки й без одного великого перемикання, після якого зазвичай і трапляються аварії.
Технічні сумніви: стан, права, відкат, підтримка
Сумніви, які виникають перед розробкою Terraform-провайдера, зазвичай одні й ті самі: де живе стан, хто має право застосовувати зміни, як відкотитися і що буде після передачі коду. Нижче — короткі відповіді, деталі розбираємо на дзвінку за вашою задачею.
Де зберігається стан і хто блокує зміни?
Стан лежить у віддаленому сховищі з блокуванням на час застосування: один контур змінює лише один інженер. Середовища розділені окремими наборами й доступом за сервісними обліковими записами, історія версій стану зберігається.
Хто має право змінювати інфраструктуру?
План будує будь-який інженер команди, застосування доступне лише ролі з підтвердженням, продуктивний контур відокремлений від тестового. Кожне застосування залишає запис: хто, коли і що змінив.
Як влаштований відкат зміни середовища?
Перед застосуванням план показує всі зміни, включно з видаленням ресурсів. Відкат спирається на зафіксовану версію провайдера та знімок стану; ресурси з даними при цьому не перестворюються.
Що буде при зміні інтерфейсів сервісів?
Нова версія виходить поруч зі старою, тому чинні конфігурації продовжують працювати. Застарілі поля позначаємо попередженням під час побудови плану, а перехід робимо імпортом ресурсів без видалення й повторного створення.
Хто підтримує код після передачі?
Передаємо репозиторій, тести на схему й поведінку, документацію з ресурсів і порядок випуску релізу. Інженери замовника відпрацьовують процес на своїх задачах, супровід і доопрацювання закриваємо окремою угодою.
Обговоримо задачу: розберемо інфраструктуру й повернемося з планом
Точна оцінка термінів і обсягу робіт із кастомним провайдером можлива лише після розбору поточного стану інфраструктури.
Опишіть задачу — які внутрішні сервіси потрібно перевести під декларативне керування, у яких межах живуть середовища і які обмеження за термінами вже зафіксовані.
Зі свого боку розберемо конфігурації, розділення станів і ролі доступів, а потім повернемося з планом робіт і розподілом етапів за термінами.
Що допомагає нам зібрати коректну оцінку:
- перелік внутрішніх сервісів та їхніх інтерфейсів — що вже віддає керуючі виклики, а що доведеться обгортати;
- межі середовищ: скільки середовищ, як відрізняються параметри, де проходить розділення між тестовим контуром і промисловим;
- поточне зберігання стану: де лежить файл стану, хто має до нього доступ, чи є блокування на паралельні зміни;
- вимоги до доступів: які облікові записи та ролі видаються провайдеру, хто відповідає за ротацію прав, які дії потребують підтвердження;
- обмеження й терміни: жорсткі дати, заморозки змін, вікна обслуговування, вимоги щодо відкату;
- склад погоджувачів: хто з боку замовника приймає схему модулів і вердикт щодо готовності.
Після розбору повернемося з планом: послідовність етапів, склад команди, точки, на яких ви зможете перевірити проміжний результат на своєму стенді, і порядок передачі репозиторію та документації вашим інженерам.
Якщо частина сервісів поки не готова до керування з коду, скажемо про це прямо й запропонуємо, з чого почати, щоб не блокувати решту.
Готові почати з короткої розмови по суті: опишіть задачу автоматизації — повернемося з оцінкою та планом.
