Поделиться через


Руководство по развертыванию Microsoft Dev Box

В этой статье вы узнаете о процессе, параметрах конфигурации и рекомендациях по планированию и реализации развертывания Microsoft Dev Box.

Развертывание Microsoft Dev Box требует участия различных ролей в организации. Каждая роль имеет определенные обязанности и требования. Прежде чем начать реализацию Microsoft Dev Box, важно собрать все требования из разных ролей, так как они влияют на параметры конфигурации для различных компонентов в Microsoft Dev Box. После того как вы изложили свои требования, вы можете выполнить шаги по развертыванию, чтобы развернуть Dev Box в вашей организации.

Краткий обзор: контрольный список развертывания Dev Box

  1. Настройте подписку Azure и проверьте соответствие арендатора с Microsoft Entra и Intune.
  2. Планирование и настройка сетевого подключения (размещенное на серверах Microsoft или подключение к сети Azure; гибридное подключение по мере необходимости).
  3. Настройте группы и роли Azure RBAC для администраторов и пользователей.
  4. Создание центра разработки.
  5. Настройте сетевые подключения для центра разработки или проектов.
  6. Создание или подключение Галерей вычислений Azure (необязательно) для управления образами.
  7. Присоединение каталога настроек (необязательно) для задач установки.
  8. Настройте образы и вычисления (определения изображений, пользовательские образы или образы Marketplace; выберите размер вычислительных ресурсов и хранилище).
  9. Создание проектов и установка ограничений поля разработки.
  10. Создайте пулы полей разработки (выберите сетевое подключение и автоматическая остановка).
  11. Настройка Microsoft Intune (конфигурация устройства, условный доступ, управление привилегиями).

Роли и обязанности организации

Служба Dev Box была разработана с тремя организационными ролями: инженерами платформ, специалистами по разработке и разработчиками. В зависимости от размера и структуры организации некоторые из этих ролей могут объединяться человеком или командой.

Каждая из этих ролей несет определенные обязанности во время развертывания Microsoft Dev Box в вашей организации:

  • Инженер платформы: работает с ИТ-администраторами для настройки инфраструктуры разработчиков и средств для команд разработчиков. Это состоит из следующих задач:

    • Настройте Microsoft Entra ID для включения удостоверения и аутентификации для лидеров команд разработчиков и разработчиков.
    • Создание центра разработки и управление ими в подписке Azure организации
    • Создание сетевых подключений, определений поля разработки и коллекций вычислительных ресурсов в центре разработки и управление ими
    • Создание проектов и управление ими в центре разработки
    • Создание и настройка других ресурсов Azure в подписках Azure организации
    • Настройка конфигурации устройств Microsoft Intune для Dev Box и назначение лицензий пользователям Dev Box
    • Настройка параметров сети для обеспечения безопасного доступа и подключения к ресурсам организации
    • Настройка параметров безопасности для авторизации доступа к полям разработки
  • Руководитель группы разработчиков: помогает создавать интерфейс разработчика и управлять ими. Сюда входят следующие задачи:

    • Создание пулов полей разработки и управление ими в проекте
    • Определение специфичных для команды требований к образам и их кастомизации.
    • Предоставление входных данных инженерам платформы для создания определений изображений и настройки коллекций вычислительных ресурсов
  • Разработчик: самостоятельно управляет одной или несколькими разработческими средами в рамках назначенных проектов.

    • Подключение к среде разработки через портал для разработчиков
    • Создание и управление полем разработки на портале разработчика

Схема, показывая роли и обязанности инженеров платформы Dev Box, руководителей команд и разработчиков.

Определение требований для Microsoft Dev Box

При подготовке к развертыванию Microsoft Dev Box в вашей организации важно сначала определить требования конечных пользователей и управленческие требования ИТ. Например, группы разработки географически распределены, имеются ли политики безопасности, вы стандартизируете определенные вычислительные ресурсы и многое другое.

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

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

