Налаштування деплою Google Cloud: де ламається випуск версій
Випуск ламається не на етапі розробки, а в момент перенесення змін на робочий контур.
Типова картина: образ збирається локально, міграції проганяються вручну, змінні середовища копіюються з нотаток — і за тиждень стенд і продакшн розходяться так, що той самий код поводиться по-різному.
Розходження середовищ рідко видно одразу: воно спливає на наступному релізі, коли причина вже загублена в чужій історії правок.
Друге джерело збоїв — порядок кроків. Міграція, застосована після старту нової версії, блокує таблиці, а старий контейнер продовжує обслуговувати запити з новою схемою і віддає помилки частині користувачів.
Окрема історія — секрети й параметри, які правлять руками в панелі та не фіксують у репозиторії: під час наступного розгортання їх мовчки перезаписують значеннями за замовчуванням.
Найдорожче обходиться відкат. Якщо попередню збірку не збережено як відтворюваний артефакт, повернення йде навмання: перезбирають із гілки, яка вже поїхала вперед, і отримують третій, невідомий нікому варіант. Простій у момент випуску розтягується не на хвилини, а на години.
Налаштування деплою Google Cloud закриває саме ці три класи відмов: викладка йде за одним сценарієм, середовища збираються зі спільного опису, а попередня версія залишається готовою до повернення в один крок.
Що дає керований випуск: швидкість, відкати, менше простою
Ручний випуск тримається на людині: вона пам'ятає порядок дій, вручну править конфігурацію на сервері та залишається на зв'язку ввечері. Один такий випуск займає години, і час випуску версії зростає разом із кількістю сервісів — кожна правка вимагає заново пройти весь ланцюжок.
Коли інфраструктура описана в Terraform, а викладка йде однією командою, той самий випуск укладається в хвилини й не залежить від того, хто саме його запускає.
Передбачуваний відкат перестає бути окремою операцією. Попередня версія залишається доступною, і повернення трафіку на неї займає секунди, без розгортання резервної копії та очікування відновлення бази.
Це змінює ціну помилки: невдалий випуск відкочується раніше, ніж його встигають помітити користувачі.
Кілька середовищ описуються одним набором правил: тестове, передпродакшн і робоче відрізняються параметрами, а не ручними правками «тільки тут». Зміна проходить той самий шлях перевірок, тому розходження «на тесті працювало» перестає бути нормою і перестає з'їдати день на розбір.
Вартість простою рахується не абстрактно, а в хвилинах недоступності та втрачених запитах. Коли випуск не потребує нічного вікна й ручних пауз, недоступність стискається до часу перемикання трафіку, а частина оновлень проходить взагалі без зупинки сервісу.
На виході випуск стає повторюваним: однаковий результат за однакових вхідних даних, історія версій і зрозуміла точка повернення. Далі розбираємо, з чого складається такий процес.
Варіанти деплою: контейнери, машини, оркестратор
Вибір варіанта розміщення визначає не лише те, як застосунок переживає піки навантаження, а й скільки інженерного часу йде на експлуатацію.
Керовані контейнери знімають із команди обслуговування серверів, виділена віртуальна машина дає повний контроль над середовищем, оркестрація потрібна там, де сервісів багато і вони пов'язані між собою. Нижче — робоче порівняння варіантів деплою в Google Cloud, за яким ми зазвичай і обираємо.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керовані контейнери | Сервіс із нерівномірним навантаженням: нічні провали, денні піки. Масштабування до нуля, оновлення — зміною образу | Немає постійного локального диска, обмежений доступ до налаштувань середовища, не підходить для довгих фонових завдань |
| Виділена віртуальна машина | Моноліт, успадкований застосунок, ліцензоване ПЗ, особливі вимоги до ядра й мережевого стеку | Патчі, масштабування та оновлення вручну, ресурси простоюють між піками |
| Оркестрація контейнерів | Десятки сервісів, спільні мережеві політики, власні вимоги до планувальника та ізоляції | Високий поріг експлуатації: вузли, квоти, оновлення й моніторинг кластера — постійна робота команди |
| Безсерверні функції | Окремі події: вебхуки, обробка файлів, рідкісні тригери за розкладом | Холодний старт, обмеження за часом виконання, не тягнуть постійне навантаження |
На практиці схема рідко буває одна: інтерфейс і API їдуть у керовані контейнери, база й важкі обробники залишаються на виділеній машині або всередині оркестратора.
Ми описуємо ці межі кодом, щоб конфігурацію можна було перезібрати з нуля та відтворити на тестовому середовищі без ручних правок. Звідси й розбираємо, як це закривається далі — збіркою, середовищами та відкатами.
Аудит інфраструктури, схема середовищ, налаштування, передача
Роботи ведемо від поточного стану до регламентів, які ваша команда застосовує без нас.
Починаємо з аудиту інфраструктури в хмарному проєкті: інвентаризація ресурсів, права доступу, місця зберігання секретів і ручні операції у випуску — саме вони ламаються першими при зміні відповідального. Продакшн не чіпаємо, доки не узгоджено схему середовищ.
- Аудит інфраструктури. Карта ресурсів, залежностей і прав, перелік ручних кроків і точок відмови; позначаємо, що переноситься в декларативний опис, а що потребує перебудови.
- Схема середовищ. Розводимо розробку, передпродакшн і продакшн: окремі конфігурації, ізольовані секрети, власні квоти — зникає клас помилок із ключами та даними не з того середовища.
- Опис інфраструктури як коду. Ресурси переїжджають у конфігурацію зі станом у захищеному сховищі та блокуванням: ручні правки в консолі перестають бути нормою, стенд піднімається повторювано.
- Налаштування викладки. Збірка артефакту, реєстр образів із політикою зберігання, розділення трафіку між ревізіями сервісу, міграції бази окремим кроком.
- Перевірка перед випуском. Прогін на передпродакшні, тренування відкату на попередню ревізію, метрики й алерти на помилки та затримки — до бойового трафіку.
- Передача регламентів. Документація з випуску та відкату, розбір із вашими інженерами, супровід першого самостійного релізу.
Що залишається у вашої команди після передачі
Передаємо не «працюючий сервер», а повний комплект, за яким ваша команда може розвивати й перезбирати середовище без нас. Інфраструктура описана декларативно, а не зібрана руками в консолі Google Cloud: стенд можна підняти з нуля та отримати ті самі сервіси, мережі й права. Нижче — що саме йде у ваш репозиторій і вікі на прийманні.
- Конфігурація як код — опис усіх середовищ, сервісів і мереж у файлах репозиторію з історією змін. Тестовий і робочий контури збираються з одного набору описів, розходження видно на етапі перевірки, а не в бою.
- Схеми інфраструктури — карта сервісів, балансувальників, черг, баз і зв'язків між ними, з позначками, які елементи змінюються разом. Потрібна, щоб правка одного компонента не ламала сусідній.
- Політики доступу — ролі сервісних облікових записів, мінімально необхідні права, розділення контурів між собою, порядок видачі та ротації ключів.
- Регламент відкату — як повернути попередню ревізію сервісу, скільки це займає, хто ухвалює рішення, які перевірки проганяються після повернення.
- Регламент відновлення — покроковий порядок підняття контуру з нуля: що розгортається першим, де лежать резервні копії, як перевіряється цілісність даних після.
- Інструкція з випуску — послідовність збірки та викладки, змінні середовища, робота із секретами, що робити при провалі перевірок перед публікацією.
- Спостережуваність — перелік метрик і журналів, пороги оповіщень і маршрути, якими вони йдуть черговому.
Усе це лежить у ваших репозиторіях і облікових записах, доступи передані вашій команді. Наші інженери залишаються на зв'язку, але подальша робота не потребує нашої участі в щоденних операціях.
Кейс: викладка вручну перетворилася на передбачуваний випуск
Замовник прийшов із ручною викладкою: застосунок на віртуальних машинах, інструкція у вікі, випуск прямо на сервері — копіювання файлів, збірка «на місці», правка конфігурації руками.
Один випуск займав 40–50 хвилин інженерного часу, а кожна п'ята викладка закінчувалася інцидентом: забутий параметр середовища, розходження версій залежностей, незакритий порт.
Найдорожче обходилося відновлення: шукали, що саме змінили, звіряли конфігурацію з минулим станом і збирали попередню версію заново. Метрики до — 45 хвилин на випуск, 20% викладок із відкатом, середній час відновлення 2,5 години.
Що змінилося
Платформу перезібрали на Google Cloud: збірку винесли в конвеєр, середовища описали декларативно, стан — у керований сервіс, секрети — у сховище.
Викладка йде в новий екземпляр, трафік перемикається лише після перевірки готовності, а попередня версія залишається в реєстрі як готова точка відкату.
Метрики після: випуск — 6 хвилин без участі інженера, збої — одна викладка з двадцяти, відкат на попередню версію — 90 секунд, відновлення сервісу — 4 хвилини замість 2,5 годин.
Окремий ефект — частота випусків. Раніше зміни накопичували тижнями, щоб не ризикувати; тепер випускають у міру готовності, а чим менша різниця між версіями, тим рідше збої та швидше розбір, якщо щось пішло не так.
Що робити, якщо проєкт уже розгорнуто вручну?
Переписувати застосунок не потрібно — описуємо та автоматизуємо те, що вже працює. Міграція ручної викладки йде поетапно й за сервісами, а не одним перемиканням: стара схема випуску залишається робочою, доки нова не довела надійність на окремих ділянках.
Перший крок — інвентаризація. Фіксуємо реальний стан: які сервіси запущені, звідки беруться образи, де лежать змінні середовища та секрети, які правила доступу відкриті назовні.
Головний ризик тут не в коді, а в розходженні між документацією та робочим контуром: частину налаштувань зазвичай внесено руками й ніде не записано.
Далі описуємо інфраструктуру як код у Google Cloud, починаючи з периферії — мережа, права сервісних облікових записів, правила доступу, реєстр образів. Застосування цих описів не перезапускає працюючі контейнери, тому продукт продовжує обслуговувати запити без простою.
Збірку й автоматичний деплой переносимо останніми. Спершу новий процес розгортає версію в окремому середовищі, перевірки йдуть на ньому, і лише потім трафік переводиться порціями з поточної ревізії, з відкатом на попередню однією командою. Базу даних не перестворюємо: міграції схеми виконуються окремим кроком і є оборотними.
Такий порядок прибирає ручні правки на серверах поступово й без переписування проєкту.
Часті технічні сумніви перед стартом робіт
Сумніви на цьому етапі майже завжди одні й ті самі: де будуть лежати секрети, хто отримає доступ до продакшну, чи реально швидко повернути попередню версію і чи не доведеться переписувати проєкт. Нижче — інженерні відповіді без загальних слів.
Де зберігатимуться секрети та ключі доступу?
Паролі, токени й сертифікати живуть у менеджері секретів Google Cloud, а в репозиторії залишаються лише посилання на них. Значення підставляються в момент застосування конфігурації, тому копій ключів на машинах інженерів не залишається. Ротація — це заміна одного значення, без правок у коді та перезбирання образів.
Як розмежовуються права та ролі?
Доступ видаємо за принципом мінімально необхідного: сервісний акаунт застосунку вміє тільки те, що потрібно йому для роботи, а тестовий і робочий контури ізольовані. Інженер отримує роль на конкретне середовище й на час задачі. Усі зміни конфігурації потрапляють у журнал аудиту — видно, хто, що і коли змінив.
Наскільки швидко відкочується зіпсована версія?
Кожен реліз — незмінний образ з окремим тегом, тому повернення до попередньої версії це перемикання трафіку на минулу ревізію, а не перезбирання. Займає менше хвилини. Міграції схеми пишемо зворотно сумісними, щоб стара версія застосунку продовжувала працювати з новою базою.
Чи сумісно це з поточним стеком?
Переносити проєкт цілком не потрібно: зазвичай достатньо упакувати збірку та запуск у контейнер, а фреймворк, база даних і черги залишаються попередніми. Сервіси, які вже працюють на віртуальних машинах, продовжують працювати. Маршрутизацію налаштовуємо на рівні балансувальника й перемикаємо поступово.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Опишіть, як випуск змін влаштований зараз: чим збираються артефакти, хто викладає в середовища, де лежать конфігурації та секрети, скільки часу займає відкат на попередній реліз.
Цього достатньо, щоб зрозуміти вузькі місця — ручні кроки, розходження між середовищами, відсутність історії викладок.
У відповідь надсилаємо план впровадження з етапами, склад робіт і порядок взаємодії. За кожним пунктом зазначаємо, що робимо ми, а що залишається на вашому боці, — щоб оцінка робіт була перевірюваною, а не «під ключ за домовленістю».
- Розбір поточної схеми випуску: збірка, середовища, доступи, точки ручного втручання.
- Оцінка робіт за етапами з межами відповідальності та залежностями від вашої команди.
- План впровадження: черговість переведення середовищ, точки відкату, вікна для змін.
- Опис інфраструктури як коду: конфігурації, змінні середовища, правила масштабування.
- Порядок взаємодії: одна точка зв'язку, звітність за етапами, канал для термінових питань.
- Критерії приймання на кожному кроці: що вважаємо завершеним і як це перевіряємо.
- Регламент підтримки викладки після запуску: як випускаються зміни, як розбираються збої.
Опишіть задачу в тому вигляді, у якому вона є, — повернемося з оцінкою та планом робіт.
