Увеличение масштаба инфраструктуры Azure DevTest Labs

Оркестрация успешной реализации DevTest Labs в масштабе предприятия требует рассмотрения ключевых точек принятия решений и планирования подхода к быстрому развертыванию и внедрению Azure DevTest Labs.

В этой статье описаны ключевые моменты принятия решений, которые следует учитывать при планировании реализации, и предоставляет рекомендуемый подход к развертыванию.

Ключевые моменты принятия решений

Прежде чем реализовать DevTest Labs на корпоративном уровне, нужно решить некоторые важные вопросы. Общее понимание этих вопросов поможет организации принимать решения относительно проектирования в будущем. Однако эти моменты не должны помешать организации приступить к подтверждению концепции.

Ниже приведены три основных аспекта, с которых нужно начать планирование увеличения масштаба:

• Сетевые подключения и безопасность
• топология использования подписки;
• Роли и обязанности

Сетевые подключения и безопасность

Сетевые подключения и безопасность — это ключевые вопросы для всех организаций. Если развертывание на корпоративном уровне требует более глубокого анализа, то для успешного подтверждения концепции существует меньше требований. Несколько ключевых моментов, которым следует уделить внимание:

• Подписка Azure. Чтобы развернуть DevTest Labs, вам потребуется доступ к подписке Azure с соответствующими правами для создания ресурсов. Существует несколько способов получить доступ к подпискам Azure, включая подписки с соглашением Enterprise и оплатой по мере использования. Дополнительные сведения о получении доступа к подписке Azure см. на странице Лицензирование Azure для корпоративных пользователей.
• Доступ к локальным ресурсам. В некоторых организациях требуется, чтобы ресурсы в DevTest Labs имели доступ к локальным ресурсам. Вам потребуется обеспечить безопасное подключение из локальной среды к Azure. Перед началом работы важно установить и настроить VPN-подключение или подключение Azure ExpressRoute. Дополнительные сведения см. в статье о виртуальных сетях.
• Другие требования к безопасности. Прежде чем реализовывать подтверждение концепции, вам, возможно, также потребуется рассмотреть и другие требования к безопасности, например политики для компьютеров, доступ к общедоступным IP-адресам, подключение к Интернету и т. п.

топология использования подписки;

Топология использования подписки — важный аспект при планировании развертывания DevTest Labs в организации. Однако утверждать все решения до завершения подтверждения концепции не стоит. При оценке количества подписок, необходимых для внедрения в организации, можно прийти к двум противоположным решениям:

• использовать одну подписку для всей организации;
• использовать одну подписку на пользователя.

Ниже мы рассмотрим преимущества каждого подхода.

Одна подписка

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

• Прогнозирование затрат для предприятия. При использовании одной подписки планировать расходы становится гораздо проще, так как все ресурсы находятся в одном пуле. Такой подход упрощает принятие решений по проведению контроля расходов в любой момент времени в цикле выставления счетов.
• Упрощается управление виртуальными машинами, артефактами, формулами, конфигурацией сети, разрешениями, политиками и т. д., так как все обновления нужно выполнять только в одной подписке, а не в нескольких.
• При таком подходе сокращаются трудозатраты на обслуживание сети для организаций, где требуется возможность подключения к локальной среде. Для связи виртуальных сетей между разными подписками (звездообразная модель) требуются дополнительные подписки, а для них — дополнительные настройки, управление и диапазоны IP-адресов.
• Совместная работа в группе становится проще, если все работают в одной подписке. Например, это упрощает переназначение виртуальной машины коллегам, совместное использование ресурсов группы и т. д.

использовать одну подписку на пользователя.

Подход с отдельной подпиской для каждого пользователя обеспечивает свой набор преимуществ. Использование нескольких подписок обеспечивает такие преимущества:

• Квоты масштабирования Azure не будут препятствовать внедрению. К примеру, на момент написания этой статьи в Azure можно создать 200 учетных записей хранения на подписку. Для большинства служб Azure применяются квоты на число операций (многие из них можно настроить, но не все). В модели использования одной подписки на пользователя маловероятно, что большинство квот будет достигнуто. Дополнительные сведения о текущих квотах масштабирования в Azure см. в статье Подписка Azure, границы, квоты и ограничения службы.
• Взимание средств за использование для групп или отдельных разработчиков становится гораздо проще, что позволяет организациям учитывать затраты при использовании текущей модели.
• Упрощается владение и назначение разрешений в средах DevTest Labs. Вы предоставляете разработчикам доступ на уровне подписки, и они полностью отвечают за все, включая конфигурацию сети, политики лаборатории и управление виртуальными машинами.

Для компаний существует больше ограничений по максимальному и минимальному числу подписок. Поэтому необходимо настроить подписки таким образом, который будет представлять собой что-то среднее между этими подходами. Как правило, организациям рекомендуется минимизировать число используемых подписок. Помните о принудительных функциях, увеличивающих их общее количество. Еще раз отметим, что топология использования подписок очень важна для развертывания DevTest Labs в организации, но не должна препятствовать подтверждению концепции. Сведения о выборе подписок и степени структурированности лабораторий в организации см. в разделе об управлении инфраструктурой.

Роли и обязанности

Подтверждение концепции DevTest Labs предусматривает три первичные роли с определенными обязанностями — владелец подписки, владелец DevTest Labs, пользователь DevTest Labs и (при необходимости) участник.

