次の方法で共有

Azure App Service でステージング環境を設定する

  • [アーティクル]

Note

2024 年 6 月 1 日以降に新しく作成される App Service アプリでは、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用する一意の既定のホスト名を生成できます。 既存のアプリ名は変更されません。 次に例を示します。

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳しくは、App Service リソースの一意の既定のホスト名に関するページをご覧ください。

Web アプリ、Linux 上の Web アプリ、モバイル バック エンド、または API アプリを Azure App Service にデプロイする場合は、既定の運用スロットではなく、別のデプロイ スロットを使用できます。 この方法は、Standard、Premium、または Isolated App Service プラン レベルで実行する場合に使用できます。 デプロイ スロットは、固有のホスト名を持つライブ アプリです。 アプリのコンテンツと構成の要素は、運用スロットを含む 2 つのデプロイ スロットの間でスワップすることができます。

非運用スロットにアプリケーションをデプロイすることには、次のメリットがあります:

  • ステージング デプロイ スロットでアプリの変更を検証した後に、運用スロットとスワップできます。
  • 最初にスロットにアプリをデプロイし、運用環境にスワップすることで、運用環境へのスワップ前にスロットのすべてのインスタンスが確実に準備されます。 この方法により、アプリをデプロイするときのダウンタイムがなくなります。 トラフィックのリダイレクトはシームレスです。 スワップ操作であるため、要求は削除されません。 スワップ前の検証が必要ない場合は、自動スワップを構成することで、このワークフロー全体を自動化できます。
  • スワップ後も、以前のステージング アプリ スロットに元の運用アプリが残っているため、 運用スロットにスワップした変更が想定どおりでない場合は、同じスワップを実行して、"適切な動作が確認されている元のサイト" にすぐに戻すことができます。

サポートされるデプロイ スロット数は、App Service プラン レベルごとに異なります。 デプロイ スロットは追加料金なしでご利用いただけます。 使用しているアプリのサービス レベルでサポートされるスロット数を確認するには、「App Service の制限」をご覧ください。

アプリを別のサービス レベルにスケールするには、アプリが既に使用しているスロット数がターゲット レベルによってサポートされていることを確認します。 たとえば、アプリに 5 つを超えるスロットがある場合、Standard レベルにスケールダウンすることはできません。 Standard レベルでは、5 つのデプロイ スロットのみがサポートされます。

このビデオでは、Azure App Service でステージング環境を設定する方法が説明されています。

ビデオの手順については、次のセクションでも説明します。

前提条件

  • 必要なスロット操作を実行するために必要なアクセス許可については、「リソース プロバイダーの操作」を参照してください。 たとえば、"スロット" を検索します。

スロットを追加する

複数のデプロイ スロットを有効にするには、アプリが Standard、Premium、Isolated のいずれかのレベルで実行されている必要があります。

  1. Azure portal で、アプリの管理ページに移動します。

  2. 左側のウィンドウで、[デプロイ]>[デプロイ スロット]>[追加] の順に選択します。

    Note

    アプリがまだ Standard、Premium、または Isolated レベルにない場合は、[アップグレード] を選択します。 続行する前に、アプリの [スケール] タブに移動します。

  3. [スロットの追加] ダイアログ ボックスで、スロット名を指定し、別のデプロイ スロットからアプリ構成を複製するかどうかを選択します。 [追加] を選択して続行します。

    ポータルで

    構成は、既存のどのスロットからも複製できます。 複製できる設定には、アプリの設定、接続文字列、言語フレームワークのバージョン、Web ソケット、HTTP のバージョン、プラットフォームのビット数などがあります。

    注意

    現時点では、プライベート エンドポイントはスロット間でクローンされません。

  4. 設定を入力した後、[閉じる] を選択してダイアログ ボックスを閉じます。 これで新しいスロットが [デプロイ スロット] ページに表示されます。 既定では、新しいスロットの [トラフィック %] は 0 に設定され、顧客のトラフィックはすべて運用スロットにルーティングされます。

  5. 新しいデプロイ スロットを選択して、そのスロットのリソース ページを開きます。

    ポータルにデプロイ スロットの管理ページを開く方法を示しているスクリーンショット。

    ステージング スロットには、他の App Service アプリと同様に管理ページがあります。 スロットの構成を変更することができます。 デプロイ スロットを表示していることを知らせるために、アプリ名は <app-name>/<slot-name> と表示されます。 アプリの種類は App Service (スロット) です。 また、同じ指定先を使用して、リソース グループ内の別のアプリとしてスロットを表示することもできます。

  6. スロットのリソース ページで、アプリの URL を選択します。 デプロイ スロットは独自のホスト名を持ち、ライブ アプリでもあります。 デプロイ スロットへのパブリック アクセスを制限するには、Azure App Service の IP 制限に関するページをご覧ください。

