Налаштування GCP Cloud Run: деплой контейнерів із CI/CD та VPC

Налаштування Cloud Run: де ламається розгортання контейнерів

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

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

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

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

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

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

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

Розбираємо, як це закривається — від декларативного опису сервісів до перевірок перед перемиканням трафіку.

Що дає керований запуск контейнерів

Керований запуск контейнерів — це коли платформа сама тримає ревізії, розподіляє трафік між ними та піднімає екземпляри під навантаження, а команда описує лише образ, змінні середовища та ліміти.

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

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

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

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

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

Межі задають заздалегідь — ліміт екземплярів, конкурентність на один екземпляр, таймаути, обсяг пам’яті; інакше сервіс упирається в ліміти зовнішньої бази або квоти проєкту й починає віддавати помилки на піку.

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

Внутрішні адреси та службові облікові записи перестають бути доступними ззовні, а права зводяться до конкретних ролей для конкретних сервісів.

Варіанти розміщення: сервіс, завдання, віртуальні машини

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

Тому режим розміщення контейнерів обирають не за звичкою, а за профілем навантаження — від цього залежить і архітектура, і те, які відмови взагалі можливі. У Cloud Run таких режимів три, і вони не взаємозамінні.

Як обираємо на практиці

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

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

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

Етапи налаштування: від аудиту до передачі в підтримку

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

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

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

Комплект передачі: конфігурації, схеми, регламенти

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

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

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

Кейс: прибрали простої під час оновлення сервісу

Сервіс із піковим трафіком жив на кількох віртуальних машинах за балансувальником. Оновлення запускали вночі в ручному вікні: інженер по черзі зупиняв екземпляри, піднімав нові та слідкував за логами.

До переїзду випуск займав 40–50 хвилин, і майже кожна п’ята спроба закінчувалася відкатом — зазвичай через несумісну міграцію схеми. Якщо оновлення ламало сервіс у години навантаження, відновлення розтягувалося на 20–30 хвилин ручних дій під тиском.

Перевели запуск на керовані контейнери Cloud Run. Образ складається конвеєром за кожного злиття в основну гілку, а нова ревізія отримує трафік лише після проходження перевірок готовності.

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

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

Результат у цифрах

Після переїзду випуск займає 6–8 хвилин, частка невдалих оновлень знизилася з 20% до 5%, а відновлення — секунди замість півгодини. Нічні вікна прибрали: випускаємо в робочі години по кілька разів на тиждень, і кожне викочування видно в історії ревізій із точною версією образу.

Що робити, якщо частина сервісів уже працює в хмарі

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

Спочатку будуємо мережевий міст: приватне з’єднання між майданчиками, неперетинні діапазони адрес, маршрути до внутрішніх сервісів в обидва боки.

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

Сервіс у Cloud Run бачить базу й внутрішні API так само, як бачив їх на попередньому розміщенні, — переписувати код під новий контур не доводиться.

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

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

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

Відкат перевіряємо до перемикання: поки трафік можна повернути за хвилини, перенесення йде спокійно.

Технічні сумніви: доступ, масштабування, відкат

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

Як обмежується внутрішній трафік між сервісами?

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

Як відкочується невдала версія?

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

Облікові записи середовищ розділяються?

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

Що відбувається під час оновлення працюючого сервісу?

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

Обговоримо задачу: зберемо схему та план впровадження

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

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

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