• Владелец подписки может управлять подпиской Azure, в том числе назначать пользователей, управлять политиками, создавать и администрировать топологии сети, запрашивать увеличения квоты и т. д. Дополнительные сведения см. в этой статье.
• Владелец DevTest Labs имеет полный административный доступ к лаборатории. Этот пользователь отвечает за добавление и удаление пользователей, управление параметрами затрат, общие параметры лаборатории и другие задачи, связанные с артефактами или виртуальными машинами. Владелец лаборатории также имеет все права пользователя DevTest Labs.
• Пользователь DevTest Labs может создавать и использовать виртуальные машины в лаборатории. Эти пользователи имеют минимальные права администрирования (запуск, приостановление, удаление и настройка виртуальных машин) для виртуальных машин, которые они создают. Они не могут управлять виртуальными машинами других пользователей.

Планирование внедрения DevTest Labs

В этом разделе представлен рекомендуемый подход к быстрому развертыванию и реализации Azure DevTest Labs. На следующем изображении поэтапно представлен весь процесс, который гибко поддерживает различные сценарии и отраслевые требования.

Предположения

В этой статье предполагается, что перед реализацией пилотного проекта DevTest Labs у вас подготовлены следующие компоненты:

• Подписка Azure. Команда пилотного проекта имеет доступ к развертыванию ресурсов в подписке Azure. Если единственными рабочими нагрузками является разработка и тестирование, рекомендуется выбрать предложение Enterprise DevTest, чтобы получить дополнительные образы и более низкие тарифы для виртуальных машин Windows.
• Локальный доступ. Если необходимо, локальный доступ уже должен быть настроен. Локальный доступ может осуществляться через VPN-подключение типа "сеть —сеть" или через ExpressRoute. Установка подключения через ExpressRoute обычно может занять несколько недель. Рекомендуется развернуть ExpressRoute перед запуском проекта.
• Команды пилотных проектов. Уже должна быть определена первоначальная команда разработчиков проекта, которая использует DevTest Labs, а также установлены действия для разработки и тестирования и согласованы требования, цели и задачи для этих команд.

Веха 1. Определение начальной топологии сети и разработка

Первой основной задачей при развертывании решения Azure DevTest Labs является установка запланированного подключения для виртуальных машин. Ниже приведены необходимые процедуры:

1. Определите начальные диапазоны IP-адресов, которые будут назначены подписке Azure DevTest Labs в Azure. На этом шаге нужно спрогнозировать ожидаемое использование (в количестве виртуальных машин), чтобы вы могли обеспечить достаточно большой блок для будущего расширения.
2. Определите методы необходимого доступа в DevTest Labs (например, внешний или внутренний доступ). Ключевой момент на этом шаге — определить, имеют ли виртуальные машины общедоступные IP-адреса (то есть, доступны из Интернета напрямую).
3. Идентифицируйте и установите методы подключения к остальным облачным и локальным средам Azure. Если включена принудительная маршрутизация с помощью ExpressRoute, вполне вероятно, что виртуальным машинам понадобятся соответствующие конфигурации прокси-сервера для прохождения через корпоративный брандмауэр.
4. Если виртуальные машины должны быть присоединены к домену, определите, присоединяются ли они к облачному домену (например, службам каталогов Microsoft Entra) или локальному домену. Для локальной среды определите, какая подразделение (подразделение) в Active Directory присоединяется к виртуальным машинам. Кроме того, убедитесь, что пользователи имеют право на присоединение, или создайте учетную запись службы, которая может создавать записи компьютера в домене.

Веха 2. Развертывание лаборатории пилотного проекта

Когда сетевая топология будет настроена, можно создать первую или экспериментальную лабораторию, выполнив следующие действия:

1. Создайте начальную среду DevTest Labs.
2. Определите допустимые образы виртуальных машин и их размеры для использования в лаборатории. Решите, можно ли отправлять пользовательские образы в Azure для использования с DevTest Labs.
3. Безопасный доступ к лаборатории путем создания начального управления доступом на основе ролей Azure (Azure RBAC) для лаборатории (владельцев лаборатории и пользователей лаборатории). Рекомендуется использовать синхронизированные учетные записи Active Directory с идентификатором Microsoft Entra для идентификации с DevTest Labs.
4. Настройте в DevTest Labs использование политик, например расписания, управления затратами, запрашиваемых виртуальных машин, пользовательских образов или формул.
5. Создайте онлайн-репозиторий, например Azure Repos/Git.
6. Решите, какие репозитории использовать: общедоступные, частные или комбинируемые. Упорядочите шаблоны JSON для развертывания и долгосрочной поддержки.
7. Создайте настраиваемые артефакты, если это необходимо. Этот шаг необязательный.

Веха 3. Документация, поддержка, обучение и улучшения

Для начала работы командам пилотных проектов может потребоваться глубокая поддержка. В процессе работы команд предоставляйте им подходящую документацию и поддержку для продолжения развертывания Azure DevTest Labs.

1. Предоставьте командам пилотных проектов новые ресурсы DevTest Labs (демонстрации, документация).
2. Исходя из продвижения команд пилотных проектов, планируйте и предоставляйте документацию по мере необходимости
3. Формализация процесса подключения новых команд (создание и настройка лабораторий, предоставление доступа и т. д.)
4. Основываясь на первоначальном использовании, убедитесь, что исходный прогноз пространства IP-адресов по-прежнему разумный и правильный.
5. Убедитесь, что были выполнены соответствующие проверки обеспечения соответствия и безопасности.

Следующие шаги

Перейдите к следующей статье этой серии: Governance of Azure DevTest Labs infrastructure - Resources (Система управления инфраструктурой Azure DevTest Labs. Ресурсы).