Блог

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

Когда сценарий PowerShell запускается для создания агента, который является целью группы развертывания, созданная служба Windows называется vstsagent .{название организации}.{название проекта}.{имя целевой виртуальной машины}. Это делает имя службы Windows уникальным для каждого проекта.

Когда сценарий PowerShell запускается для создания агента, который является ресурсом среды, созданная служба Windows называется vstsagent .{название организации} .. {имя целевой виртуальной машины} по умолчанию. Это означает, что по умолчанию все проекты в одной организации, которые развертываются на одной виртуальной машине, будут использовать одно и то же имя службы Windows для агента.

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

Когда сценарий PowerShell запускается на виртуальной машине для создания второго агента, он распознает, что уже существует служба с тем же именем, vstsagent.{название организации} .. {имя целевой виртуальной машины} на сервере и пытается заменить его. Это приводит к сбою примерно в 25% случаев. В этом случае я попытался вручную удалить существующую службу Windows, используя .config remove из PowerShell, а затем повторно запустить сценарий PowerShell второго агента. Сценарий PowerShell, похоже, выполняется без ошибок и сообщает, что он зарегистрировал агента. Однако теперь, если я попытаюсь запустить конвейер в первом или втором проекте, он завершается неудачей, сообщая: «Невозможно выполнить развертывание на виртуальной машине»{имя целевой виртуальной машины}», поскольку машина находится в автономном режиме.«. В итоге у меня получается два проекта, которые я больше не могу развертывать.

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

Я могу воспроизвести ту же проблему. Вы можете сообщить об этой проблеме группе разработчиков Microsoft.

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

По умолчанию для имени агента было задано имя виртуальной --agent $env:COMPUTERNAME машины. Вы можете изменить имя агента dafault. например. --agent $env:COMPUTERNAME-SecondProject . Смотрите ниже:

.

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