Система управления инфраструктурой Azure DevTest Labs — ресурсы

Статья
09/22/2023

В этой статье рассматриваются процессы согласования и управления для ресурсов DevTest Labs в вашей организации.

Ресурсы

Выравнивание ресурсов DevTest Labs в подписке Azure

Прежде чем применять Azure для разработки приложений в организации, проектировщики ИТ-систем должны оценить, как правильно добавить эти возможности в общий портфель своих служб. Особое внимание следует уделить следующим вопросам:

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

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

Вторая рекомендация заключается в том, чтобы включить подписку DevTest на корпоративном портале Azure. Она позволяет организации запускать клиентские операционные системы, которые обычно недоступны в корпоративной подписке Azure. Это позволит использовать корпоративное программное обеспечение с оплатой только за вычислительные ресурсы и не беспокоиться о лицензировании. В этой схеме выставление счетов за определенные службы, включая образы из коллекции в IaaS, например Microsoft SQL Server, будет основываться только на статистике использования. Сведения о подписке Azure DevTest можно найти здесь для клиентов Enterprise Agreement (EA) и здесь для клиентов с оплатой по мере использования.

Схема выравнивания ресурсов с подписками.

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

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

Есть одно важное ограничение на уровне подписки, которое необходимо учитывать — это правила выделения диапазонов IP-адресов в сети для рабочих подписок и подписок, используемых для разработки. При выделении адресов следует учитывать прогнозируемый рост (если локальное подключение или другая топология сети вынуждает предприятие самостоятельно управлять сетевым стеком вместо использования стандартной реализации Azure). Мы рекомендуем поддерживать несколько виртуальных сетей с большим префиксом IP-адресов, разделенных на большое количество крупных подсетей, а не создавать много виртуальных сетей с небольшими подсетями. Например, для 10 подписок можно выделить 10 виртуальных сетей (по одной для каждой подписки). Все лаборатории, которые не требуют изоляции, могут совместно использовать одну подсеть в виртуальной сети подписки.

Количество пользователей в лаборатории и количество лабораторий в организации

Бизнес-подразделения и группы разработки, связанные с тем же проектом разработки, должны быть связаны с той же лабораторией. Это позволит применять к обеим группам одинаковые политики, образы и процедуры завершения работы.

Иногда нужно также учитывать географические границы. Например, разработчики в северо-восточной части США могут использовать лабораторию, подготовленную в регионе "Восточная часть США 2". В то же время разработчики из Далласа (Техас) и Денвера (Колорадо) будут направляться к ресурсу в регионе "Центрально-южная часть США". Если существуют совместные усилия с внешней стороной, они могут быть назначены лаборатории, которая не используется внутренними разработчиками.

Можно также использовать лабораторию для конкретного проекта в рамках Azure DevOps Projects. Затем вы применяете безопасность через указанную группу Microsoft Entra, которая позволяет получить доступ к обоим наборам ресурсов. Еще одной границей для объединения пользователей может служить виртуальная сеть, назначенная лаборатории.

Предотвращение удаления ресурсов

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

Управление затратами и стоимостью владения

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

Оптимизация затрат

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

Если вы будете использовать DevTest Labs для рабочих нагрузок разработки и тестирования, рассмотрите возможность использования предложения подписки "Enterprise — разработка и тестирование" в рамках Соглашения Enterprise. Если же вы являетесь клиентом с оплатой по мере использования, рассмотрите предложение DevTest с оплатой по мере использования.

Этот подход дает несколько преимуществ:

особые низкие тарифы для разработки и тестирования на виртуальные машины Windows, облачные службы, HDInsight, Службу приложений и Logic Apps;
отличные тарифы на другие службы Azure в рамках Соглашения Enterprise;
доступ к эксклюзивным образам разработки и тестирования в коллекции, включая Windows 8.1 и Windows 10;

Только активные подписчики Visual Studio (стандартные подписки, годовые облачные подписки и месячные облачные подписки) могут использовать ресурсы Azure, запущенные в подписке "Enterprise — разработка и тестирование". Пользователи также могут получить доступ к приложению, чтобы предоставить отзыв об опыте использования и провести приемочное тестирование. Ресурсы в этой подписке можно использовать только для разработки и тестирования приложений. Гарантия бесперебойной работы отсутствует.

