Создание Среды службы приложений версии 1 с внутренней подсистемой балансировки нагрузки с помощью шаблонов Azure Resource Manager

Статья
06/01/2023

Внимание

Эта статья посвящена Среде службы приложений версии 1. 31 августа 2024 года будет прекращена поддержка Среды службы приложений версии 1. Имеется новая версия среды службы приложений, которая проще в использовании и которая работает на более мощной инфраструктуре. Чтобы узнать больше о новой версии, начните с изучения статьи Введение в Среду службы приложений. Если вы используете Среду службы приложений версии 1, выполните действия, описанные в этой статье, чтобы перейти на новую версию.

По состоянию на 29 января 2024 г. вы больше не можете создавать новые ресурсы Среда службы приложений версии 1 с помощью любого из доступных методов, включая шаблоны ARM/Bicep, портал Azure, Azure CLI или REST API. Необходимо выполнить миграцию в Среда службы приложений версии 3 до 31 августа 2024 г., чтобы предотвратить удаление ресурсов и потерю данных.

Обзор

Вместо общедоступного виртуального IP-адреса для создания среды службы приложений (ASE) можно использовать внутренний адрес виртуальной сети. Этот внутренний адрес принадлежит компоненту Azure, который называется внутренним балансировщиком нагрузки. Среду ASE с внутренним балансировщиком нагрузки можно создать на портале Azure. Ее также можно создать автоматически с помощью шаблонов Azure Resource Manager. В этой статье описаны действия и синтаксис, необходимые для создания ASE с внутренним балансировщиком нагрузки с помощью шаблонов Azure Resource Manager.

Автоматическое создание среды ASE с внутренним балансировщиком нагрузки предусматривает три шага:

