Azure

Каталог — це інший продукт, ніж хмара

Microsoft Entra ID — каталог, який раніше звався Azure Active Directory, — це місце, де живуть користувачі, групи й ідентичності застосунків. Він не є частиною Azure так, як нею є віртуальна машина: той самий каталог автентифікує корпоративну пошту, спільні документи й кожен інший сервіс Microsoft, яким користується організація, і чудово існує для компаній, які в Azure не тримають нічого. Azure додає до нього окрему систему прав — контроль доступу на основі ролей, — яка привʼязує ідентичність із каталогу до області в дереві ресурсів.

Звідси й перша плутанина, яку має майже кожен. Є два окремі набори ролей зі схожими назвами, і володіння одним не каже нічого про інший. Роль каталогу — Global Administrator, User Administrator — керує каталогом: створенням користувачів, керуванням групами, погодженням застосунків. Роль ресурсу — Owner, Contributor, Reader — керує речами в Azure: читанням бази, перезапуском віртуальної машини, видаленням групи ресурсів. Global Administrator за задумом може не бачити жодного ресурсу. Є свідомий крок підвищення, який дозволяє надати собі доступ по всьому дереву ресурсів, — і суть саме в тому, що це крок, а не наслідок.

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

Чотири області, і одна, що видаляє

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

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

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

Де Azure справді є правильною відповіддю

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

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

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

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

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

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

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

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

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

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

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

• ІнфраструктураAWSAWS — це хмарна платформа Amazon і найстарша з великих хмар, і це видно у двох речах: у неї найбільше сервісів, і вона змушує розібратися з правами доступу, перш ніж дозволить зробити щось корисне. Це той самий факт: неявно не дозволено нічого, а акаунт — єдина межа, що справді стримує помилку. На цій сторінці — як насправді авторизується запит, чому кілька акаунтів є типовою відповіддю на ізоляцію, чим ви торгуєте, підіймаючись драбиною керованих сервісів, і які рядки роблять рахунок несподіванкою.
• ІнфраструктураGCPGoogle Cloud (GCP) побудований навколо ієрархії, що успадковується: організація містить теки, теки містять проєкти, а проєкт містить усе решта. Це звучить адміністративно й водночас є найважливішою річчю на платформі, бо проєкт достатньо дешевий, щоб створити його під один сервіс, і достатньо цілісний, щоб видалити однією дією. На цій сторінці — ієрархія і що нею успадковується, чому сервісні акаунти є звичайним шляхом усередину, мережева модель, що різниться від усіх інших, і де платформа справді сильна, а де справді ні.
• ІнфраструктураCI/CDБезперервна інтеграція — це не сервер, що ганяє ваші тести, а звичка зливатися в одну спільну гілку достатньо часто, щоб конфлікти лишалися малими; автоматизація існує, щоб зробити цю звичку безпечною. Безперервна доставка — друга половина: один артефакт, зібраний один раз і просунутий середовищами без перезбирання. На цій сторінці — як упорядкувати етапи, чому нестабільний тест руйнує авторитет конвеєра, чим насправді торгують стратегії розгортання і які чотири числа кажуть, чи все це працює.