GCP Compute Engine налаштування: де ламається прод
Налаштування віртуальних машин у GCP Compute Engine ламається не на старті, а на зростанні. Перші машини збирають вручну: обирають тип, додають диск, прописують SSH-ключ у метадані проєкту.
Поки інстансів п’ять і їх веде один інженер, схема тримається — а далі починається розходження конфігурацій.
Основна причина в тому, що шаблон машини живе окремо від прода. У групі керованих інстансів (MIG) зберігається один зразок, але правила брандмауера, мітки, ліміти й додаткові диски до нього не потрапляють.
Автомасштабування під навантаженням піднімає десяток вузлів із шаблону — і вони приходять іншими: без доступу до бази, з диском іншого розміру, без міток, за якими їх знаходить балансувальник.
Ручні правки в консолі — друга міна. Ключі в метаданих проєкту переживають звільнення й передачу завдань: доступ залишається, а хто ним користується — незрозуміло.
OS Login закриває це, але тільки коли ввімкнений на рівні організації та пов’язаний із ролями; вмикати його в окремому проєкті, поверх старих ключів, безглуздо.
Проблеми конфігурації у проді виглядають однаково: вузол перестворено, поводиться інакше, відтворити нічим. Далі розбираємо, як це закривається — шаблоном як єдиним джерелом правди, версіонуванням і перевірками під час перестворення.
Ефект від керованої конфігурації: швидкість і стійкість
Коли парк машин описано шаблонами й політиками, а не зібрано вручну за інструкцією, змінюється економіка експлуатації.
У Google Cloud конфігурація Compute Engine зберігається в шаблоні інстансу й групі керованих інстансів: правку вносять один раз, і під час наступного оновлення вона розходиться по всіх машинах без заходу на кожну.
Час виведення машини в роботу скорочується з годин до хвилин. Мережа, диски, мітки, доступ, агент моніторингу й стартовий набір пакетів приходять із шаблону — нова машина піднімається передбачувано однаковою.
Ручних операцій стає в рази менше: інженер розбирає завдання, а не повторює один і той самий набір налаштувань на кожній машині.
Стійкість парку машин тримається на групі: вона сама перевіряє стан екземплярів і замінює неробочий на новий із того самого шаблону. Так зникає цілий клас відмов — «машина жива, але налаштована інакше».
Доступ за ключами через єдиний каталог облікових записів закриває другий клас: ключі видаються й відкликаються централізовано, а не залишаються жити на машинах після звільнення інженера.
У практиці нашої команди розходження між машинами до переходу на керовану конфігурацію знаходили вже в момент збою — після вони спливають на етапі перевірки шаблону.
Оновлення парку йде хвилями із зупинкою в разі відхилення, а повернення до попереднього стану зводиться до попередньої версії шаблону.
Варіанти розгортання: одиночні машини, групи, шаблони
Варіанти розгортання в Compute Engine із Google Cloud відрізняються не стільки типом машини, скільки тим, хто відповідає за відновлення вузла. Одиночна віртуальна машина зручна як перший крок: розгорнули, налаштували, віддали трафік.
Але її стан живе тільки на ній — ручні правки накопичуються, а після збою вузол доводиться піднімати з пам’яті або за застарілою інструкцією.
Група керованих екземплярів прибирає цю зв’язку: еталон описано в шаблоні машини, а група тримає задану кількість вузлів і перестворює випалі.
Автоматичне відновлення екземпляра спрацьовує за перевіркою працездатності, але працює тільки там, де застосунок не зберігає унікальні дані локально.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Одиночна віртуальна машина | тестовий контур, рідко змінюваний сервіс, ПЗ із прив’язкою до конкретного вузла | автоматичного відновлення немає, конфігурація розходиться з документацією, простій на час перезапуску |
| Група керованих екземплярів, один шаблон | сервіси без локального стану: вебшар, API, обробники черг | екземпляр взаємозамінний, усе локальне втрачається під час перестворення |
| Група з рознесенням по зонах | продакшн із вимогою до доступності | більше вузлів, потрібен спільний шар зберігання стану |
| Група з автоматичним масштабуванням | змінне навантаження | масштабування йде за метрикою; шаблон на живій групі не змінюють — тільки нова версія й планове заміщення |
Що це означає для вибору
Шаблон машини — одиниця версіонування всієї конфігурації. Оновлення групи — нова версія шаблону й планове заміщення вузлів, відкат — повернення до попередньої версії, яка вже перевірена.
Тому перехід від одиночної машини до групи — не переписування, а перенесення вже працюючих налаштувань у шаблон і підключення перевірок.
Налаштування за кроками: від аудиту проєкту до передачі регламентів
Налаштування Compute Engine іде від інвентаризації до регламентів: складання поверх необстеженого проєкту успадковує чужі права, осиротілі диски й конфігурацію, яку ніхто не наважується чіпати.
Етапи нижче йдуть у тому порядку, у якому виконуються в проєкті — кожен спирається на результат попереднього, а не на здогадки.
- Аудит хмарного проєкту. Інвентаризуємо інстанси, диски, снапшоти, підмережі, правила доступу й облікові записи. Невикористовувані ресурси прибираємо, права, видані «на час», звужуємо до справді потрібних ролей.
- Схема інфраструктури. Узгоджуємо кількість зон, склад груп керованих інстансів (MIG) і межі між тестовим і промисловим середовищами — до того, як створено перший ресурс. Схема фіксується як документ, за яким потім звіряють факт.
- Складання шаблону й груп. Шаблон інстансу стає версіонованим артефактом: базовий образ, диски, мережеві мітки, склад прав. Доступ через SSH — через OS Login із корпоративними обліковими записами замість ключів, розкладених по метаданих проєкту.
- Перевірка відмовостійкості. Примусово виводимо з ладу зону й окремий інстанс: фіксуємо, за який час група відновлює робочі вузли й чи повертається трафік без ручного втручання.
- Обкатка оновлень і відкату. Проганяємо почергову заміну інстансів з лімітом на недоступні й перевіряємо повернення на попередній шаблон — відкат має займати хвилини, а не вимагати перезбирання групи.
- Передача регламентів. Віддаємо схему, конфігурації, політики доступу, інструкції з типових операцій і порядок дій у разі збою, розбираємо їх із командою замовника.
Що залишається у вас: шаблони, політики, схеми, регламенти
Інфраструктура залишається у вас у вигляді коду й документів, а не у вигляді інженера, який пам’ятає, де що натиснути.
Усе, що ми налаштовуємо в Google Cloud Compute Engine — шаблони машин, групи керованих інстансів, OS Login і політики доступу — лежить у вашому репозиторії й розгортається відтворювано.
- Шаблони машин: образ, тип диска, метадані, health check і стартовий скрипт описані декларативно — нова версія проходить рев’ю як звичайний код.
- Політики доступу: ролі IAM за сервісними акаунтами, вхід через OS Login замість статичних ключів, розділення проду й стейджу, список винятків з обґрунтуванням.
- Схема інфраструктури: мережа, підмережі, правила файрвола, балансувальник, розподіл по зонах і ліміти — в одному файлі, читабельному без нас.
- Документація на інфраструктуру: що де живе, які змінні задаються на вході, як підняти середовище з нуля й як коректно його знести.
- Регламент експлуатації: порядок викату нової версії, відкату, оновлення образів і ротації доступів — із зазначенням, хто це робить.
- Алерти й дашборди: метрики групи інстансів, доступність сервісу, помилки на старті — із прив’язкою до відповідального.
- Журнал перевірок: які сценарії прогнано (втрата зони, деградація інстансу, переповнення диска) і що підтверджено на стенді.
Типовий реліз, масштабування й відкат ваша команда робить за регламентом, без нас. Ми підключаємося, коли змінюється архітектура або потрібна допомога з розбором інциденту.
Кейс: парк машин перестав вимагати ручних правок
Парк із шістдесяти машин у трьох зонах обслуговувала одна команда, і кожна правка йшла вручну: образ збирали на місці, доступ видавали ключами, розкладеними по машинах, оновлення котили по одній через консоль.
Заміна заваленого інстансу займала вечір — підняти зі знімка, доправити конфіги, повернути в балансувальник, перевірити застосунок. Найгірше було з дрейфом: через місяць після релізу частина машин у зонах уже відрізнялася від еталона, і ніхто не міг сказати, чим саме.
| Метрика | До | Після |
|---|---|---|
| Час відновлення машини | 3-4 години ручного складання | 6-8 хвилин із шаблону |
| Частка ручних операцій під час зміни складу парку | близько 80% | менше 5% |
| Викат нової версії образу на весь парк | два вечори | 25 хвилин без простою |
| Розходження конфігурації між зонами | на 12-15 машинах | немає, конфігурація йде з шаблону |
Що змінили: шаблон інстансу став єдиним джерелом істини й версіонується в репозиторії, а самі машини збираються групою керованих інстансів із розподілом по зонах.
Політика почергового оновлення виводить із роботи частину машин за раз, перевірки здоров’я знімають нездоровий інстанс і перестворюють його замість ручного лікування.
Доступи перевели на вхід за корпоративними обліковими записами з ролями — ключі на машинах більше не зберігаються, а під час звільнення співробітника обліковий запис вимикається в каталозі, і доступ зникає разом із нею.
Відкат тепер теж інженерна операція, а не пошук «тієї самої» копії образу: повертаємо попередню версію шаблону й запускаємо оновлення групи. Усе це штатні механізми Google Cloud, тому не з’являється самописних надбудов, які потрібно супроводжувати.
Ручні операції з щоденної роботи перейшли в разові — погодження нової ролі або правку шаблону, — і саме це скоротило частку ручної праці на порядок.
Чим група керованих машин відрізняється від одиночної?
Одиночна машина — це один екземпляр із фіксованими параметрами, який живе, доки не зупиниться сам або не відмовить залізо. Поки навантаження рівне, схема працює: передбачувана конфігурація, мінімум рухомих частин, усе видно в одному місці.
Проблема в тому, що будь-яке перезавантаження, оновлення ядра або збій диска перетворюється на ручну операцію — підняти, перевстановити, повернути налаштування, знову ввести в балансування.
Група керованих машин прибирає цей клас робіт завдяки шаблону екземпляра й декларації розміру.
Ви описуєте, як має виглядати машина, скільки їх потрібно і яким правилом перевіряти стан; далі автовідновлення саме перестворює випалий вузол за шаблоном, а не «лікує» його на місці — конфігурація не розходиться з часом.
Масштабування парку працює як продовження тієї самої логіки: під час зростання черги або завантаження додаються вузли, під час спаду зайві прибираються.
Відмовостійкість досягається не надійністю окремого сервера, а тим, що втрата вузла не змінює ємність групи — трафік перерозподіляється на решту, поки піднімається новий.
Ціна рішення теж зрозуміла: потрібні шаблон, перевірки стану, доступи через OS Login і стратегія оновлень, щоб прогін не зносив весь парк разом. Якщо навантаження постійне й простій допустимий за регламентом, одиночна машина дешевша в підтримці. Щойно з’являється вимога «сервіс не падає на піку», група окупається вже на першому інциденті.
Технічні сумніви перед стартом робіт
Інженерні сумніви перед стартом — не про довіру, а про ризик: сервіси вже працюють і обслуговують користувачів, тому помилка в конфігурації видна одразу.
Розбираємо три питання, які задають найчастіше під час переходу на керовані шаблони в Google Cloud, і те, як ми на них відповідаємо.
Межі варто зафіксувати до початку робіт: що вважаємо успіхом, який запас за ресурсами тримаємо, хто підтверджує зміни в production. Це дешевше, ніж переглядати домовленості, коли половину вузлів уже замінено.
Як перевести працюючі сервіси без простою?
Нова версія шаблону розкочується на групу керованих інстансів поступово, з обмеженням на кількість машин, які одночасно замінюються. Поки вузол не пройшов перевірку здоров’я, трафік на нього не йде — старі продовжують відповідати. Відкат — повернення попередньої версії шаблону, а не відновлення з резервної копії.
Який доступ до проєкту вам потрібен?
Ролі видаються на рівні проєкту, вхід — через OS Login за корпоративними обліковими записами: постійні SSH-ключі не зберігаємо, кожна дія потрапляє в журнал.
Якщо політика вимагає ізоляції, працюємо в окремому проєкті або через виділений службовий обліковий запис із мінімальним набором прав.
Що робити зі спадщиною ручних налаштувань?
Спочатку інвентаризація: що налаштовано вручну, що вже описано кодом. Ручні правки фіксуємо й переносимо в шаблон, а прямі зміни на працюючих машинах закриваємо — інакше черговий розкат їх затре й розходження повернеться.
Як перевіряємо, що нічого не відвалиться?
Першим ділом піднімаємо копію production: на ній проганяємо шаблон, правила доступу й перевірки здоров’я, порівнюємо метрики й логи з поточними. Тільки після цього запускаємо першу хвилю реальних вузлів, не чіпаючи решту.
Обговоримо задачу: що потрібно для оцінки й плану
Оцінка робіт з інфраструктури рахується за межами змін, а не за кількістю ресурсів. Щоб повернутися з планом впровадження й розбивкою етапів, достатньо вхідних даних щодо проєкту нижче — решту уточнимо в листуванні або на короткому дзвінку.
- Структура проєктів і розділення середовищ: які середовища існують окремо, хто власник і хто видає доступи.
- Мережевий контур: топологія підмереж, вихід назовні, балансувальники й правила зв’язності між сервісами.
- Образи й шаблони інстансів: чим збираються, де зберігаються, хто і як оновлює базовий образ.
- Групи інстансів Compute Engine: зональні чи регіональні, які метрики керують масштабуванням, як налаштовані перевірки здоров’я й порядок заміни машин.
- Доступи інженерів: як потрапляють на хости, де ведеться облік ролей і ключів, чи потрібен журнал входів для аудиту.
- Поточний стан: що вже описано декларативно, що створено вручну, чи є файл стану й контроль версій.
- Обмеження: допустиме вікно змін і час простою, вимоги до відмовостійкості й резервного копіювання.
Якщо частина пунктів поки без відповіді — це нормально, прогалини теж увійдуть у план як окремі етапи. Опишіть задачу словами: що працює зараз і що має вийти на виході. Ми повернемося з оцінкою робіт, планом впровадження й списком питань, які потрібно закрити до старту.
Наступний крок — розмова по суті: звіримо очікування, зафіксуємо обсяг і порядок викату, щоб перша зміна в production була передбачуваною.