Сначала в виртуальной сети создается базовая среда ASE, для чего вместо общедоступного виртуального IP-адреса используется адрес внутреннего балансировщика нагрузки. Кроме того, на этом шаге ASE с внутренним балансировщиком нагрузки присваивается имя корневого домена.
После создания ASE с ILB передается TLS/SSL-сертификат.
Переданный TLS/SSL-сертификат явным образом назначается ASE с внутренней подсистемой балансировки нагрузки в качестве TLS/SSL-сертификата по умолчанию. Этот сертификат будет использоваться для передачи трафика TLS в приложения в среде службы приложений с внутренней подсистемой балансировки нагрузки, если при обращении к ним используется общий корневой домен, назначенный этой среде (например, https://someapp.mycustomrootcomain.com).

Создание базовой среды ASE с внутренним балансировщиком нагрузки

Пример шаблона Azure Resource Manager и соответствующий файл параметров доступны здесь.

Большинство параметров в файле azuredeploy.parameters.json используются при создании как ASE с внутренним балансировщиком нагрузки, так и ASE с привязкой к общедоступному виртуальному IP-адресу. Ниже приведены параметры с особыми примечаниями и уникальные параметры, используемые при создании ASE с внутренним балансировщиком нагрузки.

internalLoadBalancingMode: определяет, как отображаются порты управления и данных.
- Значение 3 означает, что трафик HTTP и HTTPS на портах 80 и 443 и порты канала данных и канала управления, прослушиваемые FTP-службой в Среде службы приложений, будут привязаны к внутреннему адресу в виртуальной сети, выделенному внутренним балансировщиком нагрузки.
- Если задать для этого свойства значение 2, к адресу внутреннего балансировщика нагрузки будут привязаны только порты, связанные со службой FTP (канала данных и канала управления), а HTTP- и HTTP-трафик останется привязанным к общедоступному виртуальному IP-адресу.
- Значение 0 означает, что весь трафик привязан к общедоступному виртуальному IP-адресу, в результате чего ASE становится внешней.
dnsSuffix: этот параметр определяет корневой домен по умолчанию, который будет назначен среде службы приложений. В общедоступной версии службы приложений Azure корневой домен по умолчанию для всех веб-приложений — azurewebsites.net. Однако так как ASE с внутренним балансировщиком нагрузки является внутренней для виртуальной сети пользователя, бессмысленно использовать корневой домен по умолчанию общедоступной службы. Вместо этого ASE с внутренним балансировщиком нагрузки необходимо назначить корневой домен по умолчанию, который целесообразно использовать в пределах внутренней виртуальной сети компании. Например, гипотетическая корпорация Contoso может использовать корневой домен по умолчанию internal.contoso.com для приложений, предназначенных только для разрешения и доступа в виртуальной сети Contoso.
ipSslAddressCount: для этого параметра в файле azuredeploy.json автоматически задается значение 0, так как средам службы приложений с внутренним балансировщиком нагрузки назначен только адрес этого балансировщика. Для ASE с внутренним балансировщиком нагрузки нет явно заданных адресов SSL на основе IP, поэтому для пула этих адресов необходимо задать значение 0. В противном случае произойдет ошибка подготовки.

Когда файл azuredeploy.parameters.json для ASE с внутренним балансировщиком нагрузки будет заполнен, можно приступить к созданию соответствующей среды с помощью приведенного ниже фрагмента кода Powershell. Измените пути к файлам в соответствии с расположением файлов шаблонов Azure Resource Manager на вашем компьютере. Кроме того, введите собственные значения для имени развертывания Azure Resource Manager и группы ресурсов.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

После отправки шаблона Azure Resource Manager для создания ASE с внутренним балансировщиком нагрузки потребуется несколько часов. Созданная ASE с внутренним балансировщиком нагрузки появится на портале в списке сред службы приложений для подписки, использованной для развертывания.

Загрузка и настройка TLS/SSL-сертификата по умолчанию

После создания среды ASE с внутренней подсистемой балансировки нагрузки ей необходимо назначить TLS/SSL-сертификат по умолчанию, который будет использоваться для установки TLS/SSL-подключений к приложениям. Продолжая гипотетический пример Contoso Corporation, если суффикс DNS по умолчанию ASE internal.contoso.com, подключение требует https://some-random-app.internal.contoso.com tls/SSL-сертификата, допустимого для *.internal.contoso.com.

Есть множество способов получить действительный TLS/SSL-сертификат: в частности, можно получить сертификат от внутреннего центра сертификации, приобрести его у внешнего поставщика и использовать самозаверяющий сертификат. Независимо от источника TLS/SSL-сертификата для него необходимо соответствующим образом настроить следующие атрибуты:

Subject — для этого атрибута необходимо задать значение \*.имя_корневого_домена.com.
Subject Alternative Name — этот атрибут должен содержать два значения: \*.имя_корневого_домена.com и \*.scm.имя_корневого_домена.com. Вторая запись требуется, так как для TLS-подключений к сайту SCM или Kudu, связанному с каждым приложением, будет использоваться адрес в формате имя_приложения.scm.имя_корневого_домена.com.

При наличии действующего сертификата TLS/SSL необходимы два дополнительных подготовительных шага. TLS/SSL-сертификат необходимо преобразовать в PFX-файл и сохранить в таком формате. PFX-файл должен содержать все промежуточные и корневые сертификаты, а также быть защищен паролем.

Затем PFX-файл необходимо преобразовать в строку Base64, так как TLS/SSL-сертификат будет загружен с использованием шаблона Azure Resource Manager. Эти шаблоны представлены в виде текстовых файлов. Такое преобразование требуется, чтобы добавить PFX-файл в качестве параметра шаблона.

В приведенном ниже фрагменте кода Powershell показано, как создать самозаверяющий сертификат, экспортировать его в формате PFX-файла, преобразовать PFX-файл в строку в кодировке Base64 и сохранить эту строку в отдельном файле. Код PowerShell для преобразования в строку в кодировке Base64 взят из блога скриптов Powershell.

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password     

$fileContentBytes = get-content -encoding byte $fileName
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$fileContentEncoded | set-content ($fileName + ".b64")

Когда сертификат TLS/SSL будет создан и преобразован в строку в кодировке Base64, можно приступить к настройке сертификата TLS/SSL по умолчанию с использованием шаблона Azure Resource Manager.

Ниже перечислены параметры, содержащиеся в файле azuredeploy.parameters.json .

appServiceEnvironmentName— имя настраиваемой ASE с внутренним балансировщиком нагрузки.
existingAseLocation— текстовая строка, содержащая регион Azure, где развернута ASE с внутренним балансировщиком нагрузки. Например, центрально-южная часть США.
pfxBlobString — представление PFX-файла в виде строки в кодировке Base64. Нужно скопировать строку, содержащуюся в файле exportedcert.pfx.b64, и вставить ее в качестве значения атрибута pfxBlobString в фрагменте кода выше.
password— пароль, используемый для защиты PFX-файла.
certificateThumbprint— отпечаток сертификата. Если вы получите это значение из PowerShell (например, значение $certThumbprint в приведенном выше фрагменте кода), его можно использовать без каких-либо изменений. Однако если вы скопируете это значение в диалоговом окне сертификатов Windows, в нем нужно удалить лишние пробелы. Значение атрибута certificateThumbprint должно выглядеть следующим образом: AF3143EB61D43F6727842115BB7F17BBCECAECAE.
certificateName— понятный идентификатор строки для идентификации сертификата, который пользователь может выбрать по своему усмотрению. Это имя используется как часть уникального идентификатора Azure Resource Manager для сущности Microsoft.Web/certificates, представляющей TLS/SSL-сертификат. Имя должно заканчиваться таким суффиксом: _имя_ASE_InternalLoadBalancingASE. Этот суффикс сообщает порталу о том, что для обеспечения безопасности ASE с поддержкой ILB используется сертификат.

Ниже приведен сокращенный пример файла azuredeploy.parameters.json .

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "appServiceEnvironmentName": {
            "value": "yourASENameHere"
        },
        "existingAseLocation": {
            "value": "East US 2"
        },
        "pfxBlobString": {
            "value": "MIIKcAIBAz...snip...snip...pkCAgfQ"
        },
        "password": {
            "value": "PASSWORDGOESHERE"
        },
        "certificateThumbprint": {
            "value": "AF3143EB61D43F6727842115BB7F17BBCECAECAE"
        },
        "certificateName": {
            "value": "DefaultCertificateFor_yourASENameHere_InternalLoadBalancingASE"
        }
    }
}

