Различия Azure Resource Manager и Azure 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), удобно масштабировать… и, и, и.
Сразу пример. Рассмотрим простую и понятную архитектуру многоуровневого приложения на следующей схеме.
В данном случае у нас имеется открытый и доступный пользователям Frontend Tier, бизнес-логика приложения в Application Tier и старый-добрый Backend Tier, который мы не забываем часто и корректно бэкапить.
Сразу отмечу, для того, чтобы произвести те или иные действия в рамках подписки, существует целый букет возможностей. Создание, модификация и удаление средств и сервисов Azure сейчас поистине широк. Помимо привычного 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.
Для обеспечения доступа интернет-пользователей к «верхнему», frontend уровню, создается Application Gateway со всеми параметрами, как frontend ip, backend address pools, зависимости и многое другое. Почитать про настройку Application Gateways рекомендую дополнительно, например в Application Gateways Docs, или, хотя бы, вдумчиво просмотреть представленный шаблон. Подробное описание настройки шлюза, чудес Load Balancer и Traffic Manager, Route Tables я рассказывать в этот раз не возьмусь — подробно об этом во следующей части.
Отмечу, что, раз уж мы заговорили о развертывании напрямую через REST API, при необходимости внести модификации в архитектуру — изменить какие-либо параметры, или добавить новые элементы (сеть, подсеть, да что угодно). Вам достаточно внести изменения в уже использованный шаблон. Это не значит, что вся с любовью расписанная махина будет повторно развернута и съест отдельную порцию ресурсов. Система умна и будет отслеживать лишь измененные куски кода и произведет любое CRUD действие оптимальным образом.
Итак, первый шаг сделан. Доработки, внедренные в ARM, выглядят вполне логичным и нужным продолжением предыдущих версий, и откровенных косяков пока не видно. Новый web-портал достаточно быстро перестал пугать, а решения по модификации уже работающих решений выглядят вполне дружелюбно. Очень надеюсь на конструктивные отзывы и скорое продолжение. Спасибо вам!
