Как обновить белый список IP-адресов для промежуточного слота через Azure Powershell из конвейера выпуска DevOps Azure? - PullRequest
1 голос
/ 13 марта 2019

У меня есть приложение, размещенное в 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-адрес используется в данный момент динамически, в белый список, и удаляю после того, как мы закончим. Предполагая, что я смогу заставить его работать ...

1 Ответ

0 голосов
/ 18 марта 2019

Наконец-то разобрался с решением этой проблемы.Для работы со слотами тип ресурса должен быть немного другим.Эта строка работает в задаче Azure Powershell:

$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/slots/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)

Публикация на случай, если она поможет кому-либо еще с такой же проблемой.Я могу подтвердить, что выбранный мною подход прекрасно работает при управлении доступом к сайтам Azure с помощью агентов сборки и избавляет от множества проблем с файлом XML агента сборки Microsoft.

...