Из названия хаба можно понять что я работаю в компании EPAM Systems. Уже более 3х лет наша компания использует собственный Private Cloud(EPC). Здесь вы можете найти более детальную информацию о нем.

В последнее время наше облако активно сдвигается в сторону гибридного облачного решения.

Ввиду большого количества людей и команд, работающих в нашей компании, возникает вопрос об управлении проектными ресурсами. Я имею в виду создание изолированного окружения, консолидированный аудит, консолидированный биллинг, многоуровневую аналитику.

Disclaimer. Данная статья не является каким-то рабочим мануалом или рекламой. В ней я попытаюсь описать одну из проблем, с которой наша команда столкнулась во время интеграции с Azure. Заранее спасибо за фидбеки, если будут интересные предложения, обязательно систематизирую и выложу тут или в отдельной статье.


Технические требования при интеграции с Azure:

• унифицированное управление ресурсами Azure при помощи существующих инструментов EPC(CLI/UI), котрые уже используются для управления ресурсами внутреннего облака и AWS
• интеграция с корпоративной системой контроля разграничения доступа и контроля квот
• разделение биллинга по проектам
• ежемесячный финансовый отчет об использованных ресурсах
• предоставление по запросу прямого доступа к Azure Management Console
• обеспечение максимально возможного аудита всех действий пользователей (как через EPC так и через Azure Web UI)

Ранее, мы успешно интегрировались с AWS. При этом для разделения ресурсов мы используем root и linked аккаунты (более подробно можно почитать здесь). После освоения интеграции с AWS было принято решение взяться за Azure.

Первый шаг — разработать принципы распределения доступа к проектным ресурсам, который усложняется необходимостью иметь возможность предоставления доступа к Azure Management Console.

Azure предполагает следующую схему управления доступом. Организация получает учетную запись типа Enterprise(enrollment), в рамках которой можно создать множество пользовательских учетных записей (accounts). В рамках учетной записи можно создать множество подписок. В рамках подписки владелец учетной записи является Service administrator'ом. Он может предоставить другому пользователю AD доступ к этой подписке, назначив ему роль Co-Administrator.



Azure предоставляет 2 варианта авторизации: LiveID и SSO (Single Sign On). Мы сразу забраковали LiveID ввиду корпоративных стандартов. Best Practice предлагает использовать одну учетную запись для проекта, а подписки использовать как environment'ы (DEV,QA,PRP,STAGE,etc). Т.к. было принято решение использовать SSO авторизацию, стало ясно, что для каждого проекта придется заводить отдельного пользователя в AD. Был предложен вариант использовать для этого существующих пользователей (например, пользователь менеджера проекта). Но мы сразу отказались от этого варианта из-за того, что человек может уйти на другой проект или вообще прекратить сотрудничество с компанией. Вариант заводить отдельного пользователя на проект тоже оказался не очень удобным, потому что где-то эти данные должны храниться и кто-то должен следить за их актуальностью. Кроме того, после создания учетной записи необходимо в ручном режиме создать подписку и импортировать в нее сертификат для авторизации при работе с Azure через API.

Поэтому было принято решение использовать для каждого проекта отдельную подписку. Таким образом, можно создать пул подписок, импортировать сертификат и при необходимости брать из пула готовую подписку и использовать её для нового проекта или как отдельный environment существующего проекта. Это так же позволит использовать API для назначения пользователям роли Co-Adminisctrator, которая дает прямой доступ к Azure Web UI.

Первый вопрос, который возник после выбора данного варианта — это ограничение по количеству подписок на один аккаунт. Т.к. на официальных сайтах ответа на этот вопрос найти не удалось, кроме того что за создание подписок не взимается никакой дополнительной платы, было принято решение попытаться создать пулл из 500 подписок.

Ввиду того, что нет возможности добавить подписку через API, мы при помощи java + selenium написали простенький кликер, который должен был создать эти подписки.

Итог

Поначалу создавалась 1 подписка в 60-90 секунд. Но после преодоления барьера в 50 подписок это время начало расти.
В районе 90+ на создание одной подписки уходило уже около 5 минут(±). На данный момент, создано около 150 подписок и среднее время создания новой подписки — 8 минут. Создание подписок продолжается.Соответственно возникает вопрос, что будет дальше.
В общем-то, именно этим и хотел поделиться. Если у кого-то есть подобный опыт — велкам в комментарии.

UPD.

После общения с специалистом из Microsoft удалось выяснилось что ограничений на количество подписок нет.
Но в целом вопрос остается открытым.