Эталонная архитектура Azure DevTest Labs на предприятии

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

• Локальное подключение через Azure ExpressRoute
• Шлюз удаленного рабочего стола для удаленного входа на виртуальные машины
• Подключение к частному репозиторию артефактов
• Другие компоненты платформы как услуги (PaaS), используемые лабораториями

Архитектура

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

Компоненты DevTest Labs

DevTest Labs позволяет предприятиям легко и быстро предоставлять доступ к ресурсам Azure. Каждая лаборатория содержит ресурсы типов "программное обеспечение как услуга" (SaaS), "инфраструктура как услуга" (IaaS) и PaaS. Пользователи лаборатории могут создавать и настраивать виртуальные машины, среды PaaS и артефактывиртуальных машин.

На предыдущей схеме Группа Team Lab 1 в подписке Azure 1 демонстрирует пример компонентов Azure, которые доступны лабораториям и могут использоваться ими. Дополнительные сведения см. в разделе Сведения о DevTest Labs.

Компоненты соединения

Если лабораториям необходим доступ к локальным корпоративным ресурсам, вам потребуется локальное подключение. Распространенные сценарии:

• Некоторые локальные данные невозможно переместить в облако.
• Вам требуется присоединить виртуальные машины лаборатории к локальному домену.
• Необходимо принудительно направить весь сетевой трафик через локальный брандмауэр для обеспечения безопасности или соответствия.

Эта архитектура использует ExpressRoute для подключения к локальной сети. Вы также можете использовать VPN типа "сеть-сеть".

В локальной среде шлюз удаленных рабочих столов делает возможными исходящие подключения по протоколу удаленного рабочего стола (RDP) к DevTest Labs. Корпоративные брандмауэры предприятия обычно блокируют исходящие подключения. Чтобы настроить подключение, выполните указанные ниже действия.

• Используйте шлюз удаленного рабочего стола и разрешите статический IP-адрес балансировщика нагрузки шлюза.
• Используйте принудительное туннелирование для перенаправления всего трафика RDP через подключение ExpressRoute или VPN типа "сеть — сеть". Принудительное туннелирование — это набор стандартных функций для развертываний DevTest Labs корпоративного уровня.

Сетевые компоненты

В этой архитектуре идентификатор Microsoft Entra предоставляет управление удостоверениями и доступом во всех сетях. Виртуальные машины лаборатории обычно используют для доступа учетную запись локального администратора. Если есть идентификатор Microsoft Entra, локальный или домен доменных служб Microsoft Entra, вы можете присоединить виртуальные машины лаборатории к домену. Затем пользователи могут использовать свои доменные удостоверения для подключения к виртуальным машинам.

Топология сети Azure управляет доступом со стороны ресурсов лаборатории и их взаимодействием с локальными сетями и Интернетом. Эта архитектура демонстрирует распространенный способ организации сети DevTest Labs. Лаборатории подключаются к одноранговым виртуальным сетям в звездообразной конфигурации с помощью ExpressRoute или VPN-подключения типа "сеть — сеть" к локальной сети.

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

Вопросы масштабируемости

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

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

  Существует две стратегии соблюдения ограничений группы ресурсов:

  • Все виртуальные машины должны находиться в одной группе ресурсов. Эта стратегия позволяет соблюсти ограничение на группу ресурсов, но затрагивает ограничение на количество ресурсов определенного типа в группе.
  • Используйте совместные общедоступные IP-адреса. Если виртуальным машинам разрешено использовать общедоступные IP-адреса, разместите все виртуальные машины одного размера и региона в одной группе ресурсов. Эта конфигурация обеспечивает соблюдение квот на группы ресурсов и квот на типы ресурсов в группе.

• Количество ресурсов на группу ресурсов для каждого типа ресурсов. По умолчанию ограничение на количество ресурсов на группу ресурсов для каждого типа ресурсов составляет 800. В конфигурации "Все виртуальные машины в одной группе ресурсов" этот предел достигается гораздо раньше, особенно если у виртуальных машин много дополнительных дисков.

• учетные записи хранения; Каждая лаборатория DevTest Labs поставляется с учетной записью хранения. Квота Azure для количества учетных записей хранения для каждого региона на подписку составляет 250 по умолчанию. Таким образом, максимальное количество DevTest Labs в одном регионе также составляет 250. При увеличении квоты можно создавать до 500 учетных записей хранения в каждом регионе. Дополнительные сведения см. в разделе "Увеличение служба хранилища Azure квот учетных записей".

• Назначения ролей. Назначение роли обеспечивает пользователю или субъекту доступ к ресурсу. Существует ограничение в 2000 назначений ролей на подписку.

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

• Операции чтения и записи API. Вы можете автоматизировать Azure и DevTest Labs с помощью интерфейсов REST API, PowerShell, Azure CLI и пакета SDK для Azure. Каждая подписка Azure позволяет создавать до 12 000 запросов на чтение и 1200 запросов на запись в час. Автоматизируя DevTest Labs, вы можете достигнуть ограничения на число запросов API.

Вопросы управляемости

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

Ниже приведены некоторые примеры использования скриптов в развертываниях DevTest Labs.

• Изменение параметров лаборатории. Вы можете изменить определенный параметр для всех лабораторий с помощью скриптов PowerShell, Azure CLI и REST API. Например, можно разрешить во всех лабораториях новый размер экземпляра виртуальной машины.

• Обновление личных маркеров доступа репозитория артефактов. Срок действия личных маркеров доступ для репозиториев Git обычно составляет 90 дней, один год или два года. Чтобы обеспечить непрерывность, важно увеличить срок действия маркера. Вы также можете создать новый личный маркер доступа и с помощью автоматизации применить его ко всем лабораториям.

• Запрет на изменение параметров лаборатории. Чтобы ограничить изменение определенных параметров (например, разрешения на использование образов из Marketplace), можно запретить изменения для ресурса определенного типа с помощью политики Azure. Также можно создать настраиваемую роль и предоставить ее пользователям вместо встроенной роли лаборатории. Вы можете запретить изменения для большинства параметров лаборатории, таких как внутренняя поддержка, объявления лабораторий и разрешенные размеры виртуальных машин.

• Применение соглашения об именовании для виртуальных машин. С помощью политики Azure задать шаблон именования, который помогает идентифицировать виртуальные машины в облачных средах.

Управление ресурсами Azure для DevTest Labs осуществляется так же, как и в других целях. Например, политика Azure применяется к виртуальным машинам, создаваемым в лаборатории. Microsoft Defender для облака может отслеживать соответствии требованиям для виртуальной машины лаборатории. Служба Azure Backup может регулярно создавать резервные копии виртуальных машин в лаборатории.

Вопросы безопасности

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

Еще одним фактором безопасности является уровень разрешений, предоставляемый пользователям лаборатории. Владельцы лаборатории применяют управление доступом на основе ролей Azure (Azure RBAC) для назначения пользователям ролей и установки разрешений на уровне ресурсов и доступа. Наиболее распространенными разрешениями DevTest Labs являются владелец, участник и пользователь. Также можно создавать и назначать настраиваемые роли. Дополнительные сведения см. в разделе Добавление владельцев и пользователей в Azure DevTest Labs.

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

См. следующую статью в этой серии: Предоставление подтверждения концепции.