Azure Resource Manager テンプレートを使用して ILB ASEv1 を作成する方法

[アーティクル]
08/22/2024

重要

この記事は、App Service Environment v1 に関するものです。 App Service Environment v1 と v2 は、2024 年 8 月 31 日の時点で廃止されます。より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 は廃止された製品になるため、これらのワークロードに対してはサービスレベルアグリーメント (SLA) とサービスクレジットが適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止が開始されており、これが使用中のアプリやデータの可用性とパフォーマンスに影響を及ぼす場合があります。

お客様は、App Service Environment v3 への移行を迅速に完了する必要があります。これを行わないと、アプリとリソースが削除される場合があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。自動移行を実行できない場合、使用中のリソースと関連するアプリデータは削除されます。これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。

時間的猶予が必要な場合は、移行を完了するための一回限りの 30 日間の猶予期間を設定することができます。この猶予期間の詳細と要求方法について、猶予期間の概要に関する記事を確認した後、Azure portal にアクセスして、各 App Service Environment の [移行] ブレードに移動してください。

App Service Environment v1/v2 の提供終了に関する最新情報については、App Service Environment v1 と v2 の提供終了に関する更新情報の記事を参照してください。

概要

App Service Environment は、パブリック VIP の代わりに仮想ネットワークの内部アドレスを使用して作成することができます。この内部アドレスは、内部ロードバランサー (ILB) と呼ばれる Azure コンポーネントによって提供されます。 ILB ASE は、Azure ポータルを使用して作成できます。また、Azure Resource Manager テンプレートによる自動化を利用して作成することもできます。この記事では、Azure Resource Manager テンプレートを使用して ILB ASE を作成するために必要な手順と構文について詳しく説明します。

ILB ASE の自動作成は、次に示す 3 つの手順で実行されます。

