Відмінності Azure Resource Manager і Microsoft Service Manager — погляд розробника

Висловлюємо подяку за підготовку статті Михайлу Тряхову (@PerseptronYar з компанії Akvelon (Ярославль) за допомогу в написанні цієї статті. Михайло працює в команді розробників Microsoft Azure CLI (Command Line Interface) зі спеціалізацією на Networking Services.
Всім привіт!

C 2008 року ті з нас, хто працював з Azure, можливо, самі того не знаючи, використовували так званий режим ASM (Azure Service Manager), який тепер називається класичним. Платформа Azure між тим росла, розвивалася, породила безліч корисних сервісів, підтримку нових платформ і багато ще чого доброго. Із зростанням підтримуваних і все більш ускладнюються архітектур компонентів назріло цілий ряд змін, який вирішено було винести в окремий комплекс — ARM (Azure Resource Manager). У цій статті я поділюся деякими моментами, з якими стикаєшся, освоюючи дану платформу. Але спочатку згадаємо, що ж такого серйозно нового воно нам несе.




Перше, що кинеться в очі менше хардкорним читачам, які, як і раніше, використовують веб-версію порталу управління Azure, це сам портал, змінений як за формою, так і за змістом. Нова версія в даний момент інтенсивно допрацьовується і вже зараз дозволяє виконувати зручним чином більшість необхідних дій. Що стосується usability — не буває докорінної зміни структури сайту, що б відразу різко порадувала користувачів. Деякі складності при виконанні звичних дій обов'язково виникнуть. Тому підтримка обох версій сайту в найближчій перспективі — крок з боку Microsoft логічний і досить лояльний.

Зміни настають і у Azure Service Management API. Колишні портали *.windowsazure.com працюють через API, властивий класичному режиму, нові ж, ARM-івські, портали *.azure.com використовують вже новий API, на деталях якого ми і зосередимося. Вводиться поняття типу ресурсу (resource type) і відповідного йому API. Виртаульной машині — своє, базі даних — своє. Детальніше новий REST API ми подивимося трохи пізніше, поки ж торкнемося трохи більш суттєвих відмінностей.

Адже таке нововведення б'є по дуже обтяжливого недоліку в роботі з класичним API. Перш ми радісно могли створити все, що душі завгодно, від blob-a до web-сайту. Але біль починалася вже на наступному етапі — етапі роботи з безпекою, бо кожен елемент конфигурировался окремо. Не було можливості, наприклад, одноманітно вказати доступ до скопу виртуалок, або встановити схожі порядки в доступі до web-сайту і його сервісів, базі даних. Робота з ролями теж якась кастрированная — у підписки є адмін і адміни. Всі! Ніякої security matrix, розподілу ролей. Такий ось багаторічний танець навколо одного і того ж стовпа.
ARM дозволяє створювати групи ресурсів (resource groups), в рамках яких створювати потрібні сукупності додатків, сервісів і баз даних. Тепер має місце бути триступенева ієрархія — передплата (як корінь усього), група ресурсів і ресурс. Всі вони використовують модель авторизації RBAC (role based access control), які мають довгоочікуваний скоп ролей (включаючи owner, contributor та ін) з відповідними правами доступу (Access Control List, приклад подивимося нижче).



Ресурси можуть (і, за задумом творців, повинні) бути позначені тегами. Створені ресурси можуть розподілятися по групам і тегам згідно функціоналу, який вони несуть, фільтруватися по використовує їх продуктів, відповідальним співробітникам і департаментам компанії… Це дозволяє ще більш ефективно групувати і систематизувати ресурси, візуалізувати розподіл трафіку і проводити аналіз вироблених витрат. Це дозволяє більш очевидним чином оптимізувати витрати на підтримку роботи розгорнутої архітектури і хоч де-то вже, нарешті, заощадити.

Існує цілий ряд ситуацій, коли сгруппированность декількох ресурсів спрощує їх однакову модифікацію. Найпростіше, як водиться, все видалити. Але більш конструктивними кейсами є визначення політики безпеки, налаштування ip-адрес, балансування і, як ми побачимо у цій та наступних статтях, багато іншого. На практиці засоби Azure ASM і ARM режимах використовуються цілком схожим чином і розходяться лише в незначних деталях. Переучуватися і довго, з обережністю мігрувати всі свої багаторічні напрацювання, благо, не доведеться. Вже існують стандартизовані гібридні рішення для безболісного і швидкого об'єднання вже розроблених, класичних, і on-premises рішень — про це вже скоро на хабре.
Для початку поговоримо про використання Azure Networking Services. Як вже розповідалося в інших статтях, Networking Services дозволяють створювати свої віртуальні мережі, в яких користувач управляє місцем розташування (location) мережі, безпека (security groups), підмережами (subnets), конфігураціями (NIC, VMs), зручно масштабувати… і, і, і.

Відразу приклад. Розглянемо просту і зрозумілу архітектуру багаторівневого додатки наступною схемою.

MultiTier Application

В даному випадку у нас є відкритий і доступний користувачам Frontend Tier, бізнес-логіка програми в Application Tier і старий-добрий Backend Tier, який ми не забуваємо часто і коректно бэкапить.
Відразу зазначу, для того, щоб виробити ті чи інші дії в рамках підписки, існує цілий букет можливостей. Створення, модифікація і видалення засобів і сервісів Microsoft зараз справді широкий. Крім звичного web-порталу, Azure PowerShell, REST API ви також можете використовувати активно дорабатываемая на момент написання статті платформа Azure CLI. Реалізується вона на Node.js проект з відкритим кодом, що, як Ви напевно розумієте, що дає можливість повноцінно використовувати на Windows, Mac і багатьох дистрибутивах Linux.

З тих матеріалів, що я вивчив при підготовці до написання цієї статті, я зрозумів, що найбільш наочним вважається варіант з використанням REST API. Зводиться він до створення шаблонів (template) в JSON-форматі, що містить всю необхідну інформацію. Природно, вже існує ціла галерея подібних шаблонів для розгортання подібної архітектури. Обраний варіант, найбільш відповідний під бажання користувача, кастомізіруєтся і засобами, наприклад, Visual Studio розгортається у вашої підписки.

Неважко здогадатися, що і платформи PowerShell, Azure CLI роблять ні що інше, як формують ті ж самі JSON-и, але з плюшками у вигляді підказок, валідації, обмежень, які дозволять розгорнути бажане з найменшою болем для нашого брата.

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

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

Отже, для реалізації подібної схеми засобами Azure, необхідно створити віртуальну мережу, в якій для кожного з описаних рівнів створюються підмережі. Наступним кроком буде настройка прав доступу. Для цих цілей ми звернемося до Network Security Groups. NSG забезпечують в мережі доступ (або його відсутність) до конкретних віртуальним машинам або цілим подсетям. Вони містять набір правил ACL (той самий Access Control List) для дозволу або відмови в доступі до зазначеної області. За замовчуванням створюється цілий ряд inbound/outbound правил, які дозволяють покрити істотний шматок області застосування security groups. Azure надає засоби для вказівки всіх необхідних налаштувань безпеки на кожному рівні. Зокрема, у наведеному мною шаблоні ми можемо виділити, як з допомогою завдання правила обмежується доступ до рівня даних – прямо і чітко написано "access": "denied". Завдання правил проводиться досить очевидним чином, і я пропоную вивчити деякі способи їх кастомізації хоча б на нашому прикладі самостійно.

Network security groups — чудова річ, крім вищесказаного, включає в себе і зручні логгер різних типів, що дозволяє швидко і безболісно оцінити виниклі проблеми при використанні створеної архітектури, зловити і втопити сховану неточність. Користувач може всебічно проаналізувати статистику звернень до даної групи. Все це обнадіює. Деякий ряд дій записується за замовчуванням, але є можливість включити "додаткове" логгирование в рамках даної Network Security Group — відкриється куди більш широкий спектр інформації, що зберігається. Підключені логи дозволять у деталях подивитися всі необхідні дані за зверненнями до пов'язаних з NSG ресурсів. Це може сильно допомогти в налагодженні, особливо на перших етапах формування архітектури. Як ці радості роздобути, що сказати і куди подивитися — описано в документації Log analytics for NSGs.

Analyze logs using Power BI

Для забезпечення доступу користувачів інтернету до «верхнього», frontend рівня, створюється Application Gateway зі всіма параметрами, як frontend ip, backend address pools, залежності і багато іншого. Почитати про налаштування Application Gateways рекомендую додатково, наприклад Application Gateways Docs, або, хоча б, вдумливо переглянути представлений шаблон. Докладний опис установки шлюзу, чудес Load Balancer і Traffic Manager, Route Tables я розповідати в цей раз не візьмуся — докладно про це в наступній частині.

Зазначу, що, раз вже ми заговорили про розгортання безпосередньо через REST API, при необхідності внести модифікації у архітектуру – змінити які-небудь параметри, або додати нові елементи (мережа, підмережа, та що завгодно). Вам достатньо внести зміни у вже використаний шаблон. Це не означає, що вся з любов'ю розписана махіна повторно розгорнута і з'їсть окрему порцію ресурсів. Система розумна і буде відслідковувати лише змінені шматки коду і зробить будь CRUD дія оптимальним чином.

Отже, перший крок зроблено. Доопрацювання, впроваджені в ARM, виглядають цілком логічним і необхідним продовженням попередніх версій, і відвертих косяків поки не видно. Новий web-портал досить швидко перестав лякати, а рішення щодо модифікації вже працюючих рішень виглядають цілком дружелюбно. Дуже сподіваюся на конструктивні відгуки та швидке продовження. Спасибі вам!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.