В следующей таблице перечислены требования, которые могут повлиять на развертывание Microsoft Dev Box и рекомендации при настройке компонентов Dev Box.

Категория Требование Соображения
Настройка группы разработки Географически распределенные команды. Регион Azure сетевого подключения пула виртуальных машин разработчика определяет, где размещаются виртуальные машины. Чтобы оптимизировать задержку между компьютером разработчика и полем разработки, разместите поле разработки, ближайшее к расположению пользователя поля разработки. Если у вас несколько географически распределенных команд, можно создать несколько сетевых подключений и связанных пулов средств разработки для размещения каждого региона.
Несколько проектов с различными руководителями команд и правами доступа. Разрешения для проектов разработки контролируются на уровне проекта в центре разработки. Рекомендуется создать проект, если требуется разделение управления между различными командами разработки.
Настройка поля разработки Разные команды имеют разные требования к программному обеспечению для их поля разработки. Создайте определения изображений, пользовательские образы или используйте образы Marketplace для представления различных требований к операционной системе или программному обеспечению в организации. Определения изображений используют файлы настройки на основе YAML и позволяют независимо выбирать вычислительные ресурсы и хранилище. Например, создайте определение изображения для специалистов по обработке и анализу данных с помощью средств обработки и анализа данных. При создании пула полей разработки в проекте можно выбрать из доступных источников образов и независимо выбрать размер вычислительных ресурсов и хранилище.
Несколько конфигураций вычислительных ресурсов. Современные пулы средств разработки позволяют независимо выбирать размер вычислительных ресурсов и хранилище, обеспечивая большую гибкость, чем устаревшие определения полей разработки. Выберите соответствующие конфигурации вычислений и хранилища при создании пулов полей разработки на основе требований команды.
Разработчики могут настроить свое поле разработки. Для настройки для каждого разработчика, например для настройки репозиториев системы управления версиями или параметров средств разработчика, можно включить настройки для полей разработки.
Стандартизируйте образы виртуальных машин для конкретной организации. При настройке центра разработки можно указать одну или несколько коллекций вычислительных ресурсов Azure, которые содержат образы виртуальных машин, относящиеся к вашей организации. С помощью коллекции вычислений можно убедиться, что для создания полей разработки используются только утвержденные образы виртуальных машин.
Идентификация и доступ Управление пользователями только в облаке с помощью идентификатора Microsoft Entra. Ваше решение для управления пользователями влияет на сетевые настройки при создании пулов для разработки. При использовании Microsoft Entra ID можно выбрать размещение у Майкрософт или использовать свою собственную сеть.
Пользователи входят с учетной записью Active Directory. Если вы управляете пользователями в доменных службах Active Directory, необходимо использовать гибридное соединение Microsoft Entra для интеграции с Microsoft Dev Box. Таким образом, вы не можете использовать опцию сети, размещенную на платформе Microsoft, при создании пула средств разработки и вам необходимо использовать сеть Azure для обеспечения гибридного сетевого подключения.
Сеть и подключение Доступ к другим ресурсам Azure. Если требуется доступ к другим ресурсам Azure, необходимо настроить сетевое подключение Azure. В результате при создании пула сред разработки нельзя использовать предоставляемую корпорацией Майкрософт сетевую опцию.
Доступ к корпоративным ресурсам (гибридное подключение). Чтобы получить доступ к корпоративным ресурсам, необходимо настроить сетевое подключение Azure, а затем настроить гибридное подключение с помощью сторонних виртуальных сетей, VPN Azure или Azure ExpressRoute. В результате при создании пула сред разработки нельзя использовать предоставляемую корпорацией Майкрософт сетевую опцию.
Настраиваемая маршрутизация. Если требуется настраиваемая маршрутизация, необходимо настроить сетевое подключение Azure. В результате при создании пула сред разработки нельзя использовать предоставляемую корпорацией Майкрософт сетевую опцию.
Сетевая безопасность Настройте ограничения трафика с группами безопасности сети (NSG). Если для ограничения входящего или исходящего трафика требуются группы безопасности сети, необходимо настроить сетевое подключение Azure. В результате при создании пула сред разработки нельзя использовать предоставляемую корпорацией Майкрософт сетевую опцию.
Использование брандмауэра. Для использования брандмауэров или шлюзов приложений необходимо настроить сетевое подключение Azure. В результате при создании пула сред разработки нельзя использовать предоставляемую корпорацией Майкрософт сетевую опцию.
Управление устройствами Ограничить доступ к поле разработки только управляемым устройствам или на основе географии. С помощью Microsoft Intune можно создавать динамические группы устройств и политики условного доступа.
Настройка параметров и функций устройства на разных устройствах. После того, как Dev Box будет подготовлена, вы можете управлять ею так же, как и любым другим устройством в Microsoft Intune. Вы можете создать профили конфигурации устройства, чтобы включить и отключить различные параметры.