まず、パブリック VIP の代わりに内部ロードバランサーのアドレスを使用し、仮想ネットワーク内にベース ASE が作成されます。この手順には、ルートドメイン名を ILB ASE に割り当てる操作も含まれます。
ILB ASE の作成が完了すると、TLS/SSL 証明書がアップロードされます。
アップロードされた TLS/SSL 証明書は、"既定の" TLS/SSL 証明書として ILB ASE に明示的に割り当てられます。この TLS/SSL 証明書は、ILB ASE 上のアプリが ASE に割り当てられた共通ルートドメイン (https://someapp.mycustomrootcomain.com など) を使用してアドレス指定されている場合に、そのアプリへの TLS トラフィックに使用されます。

ベース ILB ASE の作成

Azure Resource Manager テンプレートの例と、それに関連するパラメーターファイルは、こちらから入手できます。

azuredeploy.parameters.json ファイルのパラメーターのほとんどは、ILB ASE と、パブリック VIP にバインドされた ASE の両方の作成に共通するパラメーターです。以下の一覧では、ILB ASE を作成するうえで特に注意が必要なパラメーターや、固有のパラメーターについて説明します。

internalLoadBalancingMode: コントロールとデータのポートを公開する方法を決定します。
- 3 に設定すると、ポート 80/443 の HTTP/HTTPS トラフィックと、ASE 上の FTP サービスがリッスンするコントロール/データチャネルポートの両方が、ILB が割り当てた仮想ネットワークの内部アドレスにバインドされます。
- 2 に設定すると、FTP サービス関連のポート (コントロールとデータの両方のチャネル) のみが ILB アドレスにバインドされ、HTTP/HTTPS トラフィックにはパブリック VIP が使用されます。
- 0 に設定すると、すべてのトラフィックがパブリック VIP にバインドされ、ASE が外部になります。
dnsSuffix: このパラメーターでは、ASE に割り当てられる既定のルートドメインを定義します。 Azure App Service のパブリック版では、すべての Web アプリの既定のルートドメインは azurewebsites.netです。しかし、ILB ASE はユーザーの仮想ネットワーク内部に位置することから、パブリックサービスの既定のルートドメインを使用しても意味がありません。 ILB ASE には、会社の内部仮想ネットワーク内での使用に適した既定のルートドメインを用意する必要があります。たとえば、Contoso Corporation という架空の企業では、Contoso の仮想ネットワーク内でのみ解決およびアクセス可能になるよう設計されたアプリに対して、internal.contoso.com という既定のルートドメインが使用されます。
ipSslAddressCount: ILB ASE には単一の ILB アドレスしかないため、このパラメーターの既定値は、azuredeploy.json ファイル内で 0 の値に自動設定されます。 ILB ASE 用の明示的な IP-SSL アドレスがないため、ILB ASE の IP-SSL アドレスプールはゼロに設定する必要があり、ゼロ以外に設定するとプロビジョニングエラーが発生します。

ILB ASE に関して azuredeploy.parameters.json ファイルへの入力が完了したら、以下の PowerShell コードスニペットを使用して ILB ASE を作成することができます。ファイルパスは、マシン上の 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 テンプレートを送信した後、ILB ASE が作成されるまでには数時間かかります。作成が完了すると、ポータル UX で、デプロイを開始したサブスクリプションの App Service Environment の一覧に ILB ASE が表示されます。

"既定の" TLS/SSL 証明書のアップロードと構成

ILB ASE を作成したら、TLS/SSL 証明書を、アプリへの TLS/SSL 接続を確立するために使用する "既定の" TLS/SSL証明書として ASE に関連付ける必要があります。ここでも架空の Contoso Corporation の例で考えると、ASE の既定の DNS サフィックスが internal.contoso.com である場合、https://some-random-app.internal.contoso.com への接続には *.internal.contoso.com に対して有効な TLS/SSL 証明書が必要です。

有効な TLS/SSL 証明書を取得するには、内部 CA を利用する、外部の発行元から証明書を購入する、自己署名証明書を使用するなど、さまざまな方法があります。どのようなソースから TLS/SSL 証明書を取得した場合でも、以下の証明書属性を適切に構成する必要があります。

Subject: この属性は、*.your-root-domain-here.com に設定する必要があります
サブジェクトの別名: この属性には、.<ルートドメイン>.com と *.scm.<ルートドメイン>.com* の両方が含まれている必要があります。 2 つ目のエントリが必要な理由は、各アプリに関連付けられた SCM/Kudu サイトへの TLS 接続が、your-app-name.scm.your-root-domain-here.com 形式のアドレスを使用して確立されるためです。

有効な TLS/SSL 証明書を取得した後、さらに 2 つの準備手順を実行する必要があります。 TLS/SSL 証明書は、.pfx ファイルに変換して保存する必要があります。 .pfx ファイルには、中間証明書とルート証明書をすべて含める必要があり、さらにパスワードで保護する必要もあるという点に注意してください。

その後、.pfx ファイルは base64 文字列に変換する必要がありますが、これは TLS/SSL 証明書が Azure Resource Manager テンプレートを使用してアップロードされるためです。 Azure Resource Manager テンプレートはテキストファイルであるため、パラメーターとしてテンプレートに含めることができるように、.pfx ファイルを base64 文字列に変換する必要があります。

以下の PowerShell コードスニペットは、自己署名証明書を生成して、その証明書を .pfx ファイルとしてエクスポートし、.pfx ファイルを base64 でエンコードされた文字列に変換してから、それを別のファイルに保存する例を示しています。 base64 エンコード用の PowerShell コードは、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:構成対象の ILB ASE の名前。
existingAseLocation:ILB ASE のデプロイ先の Azure リージョンを含むテキスト文字列。次に例を示します。"South Central US"。
pfxBlobString: based64 でエンコードされた .pfx ファイルの文字列表現。前述したコードスニペットを使用すると、"exportedcert.pfx.b64" 内に含まれる文字列をコピーし、 pfxBlobString 属性の値として貼り付けることになります。
password:pfx ファイルの保護に使用されるパスワード。
certificateThumbprint:証明書のサムプリント。この値 (前述のコードスニペットにある $certThumbprint など) を PowerShell から取得した場合、値はそのまま使用できます。ただし、この値を Windows 証明書のダイアログからコピーした場合は、忘れずに余分なスペースを削除してください。 certificateThumbprint は、AF3143EB61D43F6727842115BB7F17BBCECAECAE のようになります。
certificateName:証明書の識別に使用される、独自に選択したわかりやすい文字列識別子。この名前は、TLS/SSL 証明書を表す Microsoft.Web/certificates エンティティに固有の Azure Resource Manager 識別子の一部として使用されます。この名前は、サフィックス _yourASENameHere_InternalLoadBalancingASE で終わる必要があります。このサフィックスは、ILB が有効な ASE を保護するためにこの証明書が使用されることを示すインジケーターとして、ポータルによって使用されます。

一部省略した 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 ファイルへの入力が完了したら、以下の PowerShell コードスニペットを使用して既定の TLS/SSL 証明書を構成することができます。ファイルパスは、マシン上の 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 分かかります。たとえば、2 つのフロントエンドを使用する既定サイズの ASE では、テンプレートが完了するまでに約 1 時間 20 分かかります。テンプレートの実行中に、ASE をスケーリングすることはできません。

テンプレートが完了すると、ILB ASE 上のアプリに HTTPS 経由でアクセスできるようになり、接続は既定の TLS/SSL 証明書を使用して保護されます。既定の TLS/SSL 証明書は、ILB ASE 上のアプリが、アプリケーション名と既定のホスト名の組み合わせを使用してアドレス指定された場合に使用されます。たとえば、https://mycustomapp.internal.contoso.com の場合、*.internal.contoso.com の既定の TLS/SSL 証明書が使用されます。

ただし、パブリックマルチテナントサービスで実行されているアプリと同様に、開発者が個々のアプリに対してカスタムホスト名を設定し、各アプリに固有の SNI TLS/SSL 証明書バインドを構成することもできます。

作業の開始

App Service Environment の使用を開始するには、「App Service Environment の概要

Note

Azure アカウントにサインアップする前に Azure App Service の使用を開始したい場合は、「Azure App Service アプリケーションの作成」を参照してください。そこでは、App Service で有効期間の短いスターター Web アプリをすぐに作成できます。このサービスの利用にあたり、クレジットカードは必要ありません。契約も必要ありません。

次の方法で共有

Azure Resource Manager テンプレートを使用して ILB ASEv1 を作成する方法

概要

ベース ILB ASE の作成

"既定の" TLS/SSL 証明書のアップロードと構成

作業の開始

フィードバック

その他のリソース