Часто задаваемые вопросы об Azure DevTest Labs

В этой статье содержатся ответы на некоторые самые распространенные вопросы об Azure DevTest Labs.

Запись блога

Блог команды DevTest Labs не ведется с 20 марта 2019 года.

Где можно отслеживать обновления компонентов с этого момента?

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

Подпишитесь на блог Azure по DevTest Labs и новости Azure по DevTest Labs, чтобы получать сведения о новых возможностях в DevTest Labs.

Что будет с существующими записями блога?

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

Где можно просмотреть новости о сбоях?

Теперь мы будем публиковать новости о сбоях в Twitter под нашим именем. Подпишитесь на нас в Twitter, чтобы получать последние новости о сбоях и известных ошибках.

Twitter

Наше имя пользователя в Twitter: @azlabservices

Общие сведения

Мне не удалось найти ответ на свой вопрос. Что делать?

Если вашего вопроса нет в списке, сообщите нам об этом, и мы поможем найти ответ.

Что такое учетная запись Майкрософт?

Учетная запись Майкрософт используется практически для всех действий с устройствами и службами Майкрософт. Это электронный адрес и пароль, используемые для входа в Skype, Outlook.com, OneDrive, Windows Phone, Azure и Xbox Live, что означает, что ваши файлы, фотографии, контакты и параметры доступны на любом вашем устройстве.

Примечание

Учетная запись Майкрософт раньше называлась Windows Live ID.

Почему следует использовать Azure DevTest Labs?

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

Что означает "самообслуживание без проблем"?

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

Как можно использовать DevTest Labs?

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

  • Централизованное управление средами разработки и тестирования. Использование политик для сокращения расходов и создание пользовательских образов для совместного использования сборок в группе.
  • Разработка приложений с помощью пользовательских образов для сохранения состояния диска на протяжении развертывания.
  • Отслеживание расходов, связанных с ходом выполнения.
  • Создание массовых сред тестирования для контроля качества.
  • Использование артефактов и формул для удобной настройки и воспроизведения приложений в разных средах.
  • Распределение виртуальных машин для интенсивной работы группы (совместная работа над разработкой или тестированием) с последующим удобным отзывом этих машин после окончания события.

Как выставляются счета за использование DevTest Labs?

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

Безопасность

Какие уровни безопасности предусмотрены в DevTest Labs?

Безопасный доступ контролируется управлением доступом на основе ролей Azure (Azure RBAC). Чтобы разобраться в механизме предоставления доступа, важно понимать разницу между разрешением, ролью и областью в Azure RBAC.

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

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

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

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

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

Как определить управление доступом на основе ролей Azure для сред DevTest Labs, чтобы ИТ-отдел мог выполнять управление, а разработчики и тестировщики могли выполнять свою работу?

Существует принятый шаблон, однако детали зависят от вашей организации.

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

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

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

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

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

Как создать роль, позволяющую пользователям выполнять конкретную задачу?

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

$policyRoleDef = Get-AzRoleDefinition "DevTest Labs User"
$policyRoleDef.Actions.Remove('Microsoft.DevTestLab/Environments/*')
$policyRoleDef.Id = $null
$policyRoleDef.Name = "DevTest Labs Advanced User"
$policyRoleDef.IsCustom = $true
$policyRoleDef.AssignableScopes.Clear()
$policyRoleDef.AssignableScopes.Add("/subscriptions/<subscription Id>")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Start/action")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Stop/action")
$policyRoleDef = New-AzRoleDefinition -Role $policyRoleDef  

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

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

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

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

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

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

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

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

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

Настройка лаборатории

Как создать лабораторию на основе шаблона Resource Manager?

В GitHub доступен репозиторий шаблонов Azure Resource Manager Azure для лабораторий, которые можно развернуть "как есть" или изменить, чтобы создать пользовательские шаблоны для своих лабораторий. Каждый шаблон содержит ссылку, которую можно щелкнуть, чтобы развернуть лабораторию в исходном виде в собственной подписке Azure. Вы также можете настроить шаблон и развернуть его с помощью PowerShell или Azure CLI.

Можно ли создать все виртуальные машины в общей группе ресурсов, а не помещать каждую из них в отдельную группу ресурсов?

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

В случае отельных групп ресурсов происходит следующее:

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

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

Как правильно поддерживать соглашения об именовании в среде DevTest Labs?

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