Когда файл azuredeploy.parameters.json будет заполнен, переходите к настройке TLS/SSL-сертификата по умолчанию, используя приведенный ниже фрагмент кода Powershell. Измените пути к файлам в соответствии с расположением файлов шаблонов Azure Resource Manager на вашем компьютере. Кроме того, введите собственные значения для имени развертывания Azure Resource Manager и группы ресурсов.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

Когда шаблон Azure Resource Manager будет отправлен, применение изменений для одного внешнего интерфейса ASE займет примерно 40 минут. Например, для среды ASE с размером по умолчанию, содержащей два внешних интерфейса, реализация шаблона займет примерно один час и 20 минут. Во время выполнения шаблона нельзя масштабировать среду ASE.

Когда шаблон будет реализован, к приложениям в среде ASE с внутренней подсистемой балансировки нагрузки можно будет обращаться по протоколу HTTPS, а подключения будут защищены с помощью TLS/SSL-сертификата по умолчанию. TLS/SSL-сертификат по умолчанию будет использоваться, если обращение к приложениям в ASE с внутренней подсистемой балансировки нагрузки осуществляется с помощью сочетания имени приложения и имени узла по умолчанию. Например, https://mycustomapp.internal.contoso.com используется сертификат TLS/SSL по умолчанию для *.internal.contoso.com.

Так же, как и для приложений в общедоступной мультиклиентской службе, разработчики могут настроить для отдельных приложений пользовательские имена узлов и уникальные привязки TLS/SSL-сертификатов SNI.

Начало работы

Сведения о том, как начать работу со средами службы приложений, см. в статье Введение в среду службы приложений.

Примечание.

Чтобы приступить к работе со службой приложений Azure до создания учетной записи Azure, перейдите к разделу Пробное использование службы приложений, где вы можете быстро создать кратковременное веб-приложение начального уровня в службе приложений. Никаких кредитных карт и обязательств

Создание Среды службы приложений версии 1 с внутренней подсистемой балансировки нагрузки с помощью шаблонов Azure Resource Manager

Обзор

Создание базовой среды ASE с внутренним балансировщиком нагрузки

Загрузка и настройка TLS/SSL-сертификата по умолчанию

Начало работы

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