См. также: настройки Microsoft Dev Box.

Матрица принятия решений по сети, удостоверению и подключению

Используйте следующую матрицу, чтобы определить рекомендуемый тип подключения и тип соединения для развертывания:

Модель идентификации Контроль исходящего трафика (NSG/брандмауэры)? Локальный доступ? Рекомендуемое подключение Тип соединения
Entra ID (только облако) Нет Нет Размещено на платформе Microsoft Присоединение к Microsoft Entra
Entra ID (только для облачных решений) Да Нет Сетевое подключение Azure Присоединение к Microsoft Entra
Entra ID (только для облака) Нет или да Да Сетевое подключение Azure Присоединение к Microsoft Entra
Active Directory (гибридная версия) Любое Да Сетевое подключение Azure Гибридное объединение Microsoft Entra

Общие шаблоны архитектуры

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

  • Только облако (наиболее простая): присоединение к Microsoft Entra + сеть, размещенная на серверах Microsoft. Оптимальный выбор для организаций без локальных зависимостей и без кастомных требований к исходящему трафику. Разработчики получают доступ только к облачным ресурсам.

  • Гибридная среда с ресурсами Azure: присоединение к Microsoft Entra + сетевое подключение Azure. Для организаций, которым требуются поля разработки для доступа к службам, размещенным в Azure, таким как База данных SQL Azure, Служба Azure Kubernetes или Azure Cosmos DB. Используйте пиринг между виртуальными сетями для подключения подсетей dev box к другим ресурсам Azure.

  • Полный гибридный (локальный доступ): гибридное соединение Microsoft Entra + сетевое подключение Azure + топология концентратора и периферийной топологии. Для организаций с доменными службами Active Directory и локальными ресурсами (серверы лицензирования, управление версиями, базы данных). Требуется подключение ExpressRoute или VPN.

Использование ИИ для планирования развертывания

Вы можете использовать помощники по искусственному интеллекту, такие как GitHub Copilot, чтобы проанализировать требования организации и создать специализированный план развертывания Dev Box. Это особенно полезно, если необходимо принимать решения в области сетевых технологий, идентификационных данных, стратегии работы с изображениями и контроле затрат.

Ниже приведен пример запроса, который можно адаптировать для вашего сценария:

Help me plan a Microsoft Dev Box deployment based on these requirements:

Organization details:
- 50 developers across 3 teams (frontend, backend, data science)
- Teams located in US West and Europe
- Using Microsoft Entra ID (cloud-only, no on-premises Active Directory)
- Need access to Azure SQL Database and Azure Kubernetes Service

Requirements:
- Frontend team: Visual Studio Code, Node.js, needs 8 GB RAM
- Backend team: Visual Studio 2022, .NET 8, SQL Server tools, needs 16 GB RAM
- Data science team: Python, Jupyter, GPU access, needs 32 GB RAM
- Must auto-shutdown dev boxes at 7 PM local time
- Limit developers to 2 dev boxes each

