Azure App Service でステージング環境を設定する
実行している App Service プランのサービス レベルが Standard、Premium、または Isolated である場合は、Web アプリ、Linux 上の Web アプリ、モバイル バック エンド、または API アプリを Azure App Service にデプロイするときに、既定の運用スロットではなく別個のデプロイ スロットを使用できます。 デプロイ スロットは、固有のホスト名を持つライブ アプリです。 アプリのコンテンツと構成の要素は、運用スロットを含む 2 つのデプロイ スロットの間でスワップすることができます。
非運用スロットにアプリケーションをデプロイすることには、次のメリットがあります:
- ステージング デプロイ スロットでアプリの変更を検証してから、運用スロットにスワップできます。
- スロットにアプリをデプロイした後に運用サイトにスワップすると、運用サイトへのスワップ前にスロットのすべてのインスタンスが準備されます。 これにより、アプリをデプロイする際のダウンタイムがなくなります。 トラフィックのリダイレクトはシームレスであるため、スワップ操作によって破棄される要求はありません。 スワップ前の検証が必要ない場合は、自動スワップを構成することで、このワークフロー全体を自動化できます。
- スワップ後も、以前のステージング アプリ スロットに元の運用アプリが残っているため、 運用スロットにスワップした変更が、ユーザーの想定どおりでない場合は、同じスワップを実行して、適切な動作が確認されている元のサイトにすぐに戻すことができます。
サポートされるデプロイ スロット数は、App Service プラン レベルごとに異なります。 デプロイ スロットは追加料金なしでご利用いただけます。 使用しているアプリのサービス レベルでサポートされるスロット数を確認するには、「App Service の制限」をご覧ください。
アプリを別のサービス レベルにスケールするには、アプリが既に使用しているスロット数がターゲット レベルによってサポートされていることを確認します。 たとえば、Standard レベルではサポートされるデプロイ スロット数は 5 つのみなので、アプリのスロット数が 5 つより多い場合は、Standard レベルにスケール ダウンできません。
このビデオでは、Azure アプリ サービスでステージング環境を設定する方法について説明します。
ビデオの手順については、次のセクションでも説明します。
前提条件
必要なスロット操作 (スロットの検索など) を実行するために必要なアクセス許可については、「リソース プロバイダーの操作」を参照してください。
スロットを追加する
複数のデプロイ スロットを有効にするには、アプリが Standard、Premium、Isolated のいずれかのレベルで実行されている必要があります。
Azure portal で、アプリの管理ページに移動します。
左側のウィンドウで、 [デプロイ スロット]>[スロットの追加] と選択します。
Note
操作を続行する前に、アプリがまだ Standard、 Premium、または Isolated レベルにない場合は、[アップグレード] を選択し、アプリの [スケール] タブに移動します。
[スロットの追加] ダイアログ ボックスで、スロット名を指定し、別のデプロイ スロットからアプリ構成を複製するかどうかを選択します。 [追加] を選択して続行します。
構成は、既存のどのスロットからも複製できます。 複製できる設定には、アプリの設定、接続文字列、言語フレームワークのバージョン、Web ソケット、HTTP のバージョン、プラットフォームのビット数などがあります。
注意
現時点では、プライベート エンドポイントはスロット間でクローンされません。
スロットを追加した後、 [閉じる] を選択してダイアログ ボックスを閉じます。 これで新しいスロットが [デプロイ スロット] ページに表示されます。 既定では、新しいスロットの [トラフィック %] は 0 に設定され、顧客のトラフィックはすべて運用スロットにルーティングされます。
新しいデプロイ スロットを選択して、そのスロットのリソース ページを開きます。
ステージング スロットには、他の App Service アプリと同様に管理ページがあります。 スロットの構成を変更することができます。 デプロイ スロットを表示していることを知らせるため、アプリ名は <app-name>/<slot-name> と表示され、アプリの種類は App Service (スロット) です。 また、同じ指定先を使用して、リソース グループ内の別のアプリとしてスロットを表示することもできます。
スロットのリソース ページで、アプリの URL を選択します。 デプロイ スロットは独自のホスト名を持ち、ライブ アプリでもあります。 デプロイ スロットへのパブリック アクセスを制限するには、Azure App Service の IP 制限に関するページをご覧ください。
別のスロットから設定を複製した場合でも、新しいデプロイ スロットには内容がありません。 たとえば、Git を使用してこのスロットに発行することができます。 スロットには、異なるリポジトリブランチ、または異なるリポジトリからデプロイできます。 Azure App Service から発行プロファイルを取得すると、このスロットにデプロイするのに必要な情報を用意できます。 このプロファイルを Visual Studio でインポートすると、内容をスロットにデプロイできます。
スロットの URL の形式は http://sitename-slotname.azurewebsites.net です。 URL の長さを必要な DNS 制限内に維持するために、サイト名は 40 文字で切り捨てられ、サイト名とスロット名を合わせて 59 文字未満にする必要があります。
スワップ中の動作
スワップ操作の手順
2 つのスロット (通常はソースとしてステージング スロットからターゲットとして運用スロットに入れる) をスワップすると、App Service は、ターゲット スロットにダウンタイムが発生しないように、次の処理を行います。
ターゲット スロット (たとえば運用スロット) からソース スロットのすべてのインスタンスに対して、以下の設定を適用します。
- スロット固有のアプリ設定と接続文字列 (該当する場合)。
- 継続的デプロイの設定 (有効になっている場合)。
- App Service の認証の設定 (有効になっている場合)。
これらのどの場合も、ソース スロット内のすべてのインスタンスがトリガーされます。 スワップ中のプレビューは、最初のフェーズが終了したことを示します。 スワップ操作が一時停止しても、ターゲット スロットの設定によってソース スロットが正しく動作していることを検証できます。
ソース スロット内のすべてのインスタンスが再起動を完了するまで待機します。 いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。
ローカル キャッシュが有効になっている場合は、ソース スロットの各インスタンスのアプリケーション ルート ("/") に対して HTTP 要求を行うことで、ローカル キャッシュの初期化をトリガーします。 各インスタンスが何らかの HTTP 応答を返すまで待機します。 ローカル キャッシュの初期化により、各インスタンスでもう一度再起動が発生します。
カスタム ウォームアップによって自動スワップが有効になっている場合は、ソース スロットの各インスタンスのアプリケーション ルート ("/") に対して HTTP 要求を行うことで、アプリケーションの初期化をトリガーします。
applicationInitializationが指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。
ソース スロットのすべてのインスタンスが正常にウォームアップされたら、2 つのスロットのルーティング規則を入れ換えることで 2 つのスロットをスワップします。 この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。
この時点でソース スロットが保有するスワップ前のアプリは、以前ターゲット スロットに存在しており、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。
スワップ操作のどの時点でも、スワップされるアプリを初期化するすべての作業はソース スロットで発生しています。 スワップが成功または失敗した場所に関わらず、ソース スロットが準備され、ウォームアップされる間は、ターゲット スロットがオンライン状態に留まります。 ステージング スロットと運用スロットをスワップする場合は、常に運用スロットがターゲット スロットであることを確認してください。 こうすることで、スワップ操作が運用アプリに影響を及ぼしません。
Note
以前の運用インスタンス (このスワップ操作の後でステージングにスワップされるもの) は、スワップ プロセスの最後のステップですぐにリサイクルされます。 アプリケーションに実行時間の長い操作がある場合は、ワーカーがリサイクルされるときに破棄されます。 これは関数アプリにも適用されます。 そのため、アプリケーションのコードはフォールト トレラントな方法で記述する必要があります。
スワップされる設定
別のデプロイ スロットから構成を複製する場合、複製された構成を編集することができます。 構成要素には、スワップを経ても内容が反映される (スロット固有でない) ものもあれば、スワップ後に同じスロットに残されている (スロット固有の) ものもあります。 次の一覧では、スロットのスワップ時に変更される設定を示します。
スワップされる設定:
- 一般設定 (フレームワーク バージョン、32/64 ビット、Web ソケットなど)
- アプリ設定 (スロット固有として構成可能)
- 接続文字列 (スロット固有として構成可能)
- ハンドラー マッピング
- パブリック証明書
- Web ジョブ コンテンツ
- ハイブリッド接続 *
- サービス エンドポイント *
- Azure Content Delivery Network *
- パスのマッピング
アスタリスク (*) 記号付きの機能は、スワップされない予定です。
スワップされない設定:
- 発行エンドポイント
- カスタム ドメイン名
- パブリックでない証明書と TLS/SSL 設定
- スケールの設定
- Web ジョブ スケジューラ
- IP 制限
- 常時接続
- 診断設定
- クロスオリジン リソース共有 (CORS)
- 仮想ネットワークの統合
- マネージド ID と関連する設定
- サフィックス _EXTENSION_VERSION で終わる設定
- サービス コネクタによって作成された設定
Note
前述の設定をスワップ可能にするには、アプリのすべてのスロットでアプリ設定 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS を追加し、その値を 0 または false に設定します。 これらの設定は、すべてがスワップ可能か、まったくスワップ可能でないかのどちらかです。 一部の設定だけをスワップ可能にして、他を不可にすることはできません。 マネージド ID はスワップされないため、このオーバーライド アプリ設定による影響を受けません。
スワップされていない設定に適用されている特定のアプリ設定もスワップされません。 たとえば、診断の設定はスワップされないため、WEBSITE_HTTPLOGGING_RETENTION_DAYS や DIAGNOSTICS_AZUREBLOBRETENTIONDAYS などの関連するアプリ設定もスワップされません。これは、スロット設定として表示されない場合でも同様です。
特定のスロットに固有の (スワップされない) アプリ設定や接続文字列を構成するには、そのスロットの [構成] ページに移動します。 設定を追加または編集し、 [deployment slot setting](スロット設定のデプロイ) を選択します。 このチェック ボックスを選択し、設定がスワップ可能ではないことを App Service に指示します。
2 つのスロットをスワップする
アプリの [デプロイ スロット] ページと [概要] ページで、デプロイ スロットをスワップできます。 スロットのスワップに関する技術的詳細については、「スワップ中の動作」を参照してください。
重要
アプリをデプロイ スロットから運用環境にスワップする前に、運用環境がターゲット スロットになっていること、およびソース スロットのすべての設定が、運用環境に反映させたい内容で正確に構成されていることを確認してください。
デプロイ スロットをスワップするには:
アプリの [デプロイ スロット] ページに移動し、 [スワップ] を選択します。
[スワップ] ダイアログ ボックスに、選択したソース スロットとターゲット スロットの変更される設定が表示されます。
目的の [ソース] および [ターゲット] スロットを選択します。 通常、ターゲットは運用スロットになります。 また、 [ソースの変更] タブと [ターゲットの変更] タブを選択して、構成の変更が予定されていることを確認します。 完了したら、 [スワップ] を選択することで直ちにスロットをスワップできます。
スワップを実際に行う前に、新しい設定でのターゲット スロットの動作を確認するには、 [スワップ] を選択しないで、「プレビューでのスワップ」の指示に従います。
完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。
問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。
プレビューでのスワップ (複数フェーズのスワップ)
ターゲット スロットとしての運用環境にスワップする前に、スワップ後の設定でアプリの実行を検証します。 ソース スロットは、スワップの完了前にウォームアップもされているため、ミッション クリティカルなアプリケーションに適しています。
プレビューでのスワップを実行すると、App Service は同じスワップ操作を実行しますが、最初の手順の後に、一時停止します。 その後、スワップを完了する前にステージング スロットでの結果を検証できます。
スワップをキャンセルすると、構成要素がソース スロットに再適用されます。
Note
スロットのいずれかでサイト認証が有効になっている場合、プレビューでのスワップは使用できません。
プレビューでのスワップを行うには:
「デプロイ スロットをスワップする」の手順に従いますが、 [プレビューでスワップを実行] を選択します。
ダイアログ ボックスに、フェーズ 1 でソース スロットの構成がどのように変わり、フェーズ 2 でソース スロットとターゲット スロットがどのように変わるかが表示されます。
スワップを開始する準備ができたら、 [スワップの開始] を選択します。
フェーズ 1 が終了すると、ダイアログ ボックスで通知されます。
https://<app_name>-<source-slot-name>.azurewebsites.netに移動して、ソース スロットでのスワップをプレビューします。保留中のスワップを完了する準備ができたら、 [スワップ アクション] で [スワップの完了] を選択し、 [スワップの完了] を選択します。
保留中のスワップを取り消す場合は、代わりに [スワップのキャンセル] を選択した後、下部で [スワップをキャンセル] を選択します。
完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。
問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。
スワップをロールバックする
スロットのスワップ後にターゲット スロット (運用スロットなど) でエラーが発生する場合は、同じ 2 つのスロットをすぐにスワップして、スロットをスワップ前の状態に復元します。
自動スワップを構成する
Note
自動スワップは、Linux および Web App for Containers の Web アプリではサポートされていません。
自動スワップを使うと、アプリのユーザーにコールド スタートを課したりダウンタイムを生じさせたりすることなく、アプリを連続的にデプロイする効率的な Azure DevOps シナリオを実現できます。 あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、アプリが運用環境にスワップされます。
Note
運用スロットに対する自動スワップを構成する前に、非運用環境のターゲット スロットでの自動スワップのテストも考慮してください。
自動スワップを構成するには:
アプリのリソース ページに移動します。 [デプロイ スロット]>[<目的のソース スロット>]>[構成]>[全般設定] の順に選択します。
[Auto swap enabled](自動スワップ有効化) で、 [オン] を選択します。 [Auto swap deployment slot](自動スワップのデプロイ スロット) で目的のターゲット スロットを選択し、コマンド バーで [保存] を選択します。
ソース スロットへのコードのプッシュを実行します。 しばらくすると自動スワップが実行され、更新がターゲット スロットの URL に反映されます。
問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。
カスタム ウォームアップを指定する
一部のアプリでは、スワップ前のカスタム ウォームアップ アクションが必要な場合があります。 web.config の applicationInitialization 構成要素を使用して、カスタム初期化アクションを指定できます。 スワップ操作では、このカスタム ウォームアップの終了を待ってから、ターゲット スロットとのスワップが行われます。 以下に、サンプルの web.config フラグメントを示します。
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
applicationInitialization 要素のカスタマイズの詳細については、「Most common deployment slot swap failures and how to fix them (最も一般的なデプロイ スロットのスワップ エラーとその修正方法)」を参照してください。
次のアプリ設定の 1 つまたは両方を使用して、ウォームアップの動作をカスタマイズすることもできます。
WEBSITE_SWAP_WARMUP_PING_PATH: サイトをウォームアップするための、HTTP 経由での ping へのパス。 このアプリ設定を追加するには、値としてスラッシュで始まるカスタム パスを指定します。 たとえば/statuscheckです。 既定値は/です。WEBSITE_SWAP_WARMUP_PING_STATUSES: ウォーム アップ操作の有効な HTTP 応答コード。 HTTP コードのコンマ区切りの一覧で、このアプリ設定を追加します。 たとえば200,202とします。 返された状態コードが一覧にない場合、ウォームアップとスワップの操作が停止されます。 既定で、すべての応答コードは有効です。WEBSITE_WARMUP_PATH: (スロット スワップ中だけでなく) サイトが再起動されるたびに ping を実行する必要があるサイトの相対パス。 サンプル値には、/statuscheckまたはルート パス、/が含まれます。
Note
<applicationInitialization> 構成要素は各アプリの起動に含まれますが、2 つのウォームアップの動作を行うアプリの設定はスロット スワップにのみ適用されます。
問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。
スワップを監視する
スワップ操作が完了するまで長い時間がかかる場合、アクティビティ ログでスワップ操作に関する情報を取得できます。
ポータルのアプリのリソース ページで、左側のウィンドウの [アクティビティ ログ] を選択します。
スワップ操作がログ クエリに Swap Web App Slots として表示されます。 これを展開し、副操作やエラーの 1 つを選択して詳細を表示できます。
運用トラフィックを自動的にルーティングする
既定では、アプリの運用環境の URL (http://<app_name>.azurewebsites.net) に対するすべてのクライアント要求は、運用スロットにルーティングされます。 トラフィックの一部を、別のスロットにルーティングできます。 この機能は、新しい更新についてのユーザーのフィードバックが必要であっても、運用環境にリリースできる状態ではない場合に便利です。
運用トラフィックを自動的にルーティングするには、以下の手順に従います。
アプリのリソース ページに移動し、 [デプロイ スロット] を選択します。
ルーティング先のスロットの [トラフィック %] 列で、ルーティングするトラフィックの合計量を表す割合 (0 ～ 100) を指定します。 [保存] を選択します。
設定の保存後は、指定した割合のクライアントが、非運用スロットにランダムにルーティングされます。
クライアントが特定のスロットに自動的にルーティングされると、そのスロットに 1 時間、または Cookie が削除されるまで "ピン留め" されます。 クライアントのブラウザーで、HTTP ヘッダー内の x-ms-routing-name Cookie を調べることにより、セッションが固定されているスロットを確認できます。 "ステージング" スロットにルーティングされる要求には、x-ms-routing-name=staging という Cookie が設定されています。 運用スロットにルーティングされる要求には、x-ms-routing-name=self という Cookie が設定されています。
運用トラフィックを手動でルーティングする
App Service では、トラフィックの自動ルーティングだけでなく、特定のスロットに要求をルーティングすることもできます。 この方法は、ユーザーがベータ版アプリの利用を選択または拒否できるようにしたい場合に便利です。 運用トラフィックを手動でルーティングするには、x-ms-routing-name クエリ パラメーターを使用します。
ユーザーがベータ版アプリの利用をオプトアウトできるようにするには、たとえば次のようなリンクをご利用の Web ページに配置します。
<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>
文字列 x-ms-routing-name=self に指定されているのは運用スロットです。 クライアント ブラウザーは、リンクにアクセスすると、運用スロットにリダイレクトされます。 以降のすべての要求には、セッションをその運用スロットに固定する x-ms-routing-name=self cookie が含まれます。
ベータ版アプリの利用をユーザーがオプトインできるようにするには、同じクエリ パラメーターを、非運用スロットの名前に対し設定します。 次に例を示します。
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
既定では、新しいスロットには、0% のルーティング規則がグレーで表示されます。 この値を明示的に 0% に設定すると (黒のテキストで表示されます)、ユーザーは x-ms-routing-name クエリ パラメーターを使用して、ステージング スロットに手動でアクセスできます。 しかし、ルーティングの割合は 0 に設定されているため、ユーザーはスロットに自動的にルーティングされません。 これは、内部チームにスロットでの変更のテストを許可する一方で、ステージング スロットをパブリックから "非表示" にできる高度なシナリオです。
スロットを削除する
アプリを検索して選択します。 [デプロイ スロット]><[削除するスロット]>>[概要] の順に選択します。 アプリの種類は App Service (スロット) として表示され、デプロイ スロットが表示されていることを知らせます。 スロットを削除する前に、必ずスロットを停止し、スロット内のトラフィックを 0 に設定してください。 コマンド バーの [削除] を選択します。
Resource Manager テンプレートで自動化する
Azure Resource Manager テンプレートは、Azure リソースのデプロイと構成を自動化するために使用される宣言型の JSON ファイルです。 Resource Manager テンプレートを使用してスロットをスワップするには、2 つのプロパティを、Microsoft.Web/sites/slots と Microsoft.Web/sites リソースで設定します:
buildVersion: これは、スロットにデプロイされているアプリの現在のバージョンを表す文字列プロパティです。 たとえば、"v1"、"1.0.0.1"、または "2019-09-20T11:53:25.2887393-07:00" のようになります。targetBuildVersion: これは、スロットに必要なbuildVersionを指定する文字列プロパティです。targetBuildVersionが現在のbuildVersionに等しくない場合、指定されたbuildVersionを持つスロットが検索され、スワップ 操作がトリガーされます。
Resource Manager テンプレートの例
次の Resource Manager テンプレートは、staging スロットの buildVersion を更新し、運用スロットに targetBuildVersion を設定することで、2 つのスロットをスワップします。 このテンプレートでは、staging というスロットが作成済みであることを前提としています。
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"my_site_name": {
"defaultValue": "SwapAPIDemo",
"type": "String"
},
"sites_buildVersion": {
"defaultValue": "v1",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Web/sites/slots",
"apiVersion": "2018-02-01",
"name": "[concat(parameters('my_site_name'), '/staging')]",
"location": "East US",
"kind": "app",
"properties": {
"buildVersion": "[parameters('sites_buildVersion')]"
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2018-02-01",
"name": "[parameters('my_site_name')]",
"location": "East US",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
],
"properties": {
"targetBuildVersion": "[parameters('sites_buildVersion')]"
}
}
]
}
この Resource Manager テンプレートはべき等です。つまり、繰り返し実行して、スロットの同じ状態を生成することができます。 テンプレートの変更をせずに、同じテンプレートで引き続き実行しても、スロットが既に目的の状態となっているため、スロットのスワップはトリガーされません。
スワップのトラブルシューティングを行う
スロットのスワップ中に何らかのエラーが発生した場合、そのエラーは D:\home\LogFiles\eventlog.xml にログ記録されます。 アプリケーション固有のエラー ログにも記録されます。
以下に、スワップの一般的なエラーをいくつか示します。
アプリケーション ルートへの HTTP 要求には時間枠が設けられています。 スワップ操作は、HTTP 要求ごとに 90 秒間待機してからの再試行を、最大 5 回実行します。 すべての再試行がタイムアウトになると、スワップ操作は停止されます。
アプリのコンテンツがローカル キャッシュ用に指定されたローカル ディスクのクォータを超過すると、ローカル キャッシュの初期化が失敗することがあります。 詳細については、ローカル キャッシュの概要に関するページを参照してください。
カスタム ウォームアップ時には、HTTP 要求は (外部 URL を経由することなく) 内部的に作成されます。 Web.config 内に特定の URL 書き換えルールがあると、それらが失敗する可能性があります。たとえば、ドメイン名をリダイレクトするルールや HTTPS を適用するルールは、ウォームアップ要求がアプリ コードに到達するのを妨げることがあります。 この問題を回避するには、以下のように 2 つの条件を追加して、書き換えルールを変更します。
<conditions> <add input="{WARMUP_REQUEST}" pattern="1" negate="true" /> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>カスタム ウォームアップを行わなくても、URL 書き換えルールが HTTP 要求をブロックする場合があります。 この問題を回避するには、以下のように条件を追加して、書き換えルールを変更します。
<conditions> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>スロットをスワップした後、アプリが予期せず再起動する可能性があります。 これは、スワップ後にホスト名のバインド構成の同期が切れ、単体では再起動を行うことができないためです。 ただし、基盤となる特定のストレージ イベント (記憶域ボリュームのフェールオーバーなど) によってこれらの不一致が検出され、すべてのワーカー プロセスが強制的に再起動される可能性があります。 このような再起動を最小限に抑えるには、すべてのスロットで
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1app settingを設定します。 ただし、このアプリケーション設定は Windows Communication Foundation (WCF) アプリでは動作しません。