Поделиться через

Создание среды ASE с помощью шаблона Azure Resource Manager

  • Статья

Обзор

Внимание

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

По состоянию на 31 августа 2024 года соглашение об уровне обслуживания (SLA) и кредиты на обслуживание больше не применяются к рабочим нагрузкам Среда службы приложений версии 1 и 2, которые продолжают работать, так как они являются устаревшими продуктами. Началось списание оборудования Среда службы приложений версии 1 и 2, и это может повлиять на доступность и производительность приложений и данных.

Необходимо выполнить миграцию в Среда службы приложений версии 3 немедленно или удалить приложения и ресурсы. Мы попытаемся выполнить автоматическую миграцию всех оставшихся Среда службы приложений версии 1 и 2 на основе оптимальной работы с помощью функции миграции на месте, но корпорация Майкрософт не утверждает или не гарантирует доступность приложений после автоматической миграции. Вам может потребоваться выполнить настройку вручную, чтобы завершить миграцию и оптимизировать выбор номера SKU плана Служба приложений в соответствии с вашими потребностями. Если автоматическая миграция невозможна, ваши ресурсы и связанные данные приложения будут удалены. Мы настоятельно призываем вас действовать сейчас, чтобы избежать любого из этих экстремальных сценариев.

Если вам потребуется дополнительное время, мы можем предложить одноразовый 30-дневный льготный период для завершения миграции. Дополнительные сведения и запросы на этот льготный период см. в обзоре льготного периода, а затем перейдите к портал Azure и перейдите в колонку "Миграция" для каждого Среда службы приложений.

Последние сведения об обновлении Среда службы приложений версии 1/2 см. в Среда службы приложений обновлении для выхода на пенсию версии 1 и версии 2.

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

ASE можно создать на портале Azure или с помощью шаблона Azure Resource Manager. В этой статье описаны действия и синтаксис, необходимые для создания внешнего ASE или ASE с внутренним балансировщиком нагрузки с помощью шаблонов Resource Manager. Сведения о создании ASEv2 в портал Azure см. в статье [Создание внешнего ASE][MakeExternalASE] или Make a ILB ASE.

При создании ASE в портал Azure вы можете создать виртуальную сеть одновременно или выбрать существующую виртуальную сеть для развертывания.

При создании ASE из шаблона необходимо:

  • Виртуальная сеть Azure.
  • Подсеть в этой виртуальной сети. Рекомендуемый размер подсети ASE — /24 с 256 адресами для расширения и масштабирования в будущем. Ее размер невозможно изменить после создания ASE.
  • Подписка, которая будет использоваться.
  • Расположение для развертывания.

Чтобы автоматизировать создание ASE, следуйте инструкциям в следующих разделах. Если вы создаете ILB ASEv2 с пользовательским dnsSuffix (например, internal.contoso.com), есть несколько действий.

  1. После создания ILB ASE загружается TLS/SSL-сертификат, соответствующий вашему домену ILB ASE.

  2. Выгруженный сертификат TLS/SSL назначается к среде службы приложений с ILB как его сертификат TLS/SSL по умолчанию. Этот сертификат используется для трафика TLS/SSL для приложений в среде службы приложений с ILB, когда они используют общий корневой домен, назначенный к среде службы приложений (например, https://someapp.internal.contoso.com).

Создание ASE

Шаблон Resource Manager, создающий ASE и связанный с ним файл параметров, доступен на сайте GitHub для ASEv2.

Если вы хотите создать ASE, используйте этот пример шаблона ASEv2 шаблона Resource Manager. Большинство параметров в файле azuredeploy.parameters.json используются при создании как ASE с внутренним балансировщиком нагрузки, так и с внешними ASE. Следующий список вызывает параметры специальной заметки или уникальность при создании ASE подсистемы балансировки нагрузки с существующей подсетью.

Параметры

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

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

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

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

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

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

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

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

  • Subject — для этого атрибута необходимо задать значение \*.имя_корневого_домена.com.
  • Альтернативное имя субъекта: этот атрибут должен включать как your-root-domain-here.com, так и *.scm.your-root-domain-here.com*. Подключения TLS к сайту SCM/Kudu, связанному с каждым приложением, используют адрес в форме имя-вашего-приложения.scm.ваш-корневой-домен-здесь.com.

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

Файл .pfx необходимо преобразовать в строку base64, поскольку сертификат TLS/SSL загружается с использованием шаблона диспетчера ресурсов. Такое преобразование требуется, так как шаблоны 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, используйте пример шаблона Resource Manager Настройка SSL-сертификата по умолчанию на GitHub.

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

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

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

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

Применение изменений для одного внешнего интерфейса ASE занимает примерно 40 минут. Например, для ASE по умолчанию, использующего две внешние части, шаблон занимает около 1 часа и 20 минут. Во время выполнения шаблона нельзя масштабировать среду ASE.

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

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