Generate a deployment plan that includes:
1. Recommended number of dev centers and projects
2. Network connection strategy (Microsoft-hosted vs Azure network connection)
3. Image strategy (marketplace images, custom images, or image definitions)
4. Dev box pool configuration for each team and region
5. Cost optimization recommendations

Вы можете настроить этот запрос для включения конкретных требований, таких как:

  • Требования к гибридному подключению для локальных ресурсов
  • Политики соответствия или безопасности (брандмауэры, группы безопасности сети)
  • Существующие образы галереи вычислительных ресурсов Azure
  • Требования к условному доступу Microsoft Intune

Замечание

Содержимое, созданное СИ, может содержать ошибки. Всегда проверяйте план развертывания на основе политик вашей организации и архитектуры Microsoft Dev Box перед реализацией.

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

Предпосылки

  • Подписка Azure, связанная с клиентом Microsoft Entra. Ресурсы Dev Box и Microsoft Intune должны находиться в одном арендаторе.
  • Одна лицензия Microsoft Intune на пользователя Dev Box.
  • Группы и роли Azure RBAC для доступа: администратор проекта и пользователь Dev Box, назначенные с помощью групп Microsoft Entra.
  • Необходимые условия сети (например, подключение к локальным ресурсам для гибридных сценариев).

Развертывание Microsoft Dev Box

После определения требований можно начать развертывание Microsoft Dev Box. Microsoft Dev Box состоит из нескольких ресурсов Azure, таких как центр разработки, проекты, определения полей разработки и многое другое. Dev Box также имеет зависимости от других служб Azure и Microsoft Intune.

Для развертывания Microsoft Dev Box требуется создание и настройка нескольких служб в Azure, Intune и вашей инфраструктуре. В следующих разделах приведены различные шаги по развертыванию Microsoft Dev Box в организации. Некоторые действия являются необязательными и зависят от конкретной настройки организации.

Шаг 1. Настройка подписки Azure

Подписки — это единица управления, выставления счетов и масштабирования в Azure. Вы можете использовать одну или несколько подписок для поддержки структуры организации, модели управления, квот ресурсов и элементов управления затратами. Dev Box обеспечивает гибкое выставление счетов, позволяя назначать разные подписки разным командам или отделам. Это помогает сравнивать затраты на облако с тем, как работает ваш бизнес. Узнайте больше о аспектах, которые следует учитывать при создании подписок Azure.

Каждая подписка Azure связана с одним клиентом Microsoft Entra, который выступает в качестве поставщика удостоверений (IdP) для подписки Azure. Клиент Microsoft Entra используется для проверки подлинности пользователей, служб и устройств.

Каждому пользователю Dev Box требуется лицензия Microsoft Intune. Подписка Azure, содержащая ресурсы Azure Dev Box (центр разработки, проект и многое другое), должна находиться в том же клиенте, что и Microsoft Intune. Сведения о назначении лицензий пользователям см. в статье "Назначение лицензий Microsoft 365 пользователям".

Шаг 2. Настройка сетевых компонентов

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

Примеры сетевых компонентов, которые могут потребоваться настроить:

  • Виртуальные сети Azure (VNet)
  • Пиринг между виртуальными сетями
  • Группы безопасности сети (NSG)
  • Брандмауэры, такие как брандмауэр Azure или другие решения брандмауэра
  • Azure ExpressRoute
  • виртуальные частные сети или шлюзы

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

  • Доступ к локальным ресурсам из разработческой среды, например, сервера лицензирования, принтеров или системы управления версиями.
  • Доступ к другим ресурсам Azure, таким как Azure Cosmos DB и кластеры Службы Azure Kubernetes (AKS)
  • Ограничение доступа через брандмауэры или группы безопасности сети (NSG)
  • Определение правил пользовательской маршрутизации сети
  • Управление пользователями за пределами идентификатора Microsoft Entra

