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

[アーティクル]
03/08/2023

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

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

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

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

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

スロットを追加する

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

Azure portal で、 [App Services] を探して選択し、アプリを選択します。
左側のウィンドウで、 [デプロイスロット]>[スロットの追加] と選択します。

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 文字で切り捨てられ、スロット名は 19 文字で切り捨てられ、結果のドメイン名が一意になるように、4 つのランダムな文字が追加されます。

スワップ中の動作

スワップ操作の手順

2 つのスロットを (通常はステージングスロットから運用スロットに) スワップするときには、ターゲットスロットでダウンタイムが発生しないようにするため、App Service が以下のことを行います。

ターゲットスロット (たとえば運用スロット) からソーススロットのすべてのインスタンスに対して、以下の設定を適用します。
- スロット固有のアプリ設定と接続文字列 (該当する場合)。
- 継続的デプロイの設定 (有効になっている場合)。
- App Service の認証の設定 (有効になっている場合)。
これらのどの場合も、ソーススロット内のすべてのインスタンスがトリガーされます。スワップ中のプレビューは、最初のフェーズが終了したことを示します。スワップ操作が一時停止しても、ターゲットスロットの設定によってソーススロットが正しく動作していることを検証できます。
ソーススロット内のすべてのインスタンスが再起動を完了するまで待機します。いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソーススロットに戻されて、操作が停止されます。
ローカルキャッシュが有効になっている場合は、ソーススロットの各インスタンスのアプリケーションルート ("/") に対して HTTP 要求を行うことで、ローカルキャッシュの初期化をトリガーします。各インスタンスが何らかの HTTP 応答を返すまで待機します。ローカルキャッシュの初期化により、各インスタンスでもう一度再起動が発生します。
カスタムウォームアップによって自動スワップが有効になっている場合は、ソーススロットの各インスタンスのアプリケーションルート ("/") に対して HTTP 要求を行うことで、アプリケーションの初期化をトリガーします。

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

インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。
ソーススロットのすべてのインスタンスが正常にウォームアップされたら、2 つのスロットのルーティング規則を入れ換えることで 2 つのスロットをスワップします。この手順の後に、運用スロットなどのターゲットスロットには、ソーススロットで以前にウォームアップされたアプリが存在します。
この時点でソーススロットが保有するスワップ前のアプリは、以前ターゲットスロットに存在しており、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。

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

Note

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

スワップされる設定

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

スワップされる設定:

一般設定 (フレームワークバージョン、32/64 ビット、Web ソケットなど)
アプリ設定 (スロット固有として構成可能)
接続文字列 (スロット固有として構成可能)
ハンドラーマッピング
パブリック証明書
WebJob コンテンツ
ハイブリッド接続 *
サービスエンドポイント *
Azure Content Delivery Network *
パスのマッピング

アスタリスク (*) 記号付きの機能は、スワップされない予定です。

スワップされない設定:

発行エンドポイント
カスタムドメイン名
パブリックでない証明書と TLS/SSL 設定
スケールの設定
WebJob スケジューラ
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 に移動して、ソーススロットでのスワップをプレビューします。
保留中のスワップを完了する準備ができたら、 [スワップアクション] で [スワップの完了] を選択し、 [スワップの完了] を選択します。

保留中のスワップを取り消すには、代わりに [スワップの取り消し] を選択します。
完了したら、 [閉じる] を選択してダイアログボックスを閉じます。

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

複数フェーズのスワップを自動化するには、「PowerShell で自動化する」をご覧ください。

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

スロットのスワップ後にターゲットスロット (運用スロットなど) でエラーが発生する場合は、同じ 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 が設定されています。

Note

Azure CLI の az webapp traffic-routing set コマンドでも、GitHub Actions などの CI/CD ツール、DevOps パイプライン、その他の自動化システムのルーティング割合を設定できます。

運用トラフィックを手動でルーティングする

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 に設定してください。コマンドバーの [削除] を選択します。

デプロイスロットの削除

PowerShell で自動化する

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

Azure PowerShell は、Windows PowerShell から Azure を管理するためのコマンドレットを提供するモジュールです (Azure App Service のデプロイスロットを管理するためのサポートなど)。

Azure PowerShell のインストールと構成、Azure サブスクリプションを使用した Azure PowerShell の認証については、「 Microsoft Azure PowerShell のインストールおよび構成方法」を参照してください。

Web アプリを作成する

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

