Serverless у GCP: налаштування Cloud Functions з IAM і Secret Manager

GCP Cloud Functions налаштування: де ламається бойовий контур

Налаштування GCP Cloud Functions зазвичай проходить гладко на демо й ламається на бойовому контурі. Функція розгортається під сервісним акаунтом із надто широкими правами — так швидше на старті, — і через пару місяців ніхто вже не скаже, до яких бакетів і таблиць у неї є доступ.

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

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

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

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

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

Що змінюється після впровадження: вимірювані ефекти

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

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

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

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

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

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

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

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

Окремо зникає клас відмов, пов’язаний з витоком облікових даних через артефакти збірки та логи, і відмови через ручне редагування конфігурації на сервері.

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

Режими розгортання функцій: порівняння підходів

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

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

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

Етапи робіт: від аудиту конфігурації до передачі

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

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

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

Що залишається у замовника після передачі контуру

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

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

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

Кейс: перевели моноліт на функції без простою

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

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

Як переносили

Розбили моноліт за доменами й винесли кожен в окрему функцію за спільним маршрутизатором: старі обробники залишалися робочими, поки трафік перемикався частками — 5, 25, 50, 100%.

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

Інфраструктуру розгортали на Google Cloud і описали декларативно — нове середовище піднімається однією командою, без ручного налаштування.

Що отримали на виході

Час викладки скоротився з 40 хвилин до 4: викатка йде автоматично, без ручних кроків і чергування біля консолі. Частка помилок на реліз упала з 3,1% до 0,4% — основну частину відмов давали спільні ключі й розбіжності між середовищами, які зникли разом із ручним налаштуванням.

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

Чим безсерверні функції відрізняються від постійних сервісів?

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

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

Передбачуваність затримок розходиться першою. У функцій виклик після паузи проходить холодний старт: ініціалізація середовища, читання секретів із Secret Manager, перевірка прав через IAM.

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

Постійні з’єднання — друга точка розходження.

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

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

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

Технічні сумніви перед виводом у бойовий контур

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

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

Чому ключі не можна тримати в змінних середовища?

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

Чи буде простій під час зміни прав?

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

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

Як проходить ротація ключів без викатки нової версії?

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

Які обмеження платформи проявляться під навантаженням?

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

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

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

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

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

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

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