При подключении к локальным ресурсам через гибридные соединения Microsoft Entra обратитесь к специалисту по топологии сети Azure. Реализуйте топологию сети концентратора и периферийной сети. Узел связи — это центральная точка, которая подключается к вашей локальной сети. Используйте ExpressRoute, VPN типа "сеть — сеть" или VPN типа "точка — сеть". Спица — это виртуальная сеть, содержащая боксы разработки. Настройте пиринг между виртуальной сетью dev box и виртуальной сетью, подключенной к локальным ресурсам, чтобы обеспечить доступ. Топология с концентраторами и периферийными устройствами помогает управлять сетевым трафиком и безопасностью.

Планирование сети должно включать оценку количества необходимых IP-адресов и их распределение между виртуальными сетями. Дополнительные бесплатные IP-адреса необходимы для проверки работоспособности сетевого подключения Azure. Запланируйте один дополнительный IP-адрес для каждого поля разработки и два IP-адреса для проверки работоспособности и инфраструктуры Dev Box.

Подсказка

Пример размера подсети: для 50 полей разработки планируйте не менее 52 IP-адресов в подсети (по одному на поле разработки + 2 для проверок работоспособности и инфраструктуры). Подсеть /26 (62 доступных для использования IP-адресов) поддерживает примерно 60 полей разработки. Подсеть /24 (254 доступных для использования IP-адресов) поддерживает максимум 252 рабочих устройств.

При использовании гибридного присоединения Microsoft Entra также убедитесь, что DNS-разрешение между подсетью разработческой среды и локальной средой Active Directory настроено правильно. DNS-серверы подсети должны разрешить домен Active Directory для успешного присоединения к домену.

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

Дополнительные сведения о требованиях к сети Microsoft Dev Box.

При планировании архитектуры Dev Box выберите основные и резервные регионы. Выберите основной регион, близкий к разработчикам, чтобы оптимизировать задержку и избежать проблем с квотами. Регион резервного копирования подготавливает вас к сценариям аварийного восстановления и позволяет быстро перенести их при необходимости. Разместите центр разработки в центральном месте для распределенных команд, например, между Индией и США, и поместите пулы в регионах, ближайших к каждой группе разработки. Например, западная часть США хорошо подходит для разработчиков на основе Redmond, а центральная часть США — хорошая резервная копия для обеспечения непрерывности. Настройте два сетевых подключения для каждого региона.

Шаг 3. Настройка групп безопасности для управления доступом на основе ролей

Microsoft Dev Box использует управление доступом на основе ролей Azure (Azure RBAC) для предоставления доступа к функциям в службе. В следующей таблице перечислены ключевые роли и их типичные назначения:

Роль Типичная область Типичное назначение
Владелец или Участник Подписка или группа ресурсов Инженеры платформы, обеспечивающие инфраструктуру
Владелец DevCenter Центр разработки Инженеры платформы управляют конфигурацией Dev Box
Администратор проекта DevCenter Проект Руководители группы контролируют управление пулами и настройками проекта.
Пользователь Dev Box Проект или пул Разработчики создают собственные поля разработки и управляют ими

Назначьте самую ограничивающую роль, которая позволяет пользователям выполнять свои задачи. Например, руководитель группы, который управляет пулами dev box в рамках одного проекта, нуждается в предоставлении роли администратора проекта DevCenter, привязанной к этому проекту, а не роли участника в группе ресурсов.

Рекомендуется создавать группы безопасности в идентификаторе Microsoft Entra для предоставления или отзыва доступа для администраторов и пользователей для каждого проекта. С помощью группы безопасности можно делегировать задачу предоставления доступа независимо от их разрешений на ресурсы Azure. Например, вы можете делегировать предоставление доступа пользователям дев-боксов лидеру команды разработки этого проекта.

Узнайте больше о ролях и разрешениях Dev Box и группах Microsoft Entra ID.

Шаг 4. Создание центра разработки

