Перенос Шлюз приложений Azure и Брандмауэр веб-приложений из версии 1 в версию 2

Статья
02/26/2024

Мы объявили об отмене Шлюз приложений SKU версии 1 (standard и WAF) 28 апреля 2023 года. Номер SKU версии 1 выходит на пенсию 28 апреля 2026 года. Дополнительные сведения см. в статье "Миграция Шлюз приложений с номера SKU версии 1 на номер SKU версии 2 к 28 апреля 2026 г.

Шлюз приложений Azure и Брандмауэр веб-приложений (WAF) V2 теперь предлагают дополнительные функции, такие как автомасштабирование, доступность, избыточность зон, более высокая производительность, более быстрые операции и улучшенная пропускная способность по сравнению с V1. Кроме того, для SKU версии 2 выпускаются все новые функции. Настоятельно рекомендуется создать план миграции.

Шлюзы версии 1 не обновляются автоматически до версии 2. Используйте это руководство по миграции, чтобы спланировать и выполнить миграцию.

Миграция выполняется в два этапа:

перенос конфигурации;
перенос клиентского трафика.

Эта статья в основном помогает с миграцией конфигурации. Миграция трафика клиента зависит от среды. Некоторые общие рекомендации приведены в этой статье.

Необходимые компоненты

Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
Существующий Шлюз приложений версии 1 уровня "Стандартный".
Убедитесь, что у вас есть последняя версия модулей PowerShell, или перейдите к Azure Cloud Shell на портале.
При использовании PowerShell на локальном компьютере также нужно запустить Connect-AzAccount, чтобы создать подключение к Azure.
Убедитесь, что в подписке версии 1 нет существующего шлюза приложений с указанным именем имени и группы ресурсов AppGW версии 2. При этом перезаписываются существующие ресурсы.
Если указан общедоступный IP-адрес, убедитесь, что он находится в успешном состоянии. Если не указано и AppGWResourceGroupName предоставляется, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке V1.
Убедитесь, что во время миграции не планируется никаких других операций на шлюзе версии 1 или любых связанных ресурсах.

Azure Cloud Shell

В Azure есть Azure Cloud Shell, интерактивная оболочка среды, с которой можно работать в браузере. Для работы со службами Azure можно использовать Bash или PowerShell с Cloud Shell. Для запуска кода из этой статьи можно использовать предварительно установленные команды Cloud Shell. Ничего дополнительного в локальной среде устанавливать не нужно.

Начало работы с Azure Cloud Shell

Вариант	Пример и ссылка
Нажмите кнопку Попробовать в правом верхнем углу блока кода или команд. При нажатии кнопки Попробовать код или команда не копируется в Cloud Shell автоматически.
Чтобы открыть Cloud Shell в браузере, перейдите по адресу https://shell.azure.com или нажмите кнопку Запуск Cloud Shell.
Нажмите кнопку Cloud Shell в строке меню в правом верхнем углу окна портала Azure.

Чтобы использовать Azure Cloud Shell, выполните следующие действия:

Запустите Cloud Shell.
Нажмите кнопку Копировать в блоке кода (или блоке команд), чтобы скопировать код или команду.
Вставьте код или команду в окно сеанса Cloud Shell, нажав клавиши CTRL+SHIFT+V в Windows и Linux или CMD+SHIFT+V в macOS.
Нажмите клавишу ВВОД, чтобы запустить код или команду.

Примечание.

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Внимание

Set-AzContext -Subscription <V1 application gateway SubscriptionId> Запустите командлет каждый раз перед запуском скрипта миграции. Это необходимо для настройки активного контекста Azure в правильной подписке, так как скрипт миграции может очистить существующую группу ресурсов, если она не существует в текущем контексте подписки. Это не обязательный шаг для сценария миграции версии 1.0.11 и выше.

Внимание

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

Миграция конфигурации