別のスロットから設定を複製した場合でも、新しいデプロイ スロットには内容がありません。 たとえば、Git を使用してこのスロットに発行することができます。 スロットには、異なるリポジトリブランチ、または異なるリポジトリからデプロイできます。 Azure App Service から発行プロファイルを取得すると、このスロットにデプロイするのに必要な情報を用意できます。 Visual Studio では、プロファイルをインポートして、コンテンツをスロットにデプロイできます。

スロットの URL の形式は http://sitename-slotname.azurewebsites.net です。 URL の長さを必要な DNS 制限内に維持するために、サイト名は 40 文字で切り捨てられます。 サイト名とスロット名は合わせて 59 文字未満でなければなりません。

スワップ中の動作

スワップ操作の手順

2 つのスロットをスワップすると、ターゲット スロットでダウンタイムが発生しないように、App Service によって次のことが行われます。

  1. ターゲット スロット (たとえば運用スロット) からソース スロットのすべてのインスタンスに対して、以下の設定を適用します。

    いずれかの設定がソース スロットに適用されると、その変更によってソース スロット内のすべてのインスタンスの再起動がトリガーされます。 プレビューでのスワップ時には、このアクションは最初のフェーズが終了したことを示します。 スワップ操作は一時停止されます。 ソース スロットがターゲット スロットの設定で正しく動作することを検証できます。

  2. ソース スロット内のすべてのインスタンスが再起動を完了するまで待機します。 いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。

  3. ローカル キャッシュが有効になっている場合は、ソース スロットの各インスタンスのアプリケーション ルート ("/") に対して HTTP 要求を行うことで、ローカル キャッシュの初期化をトリガーします。 各インスタンスが何らかの HTTP 応答を返すまで待機します。 ローカル キャッシュの初期化により、各インスタンスでもう一度再起動が発生します。

  4. カスタム ウォームアップで自動スワップが有効になっている場合は、ソース スロットの各インスタンスでカスタムのアプリケーションの初期化をトリガーします。

    applicationInitialization が指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。

    インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。

  5. ソース スロットのすべてのインスタンスが正常にウォームアップされたら、2 つのスロットのルーティング規則を入れ換えることで 2 つのスロットをスワップします。 この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。

  6. この時点でソース スロットが保有するスワップ前のアプリは、以前ターゲット スロットに存在しており、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。

スワップ操作のどの時点でも、スワップされるアプリを初期化するすべての作業はソース スロットで発生しています。 ソース スロットが準備され、ウォームアップされている間、スワップがどこで成功するか失敗するかに関わらず、ターゲット スロットはオンライン状態に留まります。 ステージング スロットと運用スロットをスワップする場合は、常に運用スロットがターゲット スロットであることを確認してください。 こうすることで、スワップ操作が運用アプリに影響を及ぼしません。

Note

以前の運用インスタンスは、このスワップ操作の後にステージングにスワップされます。 これらのインスタンスはスワップ プロセスの最後の手順でリサイクルされます。 アプリケーションに実行時間の長い操作がある場合は、ワーカーのリサイクル時に破棄されます。 この事実は関数アプリにも適用されます。 そのため、アプリケーションのコードはフォールト トレラントな方法で記述する必要があります。

スワップされる設定

別のデプロイ スロットから構成を複製する場合、複製された構成を編集することができます。 一部の構成要素では、スワップを経てもコンテンツが反映されます ("スロット固有でない")。 その他の構成要素は、スワップ後も同じスロットに残ります ("スロット固有")。 次の一覧では、スロットのスワップ時に変更される設定を示します。

スワップされる設定:

  • 言語スタックとバージョン、32/64 ビット
  • アプリ設定 (スロット固有として構成可能)
  • 接続文字列 (スロット固有として構成可能)
  • マウントされたストレージ アカウント (スロット固有として構成可能)
  • ハンドラー マッピング
  • パブリック証明書
  • 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 などの関連するアプリ設定もスワップされません。これは、スロット設定として表示されない場合でも同様です。

スワップされない特定のスロットに固有のアプリ設定または接続文字列を構成するには、そのスロットの [設定]>[環境変数] ページに移動します。 設定を追加または編集し、[デプロイ スロットの設定] を選択します。 このオプションを選択すると、設定がスワップできないことが App Service に示されます。

