New-AzureResourceGroup не авторизован в агенте сборки VSO
У меня есть агент сборки, настроенный на виртуальной машине в Azure, который связан с нашей Visual Studio Online.
Затем у меня есть шаг сборки Azure Powershell, который запускает скрипт, который пытается выполнить New-AzureResourceGroup.
Это приводит к следующему:
New-AzureResourceGroup: не авторизован
113 ##[error]At C:\BuildAgents\agent\_work\[...]\Deploy-AzureResourceGroup.ps1:47 char:1
114 ##[error]+ New-AzureResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation ...
115 ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
116 ##[error]+ CategoryInfo : CloseError: (:) [New-AzureResourceGroup], CloudException
117 ##[error]+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.NewAzureResourceGroupCommand
Я могу запустить эти сценарии локально без проблем.
Я попытался импортировать файл настроек публикации в сценарии, но, похоже, New-AzureResourceGroup не разрешает аутентификацию таким образом.
Я запускаю агент сборки как сервис под учетной записью локального пользователя (не сетевой сервис).
Кто-нибудь знает, как разрешить агенту сборки выполнять New-AzureResourceGroup?
Я надеюсь, что смогу выполнить полное непрерывное развертывание, включая настройку и управление всем необходимым в Azure, включая группы ресурсов.
ОБНОВИТЬ
Согласно статье ниже:
"Если вы подключаетесь с помощью этого метода [опубликовать файл настроек], вы можете использовать только команды Azure Service Management (или режим ASM)".
https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-connect/
Я предполагаю, что это относится и к PowerShell Azure.
Итак, действительно ли нет способа управления ресурсами в Azure без использования аутентификации на основе учетной записи?
ОБНОВИТЬ
Спасибо @ bmoore-msft за предоставленную недостающую часть. Я просто добавлю еще один снимок экрана со ссылкой, которую мне нужно было найти, чтобы настроить сборку для запуска под реальной учетной записью.
2 ответа
В Azure Resource Manager вы должны использовать аутентификацию Azure Active Directory, без сертификатов. Так что это относится к cli, PowerShell, REST API и т. Д.
В VSO есть задача сборки для Azure PowerShell. Когда вы используете эту задачу, вы указываете "соединение" или подписку для выполнения задачи как... поэтому вы сохраняете кредиты в VSO. Вы можете использовать обычную задачу PowerShell, но тогда вам придется самостоятельно защищать кредиты.
Наконец, при настройке подключения к учетной записи в VSO это должен быть orgID, MSA не поддерживаются (ограничение PowerShell). Обслуживание Принципал поддержка приходит.
У меня также было много проблем с использованием диспетчера ресурсов Azure с VSO. Наконец-то я нашел рабочее решение своей проблемы, создав учетную запись Service Principal с достаточными правами на подписку Azure для развертывания из Visual Studio Online.
Я использовал эту запись в блоге Дэвида Эббо для создания основной учетной записи службы: http://blog.davidebbo.com/2014/12/azure-service-principal.html
В VSO я удалил шаг "Azure PowerShell" и заменил его на шаг "PowerShell". В сценарии PowerShell я начинаю с входа в учетную запись Service Principal, а затем развертываю свои приложения с помощью Azure Resource Manager.
Более подробную информацию о моих выводах можно найти на форуме MSDN: https://social.msdn.microsoft.com/Forums/azure/en-US/d5a940e0-ed83-46ff-9efc-045fb9522c5b/ad-auth-from-azure-powershell-in-vso-fails-with-accessingwsmetadataexchangefailed?forum=azurescripting