スロットを作成する

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

プレビューでのスワップ (複数フェーズのスワップ) を開始し、送信先スロットの構成をソーススロットに適用する

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

保留中のスワップ (レビューでのスワップ) を取り消し、ソースのスロットの構成を復元する

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

デプロイスロットをスワップする

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

アクティビティログでスワップイベントを監視する

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor

スロットを削除する

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

運用スロットからスロットを入れ替えるには、Microsoft.Web/sites/slotsswap/Action 操作を実行するための (少なくとも) アクセス許可が ID に必要です。詳細については、リソースプロバイダーの操作に関する記事を参照してください

Resource Manager テンプレートで自動化する

Azure Resource Manager テンプレートは、Azure リソースのデプロイと構成を自動化するために使用される宣言型の JSON ファイルです。 Resource Manager テンプレートを使用してスロットをスワップするには、Microsoft.Web/sites/slots と Microsoft.Web/sites リソースに 2 つのプロパティを設定する必要があります。

buildVersion: これは、スロットにデプロイされているアプリの現在のバージョンを表す文字列プロパティです。たとえば、"v1"、"1.0.0.1"、または "2019-09-20T11:53:25.2887393-07:00" のようになります。
targetBuildVersion: これは、スロットに必要な buildVersion を指定する文字列プロパティです。 targetBuildVersion が現在の buildVersion と等しくない場合は、指定された buildVersion を持つスロットを検索することによってスワップ操作がトリガーされます。

Resource Manager テンプレートの例

次の Resource Manager テンプレートでは、ステージングスロットの buildVersion が更新され、運用スロットで targetBuildVersion が設定されます。これにより、2 つのスロットがスワップされます。このテンプレートは、"staging" という名前のスロットを持つ Web アプリが既に作成されていることを前提としています。

{
    "$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 テンプレートはべき等です。つまり、繰り返し実行して、スロットの同じ状態を生成することができます。最初の実行後、targetBuildVersion は現在の buildVersion と一致するため、スワップはトリガーされません。

CLI で自動化する

デプロイスロット用の Azure CLI コマンドについては、「az webapp deployment slot」をご覧ください。

スワップのトラブルシューティングを行う

スロットのスワップ中に何らかのエラーが発生した場合、そのエラーは 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=1 app settingを設定します。ただし、このアプリケーション設定は Windows Communication Foundation (WCF) アプリでは動作しません。

次のステップ

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

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

スロットを追加する

スワップ中の動作

スワップ操作の手順

スワップされる設定

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

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

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

自動スワップを構成する

カスタムウォームアップを指定する

スワップを監視する

トラフィックをルーティングする

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

運用トラフィックを手動でルーティングする

スロットを削除する

PowerShell で自動化する

Web アプリを作成する

スロットを作成する

プレビューでのスワップ (複数フェーズのスワップ) を開始し、送信先スロットの構成をソーススロットに適用する

保留中のスワップ (レビューでのスワップ) を取り消し、ソースのスロットの構成を復元する

デプロイスロットをスワップする

アクティビティログでスワップイベントを監視する

スロットを削除する

Resource Manager テンプレートで自動化する

Resource Manager テンプレートの例

CLI で自動化する

スワップのトラブルシューティングを行う

次のステップ

その他のリソース

その他のリソース

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

スロットを追加する

スワップ中の動作

スワップ操作の手順

スワップされる設定

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

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

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

自動スワップを構成する

カスタム ウォームアップを指定する

スワップを監視する

トラフィックをルーティングする

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

運用トラフィックを手動でルーティングする

スロットを削除する

PowerShell で自動化する

Web アプリを作成する

スロットを作成する

プレビューでのスワップ (複数フェーズのスワップ) を開始し、送信先スロットの構成をソース スロットに適用する

保留中のスワップ (レビューでのスワップ) を取り消し、ソースのスロットの構成を復元する

デプロイ スロットをスワップする

アクティビティ ログでスワップ イベントを監視する

スロットを削除する

Resource Manager テンプレートで自動化する

Resource Manager テンプレートの例

CLI で自動化する

スワップのトラブルシューティングを行う

次のステップ

その他のリソース

その他のリソース

カスタムウォームアップを指定する

プレビューでのスワップ (複数フェーズのスワップ) を開始し、送信先スロットの構成をソーススロットに適用する

デプロイスロットをスワップする

アクティビティログでスワップイベントを監視する