Чтобы начать работу с Microsoft Dev Box, сначала создайте центр разработки. Центр разработчика в Microsoft Dev Box предоставляет централизованное место для управления набором проектов, настройки доступных образов и размеров dev box, а также сетевых настроек для обеспечения доступа к ресурсам организации.

Вы можете создать несколько центров разработки в следующих случаях:

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

  • Если разным пользователям необходимо владеть и поддерживать ресурс центра разработки в Azure.

Замечание

Регион Azure, в котором находится центр разработки, не определяет расположение полей разработки.

Узнайте больше о создании центра разработки для Microsoft Dev Box.

Шаг 5. Настройка сетевых подключений

Управление сетевыми подключениями определяет, где создаются и размещаются разработческие компьютеры, и позволяет подключаться к другим ресурсам Azure или корпоративным ресурсам. В зависимости от уровня управления можно использовать сетевые подключения, размещенные корпорацией Майкрософт, или использовать собственные сетевые подключения Azure.

Сетевые подключения, размещенные корпорацией Майкрософт, обеспечивают сетевое подключение в режиме SaaS. Корпорация Майкрософт управляет сетевой инфраструктурой и связанными службами для ваших ящиков разработки. Сети, предоставляемые корпорацией Майкрософт, — это облачное развертывание, поддерживающее присоединение к Microsoft Entra. Этот параметр несовместим с моделью гибридного соединения Microsoft Entra.

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

Вы также можете использовать сетевые подключения Azure (принести собственную сеть) для подключения к виртуальным сетям Azure и при необходимости подключения к корпоративным ресурсам. С помощью сетевых подключений Azure вы управляете и контролируете всю настройку и конфигурацию сети. Вы можете использовать варианты подключения Microsoft Entra join или Microsoft Entra hybrid join с сетевыми подключениями Azure, что позволяет подключаться к локальным доменным службам Active Directory (AD DS).

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

Рекомендуется создать отдельное сетевое подключение в следующих сценариях:

  • Разработчик или команда находятся в другом географическом регионе. Область сетевого подключения определяет, где размещаются поля разработки.
  • Разработчику или команде требуется доступ к ресурсам Azure. Рекомендуется создать отдельное сетевое подключение Azure для каждого сценария использования (например, доступ к серверу управления версиями или доступ к веб-приложению и серверу базы данных).
  • Разработчику или команде требуется доступ к корпоративным локальным ресурсам. Создайте сетевое подключение Azure и настройте его для гибридного подключения.
  • Пользователи поля разработки должны пройти проверку подлинности с помощью учетной записи Active Directory. Создайте сетевое подключение Azure и настройте его для гибридного подключения.

Шаг 6: Создание галерей вычислений

По умолчанию определения поля разработки могут использовать любой образ виртуальной машины, совместимый с Dev Box из Azure Marketplace. Вы можете назначить одну или несколько коллекций вычислительных ресурсов Azure центру разработки для управления образами виртуальных машин, доступными во всех проектах центра разработки.

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

Рекомендуется использовать коллекцию вычислений Azure в следующих случаях:

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

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

Узнайте больше о настройке коллекции вычислений для центра разработки.

Шаг 7. Присоединение каталога

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

Задачи установки определяются в каталоге, который может быть репозиторием GitHub или репозиторием Azure DevOps. Подключите один или несколько каталогов к центру разработки. Все задачи доступны для всех контейнеров разработки, созданных во всех проектах в центре разработок.

Корпорация Майкрософт предоставляет каталог быстрого запуска, который поможет вам приступить к настройке. Этот каталог включает набор задач по умолчанию, определяющих распространенные задачи установки, такие как установка программного обеспечения с помощью WinGet или Chocolatey, клонирование репозитория, настройка приложений или запуск сценариев PowerShell.

Рекомендуется присоединить каталог в следующих случаях:

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

