次の方法で共有

Azure Resource Manager テンプレートを使用して ASE を作成する

  • [アーティクル]

概要

重要

この記事は、Isolated App Service プランで使用される App Service Environment v2 に関するものです。 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 の提供終了に関する更新情報の記事を参照してください。

Azure App Service Environment (ASE) は、インターネットにアクセス可能なエンドポイントまたは Azure Virtual Network 内の内部アドレスのエンドポイントを使用して作成できます。 内部エンドポイントを使用して作成すると、内部ロード バランサー (ILB) と呼ばれる Azure コンポーネントによってそのエンドポイントが提供されます。 内部 IP アドレスの ASE は、ILB ASE と呼ばれます。 パブリック エンドポイントを持つ ASE は、外部 ASE と呼ばれます。

ASE は、Azure Portal または Azure Resource Manager テンプレートを使用して作成できます。 この記事では、Resource Manager テンプレートを使用して外部 ASE または ILB ASE を作成するために必要な手順と構文について説明します。 Azure portal で ASEv2 を作成する方法については、「[外部 ASE の作成][MakeExternalASE]」、または「ILB ASE の作成」を参照してください。

Azure portal で ASE を作成する場合は、同時に仮想ネットワークを作成するか、またはデプロイする既存の仮想ネットワークを選択できます。

テンプレートから ASE を作成するときは、以下が必要です。

  • Azure Virtual Network。
  • その仮想ネットワーク内のサブネット。 推奨される ASE のサブネット サイズは、将来的な規模の拡大およびスケーリングのニーズに対応できる、256 のアドレスを持つ /24 です。 ASE を作成した後は、サイズ変更はできません。
  • デプロイ先のサブスクリプション。
  • デプロイ先の場所。

ASE の作成を自動化するには、下のセクションのガイドラインに従います。 カスタム dnsSuffix (例: internal.contoso.com) を使用して ILB ASEv2 を作成する場合は、さらにいくつかの操作を行います。

  1. カスタム dnsSuffix を使用する ILB ASE を作成した後、ILB ASE ドメインに一致する TLS/SSL 証明書をアップロードする必要があります。

  2. アップロードされた TLS/SSL 証明書は、"既定の" TLS/SSL 証明書として ILB ASE に割り当てられます。 この証明書は、ILB ASE 上のアプリが ASE に割り当てられた共通ルート ドメイン (https://someapp.internal.contoso.com など) を使用する場合に、そのアプリへの TLS/SSL トラフィックに使用されます。

ASE を作成する

ASE とそれに関連するパラメーター ファイルを作成する Resource Manager テンプレートは、GitHub で入手できます (ASEv2 用)。

ASE を作成する場合は、この Resource Manager テンプレートの ASEv2 の例を使用します。 azuredeploy.parameters.json ファイルのほとんどのパラメーターは、ILB ASE と外部 ASE の作成に共通するパラメーターです。 以下の一覧では、既存のサブネットを使用して ILB ASE を作成する場合に特に注意が必要なパラメーターや、固有のパラメーターについて説明します。

パラメーター

  • aseName: このパラメーターでは、一意の ASE 名を定義します。
  • location: このパラメーターでは、App Service Environment の場所を定義します。
  • existingVirtualNetworkName: このパラメーターでは、ASE を配置する既存の仮想ネットワークとサブネットの仮想ネットワーク名を定義します。
  • existingVirtualNetworkResourceGroup: このパラメーターでは、ASE を配置する既存の仮想ネットワークとサブネットのリソース グループ名を定義します。
  • subnetName: このパラメーターでは、ASE を配置する既存の仮想ネットワークとサブネットのサブネット名を定義します。
  • internalLoadBalancingMode:ほとんどの場合、これは 3 に設定します。この設定により、ポート 80/443 の HTTP/HTTPS トラフィックと、ASE 上の FTP サービスによってリッスンされているコントロール/データ チャネル ポートは、ILB が割り当てられた仮想ネットワークの内部アドレスにバインドされます。 このプロパティを 2 に設定すると、FTP サービスに関連するポート (コントロール チャネルとデータ チャネルの両方) のみが ILB アドレスにバインドされます。 このプロパティを 0 に設定すると、HTTP/HTTPS トラフィックでは、パブリック VIP が引き続き使用されます。
  • dnsSuffix:このパラメーターでは、ASE に割り当てられる既定のルート ドメインを定義します。 Azure App Service のパブリック版では、すべての Web アプリの既定のルート ドメインは azurewebsites.netです。 ILB ASE はユーザーの仮想ネットワークの内部にあるため、パブリック サービスの既定のルート ドメインを使用しても意味がありません。 ILB ASE には、会社の内部仮想ネットワーク内での使用に適した既定のルート ドメインを用意する必要があります。 たとえば、Contoso Corporation では、Contoso の仮想ネットワーク内でのみ解決およびアクセス可能になるよう設計されたアプリに対して、internal-contoso.com という既定のルート ドメインを使用できます。 カスタム ルート ドメインを指定するには、API バージョン 2018-11-01 以前のバージョンを使用する必要があります。
  • ipSslAddressCount:ILB ASE には単一の ILB アドレスしかないため、このパラメーターは、azuredeploy.json ファイル内で自動的に既定値の 0 に設定されます。 ILB ASE 向けの明示的な IP SSL アドレスはありません。 そのため、ILB ASE の IP SSL アドレス プールは、0 に設定する必要があります。 それ以外の場合、プロビジョニングのエラーが発生します。

azuredeploy.parameters.json ファイルに入力した後で、PowerShell コード スニペットを使用して、ASE を作成します。 ファイル パスは、コンピューター上の 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 の作成には 2 時間ほどかかります。 続いて、ポータルの、デプロイをトリガーしたサブスクリプションの ASE の一覧に、作成した ASE が表示されます。

"既定の" TLS/SSL 証明書をアップロードして構成する

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

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

  • Subject:この属性は、* .your-root-domain-here.com に設定する必要があります。
  • Subject Alternative Name: この属性には、*.your-root-domain-here.com と *.scm.your-root-domain-here.com* の両方が含まれている必要があります。 各アプリに関連付けられた SCM/Kudu サイトへの TLS 接続で、your-app-name.scm.your-root-domain-here.com 形式のアドレスが使用されます。

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

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

以下の PowerShell コード スニペットを使用して、次のことを行います。

  • 自己署名証明書を作成します。
  • .pfx ファイルとして証明書をエクスポートします。
  • .pfx ファイルを base64 でエンコードされた文字列に変換します。
  • 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 でエンコードされた文字列に変換されたら、GitHub にある、既定の SSL 証明書を構成するための 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:証明書のサムプリント。 この値 (前述のコード スニペットにある $certificate.Thumbprint など) を PowerShell から取得した場合、値はそのまま使用できます。 この値を Windows 証明書のダイアログ ボックスからコピーした場合は、忘れずに余分なスペースを削除してください。 certificateThumbprint は、AF3143EB61D43F6727842115BB7F17BBCECAECAE のようになります。
  • certificateName:証明書の識別に使用される、独自に選択したわかりやすい文字列識別子。 この名前は、TLS/SSL 証明書を表す Microsoft.Web/certificates エンティティで、一意の Resource Manager 識別子の一部として使用されます。 この名前は、サフィックス _yourASENameHere_InternalLoadBalancingASE で終わる "必要があります"。 このサフィックスは、ILB が有効な ASE を保護するためにこの証明書が使用されることを示す標識として、Azure Portal で使用されます。

一部省略した 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 証明書を構成します。 ファイル パスは、コンピューター上の 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 分かかります。 たとえば、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 証明書バインドを構成することもできます。