Azure portal でアプリ設定をスロット設定として構成する方法を示しているスクリーンショット。

2 つのスロットをスワップする

アプリの [デプロイ スロット] ページと [概要] ページで、デプロイ スロットをスワップできます。 スロット スワップの詳細については、「スワップ中の動作」を参照してください。

重要

アプリをデプロイ スロットから運用環境にスワップする前に、運用環境がターゲット スロットになっていること、およびソース スロットのすべての設定が、運用環境に反映させたい内容で正確に構成されていることを確認してください。

デプロイ スロットをスワップするには:

  1. アプリの [デプロイ スロット] ページに移動し、 [スワップ] を選択します。

    ポータルでスワップ操作を起動する方法を示しているスクリーンショット。

    [スワップ] ダイアログ ボックスに、選択したソースおよびターゲット スロットの変更される設定が表示されます。

  2. 目的の [ソース] および [ターゲット] スロットを選択します。 通常、ターゲットは運用スロットになります。 また、 [ソースの変更] タブと [ターゲットの変更] タブを選択して、構成の変更が予定されていることを確認します。 完了したら、[スワップ] を選択してスロットをすぐにスワップできます。

    ポータルでスワップを構成し完了する方法を示しているスクリーンショット。

    スワップを実際に行う前に、新しい設定でのターゲット スロットの動作を確認するには、 [スワップ] を選択しないで、「プレビューでのスワップ」の指示に従います。

  3. 完了したら、[閉じる] を選択してダイアログ ボックスを閉じます。

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。

プレビューでのスワップ (複数フェーズのスワップ)

ターゲット スロットとしての運用環境にスワップする前に、スワップ後の設定でアプリの実行を検証します。 ソース スロットは、スワップの完了前にウォームアップもされているため、ミッション クリティカルなアプリケーションに適しています。

プレビューでのスワップを実行すると、App Service は同じスワップ操作を実行しますが、最初の手順の後に、一時停止します。 その後、スワップを完了する前にステージング スロットでの結果を検証できます。

スワップをキャンセルすると、構成要素がソース スロットに再適用されます。

Note

スロットのいずれかでサイト認証が有効になっている場合、プレビューでのスワップは使用できません。

プレビューでのスワップを行うには:

  1. 「デプロイ スロットをスワップする」の手順に従いますが、 [プレビューでスワップを実行] を選択します。

    ダイアログ ボックスに、フェーズ 1 でソース スロットの構成がどのように変わり、フェーズ 2 でソース スロットとターゲット スロットがどのように変わるかが表示されます。

  2. スワップを開始する準備ができたら、 [スワップの開始] を選択します。

    フェーズ 1 が完了すると、ダイアログ ボックスで通知されます。 https://<app_name>-<source-slot-name>.azurewebsites.net に移動して、ソース スロットでのスワップをプレビューします。

  3. 保留中のスワップを完了する準備ができたら、 [スワップ アクション] で [スワップの完了] を選択し、 [スワップの完了] を選択します。

    ポータルでプレビューでのスワップを構成する方法を示しているスクリーンショット。

    保留中のスワップを取り消す場合は、代わりに [スワップのキャンセル] を選択した後、下部で [スワップをキャンセル] を選択します。

  4. 完了したら、[閉じる] を選択してダイアログ ボックスを閉じます。

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。

スワップをロールバックする

スロットのスワップ後にターゲット スロット (運用スロットなど) でエラーが発生する場合は、同じ 2 つのスロットをすぐにスワップして、スロットをスワップ前の状態に復元します。

自動スワップを構成する

Note

自動スワップは、Linux および Web App for Containers の Web アプリではサポートされていません。

自動スワップを使うと、アプリのユーザーにコールド スタートを課したりダウンタイムを生じさせたりすることなく、アプリを連続的にデプロイする効率的な Azure DevOps シナリオを実現できます。 あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、アプリが運用環境にスワップされます。

Note

運用スロットに対する自動スワップを構成する前に、非運用環境のターゲット スロットでの自動スワップのテストも考慮してください。

自動スワップを構成するには:

  1. アプリのリソース ページに移動します。 [デプロイ]>[デプロイ スロット]><目的のソース スロット> を選択します。

  2. 左側のウィンドウで、[設定]>[構成]>[全般設定] を選択します。

  3. [Auto swap enabled](自動スワップ有効化) で、 [オン] を選択します。 [Auto swap deployment slot](自動スワップのデプロイ スロット) で目的のターゲット スロットを選択し、コマンド バーで [保存] を選択します。

    ポータルで運用スロットへの自動スワップを構成する方法を示しているスクリーンショット。

  4. ソース スロットへのコード プッシュを実行します。 しばらくすると自動スワップが行われます。 更新はターゲット スロットの 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 (最も一般的なデプロイ スロットのスワップ エラーとその修正方法)」を参照してください。