Если вы решили использовать предложение DevTest, это преимущество предназначено исключительно для разработки и тестирования приложений. Мы не предоставляем соглашение об уровне обслуживания с финансовыми гарантиями, если предложение используется в подписке, за исключением случаев, когда вы используете Azure DevOps и HockeyApp.

Определение доступа на основе ролей в организации

Центральный ИТ-отдел должен владеть только необходимыми ресурсами и предоставлять командам проектов и приложений необходимый уровень контроля. Как правило, это означает, что центральный ИТ-отдел владеет подпиской и обрабатывает основные ИТ-функции, такие как сетевые конфигурации. Набор владельцев подписки должен быть небольшим. Владельцы могут назначать дополнительных владельцев, когда это необходимо, или применять политики на уровне подписки, например "Запретить общедоступные IP-адреса".

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

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

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

Дополнительные сведения см. в разделе Корпоративный каркас Azure: рекомендуемая система управления подписками.

Политика компании и соответствие требованиям

В этом разделе приведены рекомендации по управлению политикой компании и соответствием инфраструктуры Azure DevTest Labs.

Общедоступный или частный репозиторий артефактов

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

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

Один репозиторий или несколько репозиториев

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

Свяжите Azure Repos с тем же клиентом Microsoft Entra, что подписка Azure используется для проверки подлинности и авторизации.
Создайте группу с именем All DevTest Labs Developers in Microsoft Entra ID, которая централизованно управляется. Любой разработчик, который участвует в разработке артефактов, должен входить в эту группу.
Ту же группу Microsoft Entra можно использовать для предоставления доступа к репозиторию Azure Repos и лаборатории.
В Azure Repos следует использовать создание ветвей и вилок из основного репозитория в рабочей среде в отдельный репозиторий разработки. Содержимое добавляется в главную ветвь только с помощью запроса на вытягивание после надлежащей проверки кода. Когда сотрудник, проверяющий код, одобрит изменение, ведущий разработчик, отвечающий за обслуживание главной ветви, выполнит слияние обновленного кода.

Корпоративные политики безопасности

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

Необходимо разработать и опубликовать комплексную политику безопасности. В политике должны быть установлены правила надлежащего использования ПО и облачных ресурсов. В ней также должно быть четко определено, что является нарушением политики.
Разработка пользовательского образа, пользовательских артефактов и процесса развертывания, позволяющего оркестрации в области безопасности, определенной с помощью Active Directory. Такой подход обеспечивает соблюдение корпоративных границ и устанавливает общий набор элементов для управления средой. Разработчики могут использовать эти элементы для управления средой, чтобы реализовать безопасный жизненный цикл разработки в рамках общего процесса работы. Цель заключается не в том, чтобы создать слишком строгую среду, которая может затруднять разработку, а оптимальный набор элементов управления. Групповые политики в подразделении, которое использует виртуальные машины лаборатории, могут быть частью общих групповых политик, используемых в производственной среде. Кроме того, они могут быть другим набором для правильного устранения определенных рисков.

Целостность данных

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

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

Первый уровень элементов управления для удаленного доступа — это применение соответствующей политики путем использования подключения VPN, которое не имеет прямого доступа к лаборатории.

Второй уровень элементов управления — это применение набора объектов групповой политики, которые предотвращают копирование и вставку при использовании удаленного рабочего стола. Можно внедрить политику сети, которая запрещает использование служб, например FTP или RDP, для подключения из-за пределов среды. Пользовательские правила маршрутизации могут принудительно направлять весь сетевой трафик Azure назад в локальную среду, но такая маршрутизация не может охватить все URL-адреса, допускающие отправку данных. В таких случаях необходимо использовать прокси-сервер, который сканирует содержимое и сеансы. В виртуальной сети, используемой в DevTest Labs, необходимо запретить общедоступные IP-адреса, чтобы предотвратить подключения типа "мост" к внешним сетевым ресурсам.

