У меня есть приложение, размещенное в Azure, и я использую DevOps Azure для управления конвейерами сборки и выпуска. В рамках выпуска я разогреваю приложение, отправляя запрос к корневому URL-адресу (например, https://myapp.azurewebsites.net).. Чтобы выполнить этот запрос, я должен сначала убедиться, что размещенный агент развертывания, на котором выполняется развертывание, имеет доступ к этому URL-адресу (или я получу 403.) Я написал короткий сценарий PowerShell для этого и поместил его в задачу Azure Powershell. Он добавляет IP-адрес агента сборки в IpSecurityConfiguration службы приложения. Пока все хорошо. Он отлично работает для приложений, которые являются просто приложениями. Когда я пытаюсь использовать его в промежуточной среде, он падает. Когда мы выпускаем в производство, мы сначала помещаем код в промежуточный слот, а затем переворачиваем его, чтобы жить, когда мы " Мы запустили наши тесты и убедились, что все хорошо. Сценарий powershell, который правильно обрабатывает IpSecurityConfiguration для служб приложений, не работает в промежуточном слоте. Для доступа к промежуточному слоту мы используем myappname / slots / staging для переменной $ (WebApiName ), обычно это просто имя службы приложений сам. Опять же, это работает отлично, если я запускаю сценарий из своей локальной среды, он только терпит неудачу в конвейере. Код ниже:
# Whitelist Azure Agent IPs
$agentIP = Invoke-RestMethod http://ipinfo.io/json | Select -exp ip
Write-Host "Connecting to Azure"
$APIVersion = ((Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Web).ResourceTypes | Where-Object ResourceTypeName -eq sites).ApiVersions[0]
Write-Host "API Version is $APIVersion. Getting web app config for $(WebApiName) in $(ResourceGroupName)"
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
Write-Host "Got web app config: $WebApiConfig"
$webIP = [PSCustomObject]@{
ipAddress = "$agentIP/32";
action = "Allow";
tag = 'Default';
priority = 300;
name = $agentIP.ToString();
description = $agentIP.ToString()
}
Write-Host "Adding $agentIP to security restrictions"
$WebApiConfig.Properties.ipSecurityRestrictions += $webIP
Write-Host "Updating security restrictions"
# update app restrictions, do not prompt for confirmation
$result = Set-AzureRmResource -ResourceId $WebApiConfig.ResourceId -Properties $WebApiConfig.Properties -ApiVersion $APIVersion -Force
Чтобы немного испачкать воду, я могу получить точно такой же код, чтобы он прекрасно работал с локальным слотом, изменив
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
до
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites -ResourceName $(WebApiName)/config -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
но это не работает в задаче Azure Powershell. Вместо этого я не могу выполнить развертывание в какой-либо среде, потому что не удается выполнить задачу при попытке доступа к IpSecurityRestrictions для объекта $ WebApiConfig. Исключение составляет "Exception setting "ipSecurityRestrictions": "The property 'ipSecurityRestrictions' cannot be found on this object. Verify that the property exists and can be set.
"
Как я уже говорил ранее, если я запускаю скрипт именно в этой форме локально, он работает отлично. Очевидно, я должен вручную заменить переменные, которые поступают из конвейера сборки, но в остальном нет разницы между кодом, который работает точно так, как я хочу, на моей локальной машине, и кодом, который не работает в выпуске. Вы можете убедиться в этом, поменяв $ (WebApiName) для допустимого имени службы приложения и $ (ResourceGroupName) для группы ресурсов, в которой находится служба приложения. Я поместил строку примерно на полпути, которая выводит $ WebApiConfig, чтобы я мог видеть, что это так, и на моей локальной машине я вижу действительный объект, в то время как в выводе задачи я ничего не получаю. В строке просто написано "Got web app config:"
У кого-нибудь есть идеи?
- Я попытался изменить версию powershell, используемую в задаче, на
соответствует версии, которую я получил.
- Я пытался использовать предварительную версию задачи (v4, иначе я использовал v3).
- Я пробовал каждую перестановку файлов / sites / config везде, о которых я мог подумать при вызове Get-AzureRmResource (поскольку именно это позволило ему работать локально в слоте).
Только одна последняя вещь на случай, если кто-нибудь спросит. Я делаю это таким образом, вместо того, чтобы вносить в белый список все IP-адреса в списке Microsoft (https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653) по двум причинам, во-первых, намного проще поддерживать короткий список наших собственных IP-адресов, а во-вторых, кажется, что есть ошибка где-то таким образом Azure обрабатывает эти определения CIDR, потому что IP-адреса, которые категорически находятся в этих диапазонах, часто блокируются во время наших развертываний, даже когда у нас есть весь белый список файлов. Таким образом, я просто добавляю, какой IP-адрес используется в данный момент динамически, в белый список, и удаляю после того, как мы закончим. Предполагая, что я смогу заставить его работать ...