Рассмотрите возможность создания нового каталога, если задачи в каталоге быстрого запуска недостаточны. Вы можете присоединить каталог быстрого запуска и собственные каталоги к центру разработки.

Узнайте, как создавать настройки поля разработки.

Шаг 8. Настройка образов и вычислений

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

  • Определения образов (рекомендуется для новых развертываний): файлы настройки на основе YAML, использующие базовый образ и применяющие задачи установки. Определения изображений позволяют независимо выбирать размер вычислительных ресурсов и хранилище при создании пула, обеспечивая максимальную гибкость.
  • Пользовательские образы: образы виртуальных машин, которые вы создаете и храните в Галерее вычислений Azure. Полезно, когда вам нужны полностью предварительно настроенные и проверенные образы для вашей организации.
  • Образы из Marketplace: готовые образы, доступные в Azure Marketplace. Самый быстрый способ начать работу с такими инструментами, как Visual Studio и общие образы для разработки Windows.

Это важно

Определения поля разработки — это устаревший вариант, который объединяет образы, размер вычислительных ресурсов и хранилище в одну конфигурацию. Для новых развертываний рекомендуется использовать определения изображений, пользовательские образы или образы Marketplace, которые обеспечивают большую гибкость. Дополнительные сведения о параметрах изображения для Dev Box.

При выборе стратегии изображения следует учитывать следующее:

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

Рассмотрите стоимость вычислительных ресурсов для оценки общей стоимости развертывания.

Обзор решения

  • Требуется доступ к локальным или корпоративным ресурсам: используйте сетевое подключение Azure с гибридным соединением Microsoft Entra.
  • Требуется строгий контроль исходящего трафика (NSG/брандмауэры или настраиваемая маршрутизация): используйте сетевое подключение Azure.
  • Только облачное и минимальное управление: используйте управляемое Microsoft сетевое подключение с присоединением к Microsoft Entra.
  • Географически распределенные команды: создание сетевых подключений и пулов разработческих окружений в каждом регионе; при необходимости реплицируйте образы с помощью Галереи вычислений Azure.
  • Сокращение обширности изображений: предпочитайте настраиваемые задачи и каталоги; создавайте специально создаваемые образы только при необходимости.

Шаг 9. Создание проектов

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

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

Microsoft Dev Box использует управление доступом на основе ролей Azure (Azure RBAC) для предоставления доступа к функциям на уровне проекта:

  • Предоставление администраторам проекта доступа к выполнению административных задач в проектах Microsoft Dev Box (роль администратора проекта)
  • Предоставление пользователям поля разработки доступа к созданию и управлению своими полями разработки в проекте Dev Box (роль пользователя Dev Box)

Рекомендуется использовать группу идентификаторов Microsoft Entra для управления доступом для пользователей и администраторов проекта.

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

  • Вы хотите предоставить команде разработчиков набор стандартных рабочих станций разработчиков облака для проекта разработки программного обеспечения
  • У вас несколько проектов разработки с отдельными администраторами проектов и разрешениями на доступ

Узнайте больше о создании проектов и управлении ими.

Шаг 10. Создание пулов полей разработки

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

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

Чтобы сократить затраты на выполнение полей разработки, можно настроить поля разработки в пуле полей разработки, чтобы завершить работу ежедневно в предопределенное время.

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

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

Узнайте больше о создании пулов средств разработки и управлении ими.

Шаг 11. Настройка Microsoft Intune

Microsoft Dev Box использует Microsoft Intune для управления полями разработки. Используйте Центр администрирования Microsoft Intune для настройки параметров Intune, связанных с развертыванием Dev Box.

Замечание

Каждому пользователю Dev Box требуется одна лицензия Microsoft Intune и может создавать несколько полей разработки.

Конфигурация устройств

После подготовки поля разработки вы можете управлять им, как и любое другое устройство Windows в Microsoft Intune. Например, можно создать профили конфигурации устройства для включения и отключения различных параметров в Windows, а также отправки приложений и обновлений в поля разработки пользователей.

