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

完了

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

デプロイ スロットの手動スワップ

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

  1. アプリの [デプロイ スロット] ページに移動し、 [スワップ] を選択します。 [スワップ] ダイアログ ボックスに、選択したソース スロットとターゲット スロットの変更される設定が表示されます。

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

    スワップが実際に行われる前に、ターゲット スロットが新しい設定でどのように実行されるかを確認するには、[スワップ] を選択せずに、下記の「プレビューでのスワップ」の手順に従います。

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

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

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

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

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

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

  1. 上記の [デプロイ スロット」の [スワップ] での手順に従いますが、[プレビューでスワップを実行] を選択します。 ダイアログ ボックスに、フェーズ 1 でソース スロットの構成がどのように変わり、フェーズ 2 でソース スロットとターゲット スロットがどのように変わるかが表示されます。

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

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

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

    保留中のスワップを取り消すには、代わりに [スワップの取り消し] を選択します。

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

自動スワップを構成する

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

注意

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

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

  1. アプリのリソース ページにアクセスし、自動スワップを構成するデプロイ スロットを選択します。 設定は、[構成] > [全般設定] ページにあります。

  2. [自動スワップが有効][オン] に設定します。 [自動スワップ デプロイ スロット] で目的のターゲット スロットを選択し、コマンド バーで [保存] を選択します。

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

ロールバックしてスワップを監視する

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

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

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

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