Налаштування CI/CD пайплайну через Spacelift: автоматизація IaC

Налаштування Spacelift: чому ручні правки ламають випуск

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

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

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

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

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

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

Що змінюється, коли інфраструктура описана кодом

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

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

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

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

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

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

Історія описів дорівнює історії станів: відкат до попередньої версії — це операція над описом, а не відновлення з пам'яті.

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

Варіанти запуску: керований сервіс, свій виконавець, гібрид

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

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

Що враховувати під час вибору

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

Налаштування Spacelift: етапи від аудиту до передачі

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

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

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

Що залишається у вас: конфігурація, схеми, регламенти

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

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

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

Кейс: випуск інфраструктурних змін без ручних правок

Замовник — продуктова команда з кількома середовищами і десятком сервісів. Інфраструктуру правили руками: інженер відкривав консоль провайдера, додавав ресурси, окремо повідомляв у листуванні, що готово. Контекст змін жив у головах двох людей, а випуск залежав від того, хто сьогодні на зв'язку.

Ми описали інфраструктуру як код і винесли випуск у Spacelift: зміни оформлюються як перевірювані описи, проходять автоматичні перевірки плану, а застосування запускається за підтвердженням ролі.

Усі середовища отримали однаковий порядок випуску — розбіжність між тестовим контуром і бойовим середовищем перестала накопичуватися.

Заміри до і після

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

Що робити, якщо інфраструктура вже розгорнута вручну

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

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

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

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

Кожен крок — окрема зміна зі зрозумілою точкою відкату; ручні правки в панелі закриваються політикою, інакше контур знову почне розходитися з реальністю.

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

Технічні сумніви: стан, секрети, відкати

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

Як поводяться із секретами й доступами?

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

Як відкотити застосовану зміну?

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

Кілька команд в одному репозиторії не заважають одна одній?

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

Обговоримо задачу: що надіслати для оцінки та плану

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

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

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

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

Опишіть задачу — повернемося з оцінкою та планом.