Настройка политик условного доступа

С помощью Intune можно настроить политики условного доступа для управления доступом к полям разработки. Для Dev Box обычно настраиваются политики условного доступа, чтобы ограничить, кто может получить доступ к Dev Box, что они могут делать, и откуда они могут получить доступ. Чтобы настроить политики условного доступа, можно использовать Microsoft Intune для создания динамических групп устройств и политик условного доступа.

Ниже приведены некоторые сценарии использования условного доступа в Microsoft Dev Box:

  • Ограничение доступа к среде разработки только для управляемых устройств.
  • Ограничение возможности копирования и вставки из поля разработки
  • Ограничение доступа к разработческой среде только из определенных регионов

Узнайте, как настроить политики условного доступа для Dev Box.

Подсказка

Рекомендуемый базовый план для пилотных развертываний. Рассмотрим эти политики условного доступа в качестве отправной точки:

  • Требуется многофакторная проверка подлинности для доступа на портале разработчика.
  • Ограничить доступ к разработческим средам на управляемых или соответствующих устройствах.
  • Блокировать устаревшие протоколы проверки подлинности.
  • Ограничьте доступ к среде разработки только из утвержденных географических местоположений.

Доработайте эти политики на основе требований безопасности вашей организации перед расширением в производство.

Управление привилегиями

Вы можете настроить Microsoft Intune Endpoint Privilege Management (EPM) для полей разработки, чтобы пользователи поля разработки не нуждались в локальных административных привилегиях. Microsoft Intune Endpoint Privilege Management позволяет пользователям вашей организации работать как стандартный пользователь (без прав администратора) и выполнять задачи, требующие повышенных привилегий. Задачи, для которых обычно требуются права администратора, — это установка приложений (например, приложений Microsoft 365), обновление драйверов устройств и запуск определенных диагностика Windows.

Узнайте больше о настройке привилегий конечной точки Microsoft Intune для Microsoft Dev Box.

Рекомендации по затратам и операциям

  • Настройте расписания автоматической остановки в пулах средств разработки для снижения затрат.
  • Выберите размеры виртуальных машин в определениях dev box, которые соответствуют рабочей нагрузке, чтобы избежать чрезмерного выделения ресурсов.
  • Определите периодичность управления версиями изображений и проверки при использовании изображений.
  • Используйте задачи настройки для хранения универсальных базовых образов; рекомендуется создать повторно используемый образ после проверки, если время создания становится критически важным.

Контрольный список развертывания пилотного проекта

Перед полным развертыванием производственной версии проверьте развертывание, используя пилотную группу.

  1. Выберите пилотную область: выберите одну команду (5–10 разработчиков), один регион и один проект.
  2. Определите критерии успешности: задайте целевые показатели для успешности подготовки, успешного входа на портал разработчика и успешного прохождения проверки состояния сетевого подключения.
  3. Применение базовых политик. Настройте минимальные политики условного доступа Intune и расписания автоматической остановки.
  4. Настройка элементов управления затратами: включение автоматической остановки в пулах полей разработки и установка ограничений для поля разработки на пользователя.
  5. Отслеживайте 2–4 недели: проверьте журнал действий Azure, журналы входа Microsoft Entra и отчеты о соответствии Intune.
  6. Расширение до уровня производства: добавление дополнительных команд и регионов. Проверка определений изображений и сетей в масштабе.

Мониторинг и устранение неполадок

  • Используйте журнал действий Azure для аудита изменений в ресурсах Центра разработки и проекта.
  • Просмотрите журналы входа Microsoft Entra для выявления проблем с доступом к средам разработки и порталу разработчика.
  • Используйте отчёты Intune для контроля соответствия устройств, конфигурации и статуса развертывания приложений в устройствах для разработки.
  • Проверьте работоспособность сетевого подключения Azure и необходимые бесплатные IP-адреса при диагностике проблем с подключением.