Устранение неполадок при применении артефактов на виртуальной машине DevTest Labs

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

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

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

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

Устранение неполадок при сбоях артефактов с помощью портала Azure

Если вы не можете применить артефакт к виртуальной машине, сначала проверка следующие элементы в портал Azure:

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

С помощью команды PowerShell

Определить, можно ли применять артефакты на виртуальной машине, также можно с помощью Azure PowerShell. Проверьте флаг canApplyArtifacts, который возвращается только при развертывании операции GET. Пример:

Select-AzSubscription -SubscriptionId $SubscriptionId | Out-Null
$vm = Get-AzResource `
        -Name "$LabName/$VmName" `
        -ResourceGroupName $LabRgName `
        -ResourceType 'microsoft.devtestlab/labs/virtualmachines' `
        -ApiVersion '2018-10-15-preview' `
        -ODataQuery '$expand=Properties($expand=ComputeVm)'
$vm.Properties.canApplyArtifacts

Исследование сбоя артефакта

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

  1. На странице Обзор лаборатории в списке Мои виртуальные машины выберите виртуальную машину с артефактом, который требуется исследовать.

  2. На странице Обзор виртуальной машины выберите Артефакты в области навигации слева. На странице Артефакты перечислены артефакты, связанные с виртуальной машиной, и их состояние.

    Снимок экрана: список артефактов и их состояние.

  3. Выберите артефакт, для которого отображается состояние Сбой. Артефакт откроется и отобразится сообщение расширения, содержащее сведения о сбое артефакта.

    Снимок экрана: сообщение об ошибке для артефакта, завершилось сбоем.

Просмотр журналов действий

Чтобы установить артефакты, служба DevTest Labs создаст и развернет шаблон Azure Resource Manager (ARM), который запросит использование расширения пользовательских скриптов (CSE). Ошибка на этом уровне отображается в журналах действий подписки и группы ресурсов виртуальной машины.

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

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

Исследование частного репозитория артефактов и учетной записи хранилища лаборатории

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

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

CSE Error: Failed to download all specified files. Exiting. Exception: Microsoft.WindowsAzure.Storage.StorageException: The remote server returned an error: (403) Forbidden. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.

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

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

  • Проверьте наличие добавленных групп безопасности сети (NSG). Если для автоматической настройки групп безопасности сети во всех виртуальных сетях была добавлена политика уровня подписки, это повлияет на виртуальную сеть, используемую для создания виртуальных машин лаборатории.

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

  • Проверьте учетную запись хранения лаборатории, используемую по умолчанию. Учетная запись хранения по умолчанию — это первая учетная запись хранения, которая создается при создании лаборатории. Ее имя обычно начинается с буквы "a" и заканчивается многозначным числом, например a<имя_лаборатории>#.

    1. Перейдите к группе ресурсов лаборатории.
    2. Выберите ресурс типа Учетная запись хранения, имя которого соответствует указанному соглашению об именовании.
    3. На странице Обзор учетной записи хранения выберите Сеть в области навигации слева.
    4. На вкладке Брандмауэры и виртуальные сети убедитесь, что для параметра Доступ к общедоступной сетизадано значение Включено из всех сетей. Или, если выбран параметр Включено из выбранных виртуальных сетей и IP-адресов , убедитесь, что виртуальные сети лаборатории, используемые для создания виртуальных машин, добавлены в список.

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

Устранение неполадок при сбоях артефактов с виртуальной машины лаборатории

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

Проверка файла журнала расширения пользовательских скриптов

  1. На виртуальной машине лаборатории перейдите к расположению C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\*1.10.12*\Status\, где *1.10.12* — номер версии CSE.

    Снимок экрана: папка Status в лаборатории V M.

  2. Откройте и проверьте файл состояния (STATUS), чтобы просмотреть ошибку.

Сведения о том, как найти файлы журналов на виртуальной машине Linux, см. в статье Использование расширения настраиваемых скриптов Azure версии 2 на виртуальных машинах Linux.

Проверка агента виртуальной машины

Убедитесь, что агент виртуальных машин Azure установлен и готов к работе.

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

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

  1. На виртуальной машине лаборатории перейдите в папку C:\WindowsAzure\logs.

  2. Откройте файл WaAppAgent.log.

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

    [00000006] [11/14/2019 05:52:13.44] [INFO]  WindowsAzureGuestAgent starting. Version 2.7.41491.949
    ...
    [00000006] [11/14/2019 05:52:31.77] [WARN]  Waiting for OOBE to Complete ...
    ...
    [00000006] [11/14/2019 06:02:30.43] [WARN]  Waiting for OOBE to Complete ...
    [00000006] [11/14/2019 06:02:33.43] [INFO]  StateExecutor initialization completed.
    [00000020] [11/14/2019 06:02:33.43] [HEART] WindowsAzureGuestAgent Heartbeat.
    

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

Общие сведения о расширениях виртуальных машин см. в Расширения и возможности виртуальных машин Azure.

Исследование проблем с скриптом

Установка артефакта может завершиться сбоем из-за способа создания скрипта установки артефакта. Пример:

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

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

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

  1. Скопируйте скрипт на виртуальную машину или найдите его на виртуальной машине в расположении скачивания скрипта артефакта C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads.
  2. С помощью командной строки администратора запустите скрипт на виртуальной машине, указав те же значения параметров, которые вызвали проблему.
  3. Определите, демонстрирует ли скрипт какое-либо нежелательное поведение. Если это так, запросите обновление или исправьте скрипт.

Совет

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

Примечание

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

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

Дальнейшие действия

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

  • Обратитесь к экспертам по Azure DevTest Labs на форумах MSDN Azure и Stack Overflow.
  • Получите ответы специалистов Azure на форумах Azure.
  • Подпишитесь на @AzureSupport, официальный канал Microsoft Azure для улучшения качества взаимодействия с клиентами. Служба поддержки Azure взаимодействует с сообществом Azure, предоставляя ответы, поддержку и советы экспертов.
  • Перейдите на сайт поддержка Azure и выберите Отправить запрос в службу поддержки, чтобы отправить поддержка Azure инцидент.