Скрипт Azure PowerShell представлен в этом документе. Он выполняет следующие операции, которые помогут вам в настройке:

Создает новый шлюз Standard_V2 или WAF_V2 в указанной подсети виртуальной сети.
Легко копирует конфигурацию, связанную с шлюзом V1 Standard или WAF, в только что созданный шлюз Standard_V2 или WAF_V2.

Скачивание скрипта

Скрипт миграции можно скачать из коллекция PowerShell. Доступен новый стабильный выпуск (версия 1.0.11) скрипта миграции, который включает в себя основные обновления и исправления ошибок. Рекомендуется использовать эту стабильную версию.

Использование скрипта

Примечание.

В зависимости от настроек и параметров локального окружения PowerShell существует два варианта использования скрипта:

если вы не установили модули Azure Az или же хотите удалить их, лучше всего запустить скрипт с помощью Install-Script;
если же модули Azure Az нужно сохранить, лучше всего загрузить скрипт и запустить его напрямую.

Чтобы определить, установлены ли модули Azure Az, выполните команду Get-InstalledModule -Name az. Если установленных модулей Az нет, можно использовать метод Install-Script.

Установка с помощью метода Install-Script (рекомендуется)

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

Запустите скрипт с помощью следующей команды, чтобы получить последнюю версию:

Install-Script -Name AzureAppGWMigration -Force

Эта команда также устанавливает необходимые модули Az.

Установка путем запуска скрипта напрямую

Если у вас установлены некоторые модули Azure Az и их не удается удалить (или не хотите их удалить), можно вручную скачать сценарий с помощью вкладки "Скачивание вручную" в ссылке скачивания скрипта. Скрипт скачивается как необработанный NUPKG-файл. Сведения об установке скрипта из этого NUPKG-файла см. в статье Скачивание пакета вручную.

Версия 1.0.11 — это новая версия скрипта миграции, которая включает основные исправления ошибок. Рекомендуется использовать эту стабильную версию.

Как проверка версию скачаемого скрипта

Чтобы проверка версию скачаемого скрипта, выполните следующие действия.

Извлечь содержимое пакета NuGet в локальную папку.
.PS1 Откройте файл в папке и проверка .VERSION сверху, чтобы подтвердить версию скачаемого скрипта.

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Обязательно используйте последнюю стабильную версию из коллекция PowerShell

Запуск скрипта

Выполните следующее, чтобы запустить этот сценарий.