Сколько лабораторий можно создать в рамках одной подписки?

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

Сколько виртуальных машин можно создать на лабораторию?

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

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

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

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

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

Как предотвратить случайное удаление ресурсов в лаборатории?

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

Как предоставить прямую ссылку на мою лабораторию?

  1. Перейдите к лаборатории на портале Azure.
  2. Скопируйте URL-адрес лаборатории из браузера и предоставьте его пользователям лаборатории.

Примечание

Если лабораторию используют внешние пользователи с учетной записью Майкрософт, не являющиеся участниками экземпляра Active Directory вашей организации, они могут получить сообщение об ошибке при переходе по предоставленной ссылке. В этом случае предложите им выбрать свое имя в правом верхнем углу на портале Azure. Затем из раздела меню "Каталог" выберите каталог, в котором расположена лаборатория.

Виртуальные машины

Почему на странице "Виртуальные машины" не отображаются виртуальные машины, доступные в DevTest Labs?

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

Как создать несколько виртуальных машин с помощью одного шаблона?

Существует два варианта одновременного создания нескольких виртуальных машин из одного шаблона:

Как переместить имеющиеся виртуальные машины Azure в лабораторию DevTest Labs?

Чтобы скопировать имеющиеся виртуальные машины в DevTest Labs, сделайте следующее:

  1. Скопируйте VHD-файл имеющейся виртуальной машины с помощью скрипта Windows PowerShell.
  2. Создайте пользовательский образ внутри лаборатории DevTest Labs.
  3. Затем создайте на его основе виртуальную машину.

Можно ли присоединить к виртуальной машине несколько дисков?

Да, такая возможность поддерживается.

Поддерживаются ли образы поколения 2, поддерживаемые DevTest Labs?

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

Если требуется использовать образ ОС Windows для тестирования, нужно ли приобретать подписку MSDN?

Чтобы использовать образы клиентской ОС Windows (Windows 7 или более поздней версии) для разработки или тестирования в Azure, выполните следующие действия.

Дополнительные сведения о деньгах на счете в Azure по каждому предложению MSDN см. в статье Ежемесячная сумма денег на счете в Azure для подписчиков Visual Studio.

Как автоматизировать процесс удаления всех виртуальных машин в моей лаборатории?

Владелец лаборатории может удалить виртуальные машины из лаборатории на портале Azure. или с помощью скрипта PowerShell. В указанном ниже примере под комментарием Values to change (Изменяемые значения) измените значения параметров. Вы можете узнать значения subscriptionId, labResourceGroup и labName на панели лаборатории на портале Azure.

# Delete all the VMs in a lab.

# Values to change:
$subscriptionId = "<Enter Azure subscription ID here>"
$labResourceGroup = "<Enter lab's resource group here>"
$labName = "<Enter lab name here>"

# Sign in to your Azure account.
Connect-AzAccount

# Select the Azure subscription that has the lab. This step is optional
# if you have only one subscription.
Select-AzSubscription -SubscriptionId $subscriptionId

# Get the lab that has the VMs that you want to delete.
$lab = Get-AzResource -ResourceId ('subscriptions/' + $subscriptionId + '/resourceGroups/' + $labResourceGroup + '/providers/Microsoft.DevTestLab/labs/' + $labName)

# Get the VMs from that lab.
$labVMs = Get-AzResource | Where-Object {
          $_.ResourceType -eq 'microsoft.devtestlab/labs/virtualmachines' -and
          $_.Name -like "$($lab.Name)/*"}

# Delete the VMs.
foreach($labVM in $labVMs)
{
    Remove-AzResource -ResourceId $labVM.ResourceId -Force
}          

Среды

Как применить шаблоны Resource Manager в моей среде DevTest Labs?

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

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

Пользовательские образы

Как мне настроить легко воспроизводимый процесс, позволяющий использовать корпоративные пользовательские образы в среде DevTest Labs?

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

Дополнительные сведения о создании фабрики образов см. в статье Создание настраиваемой фабрики образов в Azure DevTest Labs.

В чем разница между пользовательским образом и формулой?

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

Когда мне использовать формулу, а когда — пользовательский образ?

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

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

Дополнительные сведения см. в статье Сравнение пользовательских образов и формул в DevTest Labs.

Как автоматизировать процесс передачи VHD-файлов для создания пользовательских образов?