В целом, подобные ограничения необходимо применить во всей организации. Они также должны учитывать все возможные методы использования съемных носителей или внешних URL-адресов, допускающих отправку содержимого. Для проверки и внедрения политики безопасности необходимо привлечь соответствующего специалиста. Дополнительные рекомендации см. на веб-сайте Microsoft Cyber Security (Кибер-безопасность Майкрософт).

Перенос и интеграция приложения

После создания лабораторной среды для разработки и тестирования обдумайте следующие вопросы.

Как проектная группа будет использовать эту среду?
Как обеспечить соблюдение политик организации, сохраняя гибкость для повышения ценности приложения?

Образы Azure Marketplace и пользовательские образы

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

настолько сложный процесс установки программного обеспечения, что его лучше включать в состав базового образа;
установка и настройка приложения занимают несколько часов, что будет неэффективной тратой вычислительного времени при развертывании образа Azure Marketplace;
разработчикам и тест-инженерам нужен быстрый доступ к виртуальной машине и минимальные потери времени на настройку новой виртуальной машины;
обязательные требования или нормативные условия (например, политики безопасности), которые должны строго выполняться для всех компьютеров.

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

Формулы или пользовательский образ

Решающими факторами в этом вопросе обычно будут стоимость и возможность повторного использования.

Вы можете сократить затраты, создав пользовательский образ, если:

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

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

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

Шаблоны для настройки конфигурации сети

Если вы гарантируете, что разработка и тестирование виртуальных машин не удается получить доступ к общедоступному Интернету, необходимо учитывать два аспекта: входящий и исходящий трафик.

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

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

Примечание.

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

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

Новая или существующая виртуальная сеть

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

Каждая среда DevTest Labs может иметь собственную виртуальную сеть, однако количество виртуальных сетей в одной подписке ограничено. По умолчанию действует ограничение в 50 сетей, но его можно увеличить до 100.

Общий, общедоступный или частный IP-адрес

Если вы используете подключение VPN или Express Route типа "сеть — сеть", лучше всего применить частные IP-адреса. Тогда ваши компьютеры будут доступны во внутренней сети, но недоступны через Интернет.

Примечание.

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

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

Ограничения лаборатории

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

Ограничения лабораторий на подписку

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

Ограничения виртуальных машин на лабораторию

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

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

При рассмотрении количества виртуальных машин на пользователя или в лаборатории существует три основных проблемы:

Общая сумма расходов группы на ресурсы для лаборатории. Запустить несколько компьютеров очень легко. Чтобы контролировать эти расходы, можно применить ограничение на число виртуальных машин для пользователя или лаборатории.
Общее число виртуальных машин в лаборатории зависит от доступных квот уровня подписки. Одно из действующих ограничений — не более 800 групп ресурсов на одну подписку. В настоящее время DevTest Labs создает для каждой виртуальной машины новую группу ресурсов (если не используются общие общедоступные IP-адреса). Например, в подписке с 10-ю лабораториями в каждую из них можно будет поместить около 79 виртуальных машин (верхний предел 800 — 10 групп ресурсов для 10 лабораторий = 79 виртуальных машин на лабораторию).
Если лаборатория подключена к локальной сети через (например) Express Route, для виртуальной сети или подсети будут действовать определенные доступные пространства IP-адресов. Чтобы не возникало ситуаций, когда новые виртуальные машины в лаборатории не удается создать из-за ошибки ("не удается получить IP-адрес"), владельцу лаборатории следует настроить для лаборатории ограничение на максимальное количество виртуальных машин, согласованное с размером доступного пространства IP-адресов.

Использование шаблонов Resource Manager

Разверните шаблоны Resource Manager, выполнив действия из раздела Использование Azure DevTest Labs для тестовых сред. Вкратце, вам нужно разместить нужные шаблоны Resource Manager в репозиторий Git (Azure Repos или GitHub) и добавить в лабораторию частный репозиторий для шаблонов.

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

Ограничение на количество виртуальных машин для одной лаборатории и (или) одного пользователя влияет только на количество компьютеров, создаваемых в самой лабораторной среде. Этот параметр не ограничивает создание в любых других средах с помощью шаблонов Resource Manager.

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