Подключитесь к Azure с помощью команды Connect-AzAccount.
Импортируйте модули Az с помощью команды Import-Module Az.
Set-AzContext Запустите командлет, чтобы задать активный контекст Azure для правильной подписки. Это важный шаг, так как сценарий миграции может очистить существующую группу ресурсов, если она не существует в текущем контексте подписки.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```

Запустите Get-Help AzureAppGWMigration.ps1, чтобы проверить обязательные параметры:

AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Примечание.

Во время миграции не пытайтесь выполнить любую другую операцию на шлюзе версии 1 или любых связанных ресурсах.

Параметры скрипта

resourceId: [String]: обязательный: этот параметр является идентификатором ресурса Azure для существующего шлюза Standard V1 или WAF версии 1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите свой шлюз приложений или ресурс WAF и щелкните ссылку Свойства для шлюза. На этой странице будет указан идентификатор ресурса.

Чтобы получить идентификатор ресурса, также можно выполнить следующие команды Azure PowerShell:
```
$appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id
```
subnetAddressRange: [String]: обязательный: этот параметр — это пространство IP-адресов, которое вы выделили (или хотите выделить) для новой подсети, содержащей новый шлюз версии 2. Адресное пространство должно быть указано в нотации CIDR. Пример: 10.0.0.0/24. Вам не нужно заранее создать эту подсеть, но CIDR должна быть частью адресного пространства виртуальной сети. Скрипт создает его для вас, если он не существует и если он существует, он использует существующий (убедитесь, что подсеть пуста, содержит только шлюз версии 2, если он есть, и имеет достаточно доступных IP-адресов).
appgwName: [String]: необязательный. Это строка, используемая в качестве имени нового Standard_V2 или шлюза WAF_V2. Если этот параметр не указан, имя существующего шлюза версии 1 используется с суффиксом _V2 добавлен.
AppGWResourceGroupName: [String]: необязательно. Имя группы ресурсов, в которой требуется создать ресурсы версии 2 Шлюз приложений (значение <V1-app-gw-rgname>по умолчанию )

Примечание.

Убедитесь, что в подписке версии 1 нет существующего шлюза приложений с указанным именем имени и группы ресурсов AppGW версии 2. При этом перезаписываются существующие ресурсы.

sslCertificates: [PSApplicationGatewaySslCertificate]: необязательный. Разделенный запятыми список объектов PSApplicationGatewaySslCertificate, создаваемых для представления сертификатов TLS/SSL из шлюза V1, необходимо отправить в новый шлюз V2. Для каждого сертификата TLS/SSL, настроенного для шлюза Standard V1 или WAF V1, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды, показанной New-AzApplicationGatewaySslCertificate здесь. Вам потребуется путь к файлу сертификата TLS/SSL и пароль к нему.

Этот параметр является необязательным, если у вас нет прослушивателей HTTPS, настроенных для шлюза версии 1 или WAF. При наличии хотя бы одного прослушивателя HTTPS указывать этот параметр необходимо.
```
$password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password
```
Значения для этого параметра в скрипте можно передать в виде $mySslCert1, $mySslCert2 (с разделителями-запятыми), как в предыдущем примере.

sslCertificates из Keyvault: необязательно. Вы можете скачать сертификаты, хранящиеся в Azure Key Vault, и передать его в скрипт миграции. Чтобы скачать сертификат в виде PFX-файла, выполните следующую команду. Эти команды обращаются к параметру SecretId, а затем сохраняют его содержимое в виде PFX-файла.

 $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

Для каждого сертификата, скачаенного из Keyvault, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды New-AzApplicationGatewaySslCertificate, показанной здесь. Вам потребуется путь к файлу сертификата TLS/SSL и пароль к нему.

//Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: необязательный. Разделенный запятыми список объектов PSApplicationGatewayTrustedRootCertificate доверенных корневых сертификатов для проверки подлинности экземпляров серверной части шлюза версии 2.
```
$certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
```
Чтобы создать список объектов PSApplicationGatewayTrustedRootCertificate, воспользуйтесь командой New-AzApplicationGatewayTrustedRootCertificate.
privateIpAddress: [String]: необязательный. Конкретный частный IP-адрес, который требуется связать с новым шлюзом версии 2. Это должно быть из той же виртуальной сети, которую вы выделяете для нового шлюза версии 2. Если это не указано, скрипт выделяет частный IP-адрес для шлюза версии 2.
publicIpResourceId: [String]: необязательный. ResourceId существующего ресурса общедоступного IP-адреса (стандартный номер SKU) в подписке, которую вы хотите выделить для нового шлюза версии 2. Если указано имя ресурса общедоступного IP-адреса, убедитесь, что он существует в успешном состоянии. Если это не указано, скрипт выделяет новый общедоступный IP-адрес в той же группе ресурсов. Имя шлюза версии 2 с добавленным IP-адресом . Если appGWResourceGroupName предоставлен и общедоступный IP-адрес не указан, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке V1.
validateMigration: [switch]: необязательный . Этот параметр позволяет скрипту выполнять некоторые базовые проверки сравнения конфигурации после создания шлюза версии 2 и копирования конфигурации. По умолчанию проверка не выполняется.
enableAutoScale: [switch]: необязательный. Используйте этот параметр, чтобы включить автоматическое масштабирование на новом шлюзе версии 2 после его создания. По умолчанию автомасштабирование отключено. Вы всегда можете включить его вручную в новом шлюзе версии 2.

Запустите скрипт с соответствующими параметрами. Его выполнение может занять от пяти до семи минут.

Пример

AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Предостережения и ограничения

Новый шлюз версии 2 имеет новые общедоступные и частные IP-адреса. Невозможно легко переместить IP-адреса, связанные с существующим шлюзом версии 1, в версию 2. Однако вы можете выделить существующий (нераспределенный) общедоступный или частный IP-адрес для нового шлюза версии 2.
Необходимо указать пространство IP-адресов для другой подсети в виртуальной сети, где находится шлюз версии 1. Скрипт не может создать шлюз версии 2 в подсети, которая уже имеет шлюз версии 1. Если подсеть уже имеет шлюз версии 2, скрипт может по-прежнему работать, укажите достаточное пространство IP-адресов.
Если у вас есть группа безопасности сети или определяемые пользователем маршруты, связанные с подсетью шлюза версии 2, убедитесь, что они соответствуют требованиям NSG и требованиям UDR для успешной миграции.
Политики конечных точек служб для виртуальной сети в настоящее время не поддерживаются в подсети Шлюза приложений.
Чтобы перенести конфигурацию TLS/SSL, необходимо указать все сертификаты TLS/SSL, используемые в шлюзе версии 1.
Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2. Режим FIPS не поддерживается в версии 2.
Если у вас есть только частный IP-адрес шлюза версии 1, скрипт создает частный и общедоступный IP-адрес для нового шлюза версии 2. Частный IP-адрес только шлюз версии 2 в настоящее время находится в общедоступной предварительной версии. После того как он станет общедоступным, клиенты могут использовать скрипт для передачи своего частного IP-адреса только шлюзу версии 1 на частный IP-адрес только шлюз версии 2.
Проверка подлинности NTLM и Kerberos не поддерживается Шлюз приложений версии 2. Скрипт не может определить, обслуживает ли шлюз этот тип трафика и может представлять собой критическое изменение от шлюзов версии 1 до шлюзов версии 2 при запуске.
WAFv2 создается в старом режиме конфигурации WAF; Требуется миграция в политику WAF.

Миграция трафика

Во-первых, дважды проверка, что скрипт успешно создал новый шлюз версии 2 с точной конфигурацией, перенесенной из шлюза версии 1. Это можно сделать на портале Azure.

Кроме того, отправьте небольшой объем трафика через шлюз версии 2 в виде ручного теста.

Ниже приведены некоторые сценарии, в которых текущий шлюз приложений (стандартный) может получать клиентский трафик, и наши рекомендации по каждому из них:

Настраиваемая зона DNS (например, contoso.com), указывающая на внешний IP-адрес (используя запись A), связанную с шлюзом Standard V1 или WAF V1.

Вы можете обновить запись DNS, чтобы указать на внешний IP-адрес или метку DNS, связанную с шлюзом приложений Standard_V2. В зависимости от срока жизни, настроенного в записи DNS, может потребоваться некоторое время для переноса всего трафика клиента на новый шлюз версии 2.
Настраиваемая зона DNS (например, contoso.com), указывающая на метку DNS (например , myappgw.eastus.cloudapp.azure.com с записью CNAME), связанную с шлюзом V1.

Есть два варианта:
- Если вы используете общедоступные IP-адреса в шлюзе приложений, вы можете выполнить контролируемую, детализированную миграцию с помощью профиля Диспетчер трафика для добавочного маршрутизации трафика (взвешированного метода маршрутизации трафика) в новый шлюз версии 2.
  
  Это можно сделать, добавив метки DNS шлюзов приложений версии 1 и версии 2 в профиль Диспетчер трафика и CNAMEing настраиваемую запись DNS (например, ) в домен Диспетчер трафика (например, www.contoso.comcontoso.trafficmanager.net).
- Кроме того, вы можете обновить запись DNS личного домена, чтобы указать на метку DNS нового шлюза приложений версии 2. В зависимости от срока жизни, настроенного в записи DNS, может потребоваться некоторое время для переноса всего трафика клиента на новый шлюз версии 2.
Клиенты подключаются к внешнему IP-адресу шлюза приложений.

Обновите клиенты, чтобы использовать IP-адреса, связанные с недавно созданным шлюзом приложений версии 2. Использовать IP-адреса напрямую не рекомендуется. Вместо этого следует использовать метку DNS-имени (например, yourgateway.eastus.cloudapp.azure.com), связанную с вашим шлюзом приложений, которые можно с помощью записи CNAME направить на вашу собственную зону DNS (например, contoso.com).

Сведения о ценах

Модели ценообразования отличаются для номеров SKU Шлюз приложений версии 1 и V2. Плата за версию 2 взимается на основе потребления. См. Шлюз приложений цены перед переносом сведений о ценах.

Руководство по повышению эффективности затрат

SKU версии 2 поставляется с рядом преимуществ, таких как повышение производительности 5x, улучшенная безопасность с интеграцией Key Vault, более быстрые обновления правил безопасности в WAF_V2, пользовательских правилах WAF, сопоставлениях политик и защите ботов. Она также обеспечивает высокую масштабируемость, оптимизированную маршрутизацию трафика и простую интеграцию со службами Azure. Эти функции могут улучшить общий пользовательский интерфейс, предотвратить замедление во время интенсивного трафика и избежать дорогостоящих нарушений данных.

Существует пять вариантов в номере SKU версии 1 на основе уровня и размера — Standard_Small, Standard_Medium, Standard_Large, WAF_Medium и WAF_Large.

номер SKU	Исправленная цена версии 1/mo	Исправленная цена версии 2/mo	Рекомендация
Стандартный средний	102.2	179.8	Номер SKU версии 2 может обрабатывать большее количество запросов, чем шлюз версии 1, поэтому рекомендуется объединить несколько шлюзов V1 в один шлюз версии 2, чтобы оптимизировать затраты. Убедитесь, что консолидация не превышает пределы Шлюз приложений. Рекомендуется консолидация 3:1.
Средний WAF	183.96	262.8	То же, что и для среднего уровня "Стандартный"
Стандартный большой	467.2	179.58	В большинстве случаев переход на шлюз версии 2 обеспечивает более высокую ценовую выгоду по сравнению с версией 1.
WAF Large	654.08	262.8	То же, что и для стандартного большого размера

Примечание.

Приведенные здесь вычисления основаны на восточной части США и шлюзе с 2 экземплярами в версии 1. Переменная стоимость в версии 2 основана на одном из 3 измерений с наибольшим использованием: новые подключения (50/с), постоянные подключения (2500 постоянных подключений/мин), пропускная способность (1 CU может обрабатывать 2,22 Мбит/с).

Описанные здесь сценарии являются примерами и предназначены только для иллюстрации. Дополнительные сведения о ценах в соответствии с вашим регионом см. на странице цен.

Для дальнейших проблем с ценами обратитесь к CSAM или обратитесь к нашей группе поддержки за помощью.

Часто задаваемые вопросы

Распространенные вопросы о миграции можно найти здесь

Следующие шаги

Сведения о Шлюз приложений версии 2

Перенос Шлюз приложений Azure и Брандмауэр веб-приложений из версии 1 в версию 2

Необходимые компоненты

Azure Cloud Shell

Миграция конфигурации

Скачивание скрипта

Использование скрипта

Установка с помощью метода Install-Script (рекомендуется)

Установка путем запуска скрипта напрямую

Как проверка версию скачаемого скрипта

Запуск скрипта

Предостережения и ограничения

Миграция трафика

Сведения о ценах

Руководство по повышению эффективности затрат

Часто задаваемые вопросы

Следующие шаги

Дополнительные ресурсы