GCP

Ієрархія, що успадковується, і дешева межа

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

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

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

Сервісні акаунти — це шлях усередину

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

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

Глобальна мережа й де платформа справді попереду

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

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

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

Як це виявляється в реальній поставці

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

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

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

Де це вироджується

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

Коли це застосовувати

Пов’язані сторінки

• ІнфраструктураAWSAWS — це хмарна платформа Amazon і найстарша з великих хмар, і це видно у двох речах: у неї найбільше сервісів, і вона змушує розібратися з правами доступу, перш ніж дозволить зробити щось корисне. Це той самий факт: неявно не дозволено нічого, а акаунт — єдина межа, що справді стримує помилку. На цій сторінці — як насправді авторизується запит, чому кілька акаунтів є типовою відповіддю на ізоляцію, чим ви торгуєте, підіймаючись драбиною керованих сервісів, і які рядки роблять рахунок несподіванкою.
• ІнфраструктураAzureAzure — це хмара Microsoft, і перше, що варто про неї знати: у ній дві системи керування, які сприймають як одну, а вони не одна. Каталог тримає ідентичності й існував задовго до хмари — це той самий каталог, що стоїть за корпоративною поштою й входом у систему. Окремий ресурсний план тримає підписки, групи ресурсів і все, що ви розгортаєте. Бути адміністратором першого не дає нічого в другому. На цій сторінці — цей поділ і чому він спричиняє плутанину першого дня, ланцюг областей, яким успадковуються права, де Azure справді є правильною відповіддю і чого платформа коштує вам у мінливості назв.
• РозробкаNoSQLNoSQL — це парасолькова назва, яка окреслює чотири різні види баз даних через те, чим вони не є, — і саме тому вибір так часто роблять погано. Спільне в них корисніше за те, чого їм бракує: дані розміщуються на вузлі за ключем, який ви обираєте, тож саме цей ключ вирішує, які запити дешеві, які дорогі, а які неможливі. На цій сторінці — чотири сімейства, до чого насправді зобовʼязує ключ партиціювання, що означає «зрештою узгоджено» для ваших користувачів і коли реляційна база досі є правильною відповіддю.