Существует два варианта, чтобы автоматизировать процесс передачи VHD-файлов для создания пользовательских образов:

  • Скопируйте или передайте VHD-файлы в учетную запись хранения, связанную с лабораторией, с помощью AzCopy.
  • Или воспользуйтесь обозревателем хранилищ Azure. Обозреватель хранилищ — это автономное приложение, работающее на платформе Windows, OSX и Linux.

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

  1. Войдите на портал Azure.
  2. В меню слева выберите Группы ресурсов.
  3. Найдите и выберите группу ресурсов, связанную с вашей лабораторией.
  4. В разделе Обзор выберите одну из учетных записей хранения.
  5. Выберите Большие двоичные объекты.
  6. Просмотрите список отправленных файлов. Если файлы отсутствуют, вернитесь к шагу 4 и выберите другую учетную запись хранения.
  7. В команде AzCopy введите URL-адрес в качестве места назначения.

Когда мне использовать образ Azure Marketplace, а когда — пользовательский образ, созданный в компании?

Когда мне использовать образ Azure Marketplace, а когда — пользовательский образ, созданный в компании?

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

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

Артефакты

Что такое артефакты?

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

Во время создания виртуальной машины произошел сбой артефакта. Как устранить эту проблему?

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

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

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

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

Следует ли организации планировать использование одного репозитория или нескольких?

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

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

Интеграция средств непрерывной интеграции и доставки (CI/CD)

Можно ли интегрировать DevTest Labs с собственной цепочкой инструментов непрерывной интеграции и доставки?

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

  • автоматическое создание и развертывание виртуальной машины, а также ее настройка с помощью последней сборки с использованием задачи "Копирование файлов Azure" или задачи PowerShell Azure DevOps Services;
  • автоматическая запись состояния виртуальной машины после тестирования с целью воспроизведения ошибки на таком же экземпляре для дальнейшего исследования;
  • удаление виртуальной машины во время завершения работы конвейера выпуска, если она больше не нужна.

Дополнительные сведения и руководство по использованию расширения Azure DevOps Services см. в следующих записях блога:

Для других цепочек инструментов непрерывной интеграции (CI) и непрерывной поставки (CD) можно реализовать такие же сценарии путем развертывания шаблонов Azure Resource Manager с помощью командлетов Azure PowerShell и пакетов SDK для .NET. Для интеграции DevTest Labs с набором инструментов также можно использовать REST API для DevTest Labs.

Сеть

Когда мне лучше создать новую виртуальную сеть для среды DevTest Labs, а когда — использовать существующую виртуальную сеть?

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

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

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

Когда мне лучше использовать общий, общедоступный и частный IP-адреса?

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

Примечание

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

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

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

Да. Здесь важно учитывать два элемента — входящий и исходящий трафик.

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

Примечание

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

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

Устранение неполадок

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

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

Почему при подготовке из PowerShell выводится ошибка Parent resource not found (Родительский ресурс не найден)?

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

Виртуальные машины представляют собой дочерние ресурсы в лаборатории в группе ресурсов. При использовании шаблонов Resource Manager для развертывания виртуальных машин с помощью PowerShell имя группы ресурсов, указанное в скрипте PowerShell, должно совпадать с именем группы ресурсов лаборатории. Дополнительные сведения см. в статье Устранение распространенных ошибок развертывания в Azure с помощью Azure Resource Manager | Microsoft Azure.

Где найти дополнительные сведения об ошибке при сбое развертывания виртуальной машины?

Ошибки при развертывании виртуальной машины записываются в журналы действий. Найти журналы действий виртуальных машин лаборатории можно в журналах аудита или диагностических данных виртуальной машины в меню ресурсов на странице виртуальной машины лаборатории (которая отображается после выбора виртуальной машины в списке "Мои виртуальные машины").

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

Почему при попытке создать лабораторию появляется сообщение об ошибке "Указанное расположение недоступно для типа ресурса"?

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

The provided location 'australiacentral' is not available for resource type 'Microsoft.KeyVault/vaults'. List of available regions for the resource type is 'devx-track-azurepowershell,northcentralus,eastus,northeurope,westeurope,eastasia,southeastasia,eastus2,centralus,southcentralus,westus,japaneast,japanwest,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia,canadacentral,canadaeast,uksouth,ukwest,westcentralus,westus2,koreacentral,koreasouth,francecentral,southafricanorth

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

Вариант 1

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

Вариант 2

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