次のアプリ設定を使用して、ウォームアップ動作をカスタマイズすることもできます。

  • WEBSITE_SWAP_WARMUP_PING_PATH: サイトをウォームアップするための、HTTP 経由での ping へのパス。 このアプリ設定を追加するには、値としてスラッシュで始まるカスタム パスを指定します。 たとえば /statuscheck です。 既定値は / です。
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: ウォーム アップ操作の有効な HTTP 応答コード。 HTTP コードのコンマ区切りの一覧で、このアプリ設定を追加します。 たとえば 200,202 です。 返された状態コードが一覧にない場合、ウォームアップとスワップの操作が停止されます。 既定で、すべての応答コードは有効です。
  • WEBSITE_WARMUP_PATH: (スロット スワップ中だけでなく) サイトが再起動されるたびに ping を実行する必要があるサイトの相対パス。 サンプル値には、/statuscheck またはルート パス、/ が含まれます。

Note

<applicationInitialization> 構成要素は各アプリの起動に含まれますが、ウォームアップ動作アプリの設定はスロット スワップにのみ適用されます。

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。

スワップを監視する

スワップ操作が完了するまで長い時間がかかる場合、アクティビティ ログでスワップ操作に関する情報を取得できます。

ポータルのアプリのリソース ページで、左側のウィンドウの [アクティビティ ログ] を選択します。

スワップ操作がログ クエリに Swap Web App Slots として表示されます。 これを展開し、副操作やエラーの 1 つを選択して詳細を表示できます。

運用トラフィックを自動的にルーティングする

既定では、アプリの運用環境の URL (http://<app_name>.azurewebsites.net) に対するすべてのクライアント要求は、運用スロットにルーティングされます。 トラフィックの一部を、別のスロットにルーティングできます。 この機能は、新しい更新についてのユーザーのフィードバックが必要であっても、運用環境にリリースできる状態ではない場合に便利です。

運用トラフィックを自動的にルーティングするには、以下の手順に従います。

  1. Web アプリのリソース ページに移動し、[デプロイ スロット] を選択します。

  2. ルーティング先のスロットの [トラフィック %] 列で、ルーティングするトラフィックの合計量を表す割合 (0 ～ 100) を指定します。 [保存] を選択します。

    ポータルでデプロイ スロットに一定割り合いの要求トラフィックをルーティングする方法を示しているスクリーンショット。

設定の保存後は、指定した割合のクライアントが、非運用スロットにランダムにルーティングされます。

クライアントが特定のスロットに自動的にルーティングされた後、そのスロットに 1 時間、または Cookie が削除されるまで "ピン留め" されます。 クライアントのブラウザーで、HTTP ヘッダー内の x-ms-routing-name Cookie を調べることにより、セッションが固定されているスロットを確認できます。 staging スロットにルーティングされる要求には、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 回実行します。 すべての再試行がタイムアウトになると、スワップ操作は停止されます。

  • アプリのコンテンツがローカル キャッシュ用に指定されたローカル ディスクのクォータを超過すると、ローカル キャッシュの初期化が失敗することがあります。 詳細については、ローカル キャッシュの概要に関するページを参照してください。

  • サイトの更新操作中に、"スロットを変更できません。その構成設定は、スワップ用に準備が完了しています" というエラーが発生する可能性があります。 このエラーは、「プレビューでのスワップ (複数フェーズのスワップ)」のフェーズ 1 は終了したが、フェーズ 2 がまだ実行されていない場合に発生する可能性があります。 また、スワップに失敗した場合にも発生する可能性があります。 この問題を解決するには、以下の 2 つの方法があります。

    • スワップ操作を取り消して、サイトを古い状態にリセットする
    • スワップ操作を完了して、サイトを目的の新しい状態に更新する

    スワップ操作を取り消すか完了する方法については、「プレビューでのスワップ (複数フェーズのスワップ)」をご覧ください。

  • カスタム ウォームアップ時には、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=1 app settingを設定します。 ただし、このアプリケーション設定は Windows Communication Foundation (WCF) アプリでは動作しません。

次のステップ

非運用スロットへのアクセスをブロックする