Azure App Service でステージング環境を設定するSet up staging environments in Azure App Service

実行している App Service プランのサービス レベルが StandardPremium、または Isolated である場合は、Web アプリ、Linux 上の Web アプリ、モバイル バック エンド、または API アプリを Azure App Service にデプロイするときに、既定の運用スロットではなく別個のデプロイ スロットを使用できます。When you deploy your web app, web app on Linux, mobile back end, or API app to Azure App Service, you can use a separate deployment slot instead of the default production slot when you're running in the Standard, Premium, or Isolated App Service plan tier. デプロイ スロットは、固有のホスト名を持つライブ アプリです。Deployment slots are live apps with their own host names. アプリのコンテンツと構成の各要素は、(運用スロットを含む) 2 つのデプロイ スロットの間でスワップすることができます。App content and configurations elements can be swapped between two deployment slots, including the production slot.

非運用スロットにアプリケーションをデプロイすることには、次のメリットがあります。Deploying your application to a non-production slot has the following benefits:

  • ステージング デプロイ スロットでアプリの変更を検証した後に、運用スロットにスワップできます。You can validate app changes in a staging deployment slot before swapping it with the production slot.
  • スロットにアプリをデプロイした後に運用サイトにスワップすると、運用サイトへのスワップ前にスロットのすべてのインスタンスが準備されます。Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. これにより、アプリをデプロイする際のダウンタイムがなくなります。This eliminates downtime when you deploy your app. トラフィックのリダイレクトはシームレスであるため、スワップ操作によって破棄される要求はありません。The traffic redirection is seamless, and no requests are dropped because of swap operations. スワップ前の検証が必要ない場合は、自動スワップを構成することで、このワークフロー全体を自動化できます。You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.
  • スワップ後も、以前のステージング アプリ スロットに元の運用アプリが残っているため、After a swap, the slot with previously staged app now has the previous production app. 運用スロットにスワップした変更が想定どおりでない場合は、適切な動作が確認されている元のサイトにすぐに戻すことができます。If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.

サポートされるデプロイ スロット数は、App Service プラン レベルごとに異なります。Each App Service plan tier supports a different number of deployment slots. デプロイ スロットは追加料金なしでご利用いただけます。There's no additional charge for using deployment slots. 使用しているアプリのサービス レベルでサポートされるスロット数を確認するには、「App Service の制限」をご覧ください。To find out the number of slots your app's tier supports, see App Service limits.

アプリを別のサービス レベルにスケールするには、アプリが既に使用しているスロット数がターゲット レベルによってサポートされていることを確認します。To scale your app to a different tier, make sure that the target tier supports the number of slots your app already uses. たとえば、Standard レベルではサポートされるデプロイ スロット数は 5 つのみなので、アプリのスロット数が 5 つより多い場合は、Standard レベルにスケール ダウンできません。For example, if your app has more than five slots, you can't scale it down to the Standard tier, because the Standard tier supports only five deployment slots.

スロットを追加するAdd a slot

複数のデプロイ スロットを有効にするには、アプリが StandardPremiumIsolated のいずれかのレベルで実行されている必要があります。The app must be running in the Standard, Premium, or Isolated tier in order for you to enable multiple deployment slots.

  1. Azure portal で、 [App Services] を探して選択し、アプリを選択します。in the Azure portal, search for and select App Services and select your app.

    App Services を探す

  2. 左側のウィンドウで、 [デプロイ スロット] > [スロットの追加] と選択します。In the left pane, select Deployment slots > Add Slot.

    新しいデプロイ スロットの追加


    アプリのサービス レベルがまだ StandardPremium、または Isolated でない場合は、ステージングされた発行を有効にすることがサポートされているレベルを示すメッセージが表示されます。If the app isn't already in the Standard, Premium, or Isolated tier, you receive a message that indicates the supported tiers for enabling staged publishing. この時点で、操作を続行する前に、 [アップグレード] を選択してアプリの [スケール] タブに移動するオプションが用意されています。At this point, you have the option to select Upgrade and go to the Scale tab of your app before continuing.

  3. [スロットの追加] ダイアログ ボックスで、スロット名を指定し、別のデプロイ スロットからアプリ構成を複製するかどうかを選択します。In the Add a slot dialog box, give the slot a name, and select whether to clone an app configuration from another deployment slot. [追加] を選択して続行します。Select Add to continue.


    構成は、既存のどのスロットからも複製できます。You can clone a configuration from any existing slot. 複製できる設定には、アプリの設定、接続文字列、言語フレームワークのバージョン、Web ソケット、HTTP のバージョン、プラットフォームのビット数などがあります。Settings that can be cloned include app settings, connection strings, language framework versions, web sockets, HTTP version, and platform bitness.

  4. スロットを追加した後、 [閉じる] を選択してダイアログ ボックスを閉じます。After the slot is added, select Close to close the dialog box. これで新しいスロットが [デプロイ スロット] ページに表示されます。The new slot is now shown on the Deployment slots page. 既定では、新しいスロットの [トラフィック %] は 0 に設定され、顧客のトラフィックはすべて運用スロットにルーティングされます。By default, Traffic % is set to 0 for the new slot, with all customer traffic routed to the production slot.

  5. 新しいデプロイ スロットを選択して、そのスロットのリソース ページを開きます。Select the new deployment slot to open that slot's resource page.

    デプロイ スロットのタイトル

    ステージング スロットには、他の App Service アプリと同様に管理ページがあります。The staging slot has a management page just like any other App Service app. スロットの構成を変更することができます。You can change the slot's configuration. デプロイ スロットを表示していることを知らせるため、アプリ名は <app-name>/<slot-name> と表示され、アプリの種類は App Service (スロット) です。To remind you that you're viewing the deployment slot, the app name is shown as <app-name>/<slot-name>, and the app type is App Service (Slot). また、同じ指定先を使用して、リソース グループ内の別のアプリとしてスロットを表示することもできます。You can also see the slot as a separate app in your resource group, with the same designations.

  6. スロットのリソース ページで、アプリの URL を選択します。Select the app URL on the slot's resource page. デプロイ スロットは独自のホスト名を持ち、ライブ アプリでもあります。The deployment slot has its own host name and is also a live app. デプロイ スロットへのパブリック アクセスを制限するには、Azure App Service の IP 制限に関するページをご覧ください。To limit public access to the deployment slot, see Azure App Service IP restrictions.

別のスロットから設定を複製した場合でも、新しいデプロイ スロットには内容がありません。The new deployment slot has no content, even if you clone the settings from a different slot. たとえば、Git を使用してこのスロットに発行することができます。For example, you can publish to this slot with Git. スロットには、異なるリポジトリ分岐、または異なるリポジトリからデプロイできます。You can deploy to the slot from a different repository branch or a different repository.

スワップ中の動作What happens during a swap

スワップ操作の手順Swap operation steps

2 つのスロットを (通常はステージング スロットから運用スロットに) スワップするときには、ターゲット スロットでダウンタイムが発生しないようにするため、App Service が以下のことを行います。When you swap two slots (usually from a staging slot into the production slot), App Service does the following to ensure that the target slot doesn't experience downtime:

  1. ターゲット スロット (たとえば運用スロット) からソース スロットのすべてのインスタンスに対して、以下の設定を適用します。Apply the following settings from the target slot (for example, the production slot) to all instances of the source slot:

    これらのどの場合も、ソース スロット内のすべてのインスタンスがトリガーされます。Any of these cases trigger all instances in the source slot to restart. プレビューでのスワップ時には、これは最初のフェーズが終了したことを示します。During swap with preview, this marks the end of the first phase. スワップ操作が一時停止されると、ソース スロットが、ターゲット スロットの設定で正しく動作していることを検証できます。The swap operation is paused, and you can validate that the source slot works correctly with the target slot's settings.

  2. ソース スロット内のすべてのインスタンスが再起動を完了するまで待機します。Wait for every instance in the source slot to complete its restart. いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。If any instance fails to restart, the swap operation reverts all changes to the source slot and stops the operation.

  3. ローカル キャッシュが有効になっている場合は、ソース スロットの各インスタンスのアプリケーション ルート ("/") に対して HTTP 要求を行うことで、ローカル キャッシュの初期化をトリガーします。If local cache is enabled, trigger local cache initialization by making an HTTP request to the application root ("/") on each instance of the source slot. 各インスタンスが何らかの HTTP 応答を返すまで待機します。Wait until each instance returns any HTTP response. ローカル キャッシュの初期化により、各インスタンスでもう一度再起動が発生します。Local cache initialization causes another restart on each instance.

  4. カスタム ウォームアップによって自動スワップが有効になっている場合は、ソース スロットの各インスタンスのアプリケーション ルート ("/") に対して HTTP 要求を行うことで、アプリケーションの初期化をトリガーします。If auto swap is enabled with custom warm-up, trigger Application Initiation by making an HTTP request to the application root ("/") on each instance of the source slot.

    applicationInitialization が指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。If applicationInitialization isn't specified, trigger an HTTP request to the application root of the source slot on each instance.

    インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。If an instance returns any HTTP response, it's considered to be warmed up.

  5. ソース スロットのすべてのインスタンスが正常にウォームアップされたら、2 つのスロットのルーティング規則を入れ換えることで 2 つのスロットをスワップします。If all instances on the source slot are warmed up successfully, swap the two slots by switching the routing rules for the two slots. この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。After this step, the target slot (for example, the production slot) has the app that's previously warmed up in the source slot.

  6. この時点でソース スロットには、スワップ以前にはターゲット スロットにあったアプリがあるため、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances.

スワップ操作のどの時点でも、スワップされるアプリを初期化するすべての作業はソース スロットで発生しています。At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. ソース スロットが準備され、ウォームアップされている間、スワップがどこで成功するか失敗するかに関わらず、ターゲット スロットはオンライン状態に留まります。The target slot remains online while the source slot is being prepared and warmed up, regardless of where the swap succeeds or fails. ステージング スロットと運用スロットを入れ換える場合は常に、運用スロットがターゲット スロットであるようにします。To swap a staging slot with the production slot, make sure that the production slot is always the target slot. こうすることで、スワップ操作が運用アプリに影響を及ぼしません。This way, the swap operation doesn't affect your production app.

スワップされる設定Which settings are swapped?

別のデプロイ スロットから構成を複製する場合、複製された構成を編集することができます。When you clone configuration from another deployment slot, the cloned configuration is editable. 構成要素には、スワップを経ても内容が反映される (スロット固有でない) ものもあれば、スワップ後に同じスロットに残されている (スロット固有の) ものもあります。Some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific). 次の一覧では、スロットのスワップ時に変更される設定を示します。The following lists show the settings that change when you swap slots.

スワップされる設定:Settings that are swapped:

  • 一般設定 (フレームワーク バージョン、32/64 ビット、Web ソケットなど)General settings, such as framework version, 32/64-bit, web sockets
  • アプリ設定 (スロット固有として構成可能)App settings (can be configured to stick to a slot)
  • 接続文字列 (スロット固有として構成可能)Connection strings (can be configured to stick to a slot)
  • ハンドラー マッピングHandler mappings
  • パブリック証明書Public certificates
  • Web ジョブ コンテンツWebJobs content
  • ハイブリッド接続 *Hybrid connections *
  • Virtual Network 統合 *Virtual network integration *
  • サービス エンドポイント *Service endpoints *
  • Azure Content Delivery Network *Azure Content Delivery Network *

アスタリスク (*) 記号付きの機能は、スワップされない予定です。Features marked with an asterisk (*) are planned to be unswapped.

スワップされない設定:Settings that aren't swapped:

  • 発行エンドポイントPublishing endpoints
  • カスタム ドメイン名Custom domain names
  • パブリックでない証明書と TLS/SSL 設定Non-public certificates and TLS/SSL settings
  • スケールの設定Scale settings
  • Web ジョブ スケジューラWebJobs schedulers
  • IP 制限IP restrictions
  • 常時接続Always On
  • 診断設定Diagnostic settings
  • クロスオリジン リソース共有 (CORS)Cross-origin resource sharing (CORS)


スワップされていない設定に適用されている特定のアプリ設定もスワップされません。Certain app settings that apply to unswapped settings are also not swapped. たとえば、診断の設定はスワップされないため、WEBSITE_HTTPLOGGING_RETENTION_DAYSDIAGNOSTICS_AZUREBLOBRETENTIONDAYS などの関連するアプリ設定もスワップされません。これは、スロット設定として表示されない場合でも同様です。For example, since diagnostic settings are not swapped, related app settings like WEBSITE_HTTPLOGGING_RETENTION_DAYS and DIAGNOSTICS_AZUREBLOBRETENTIONDAYS are also not swapped, even if they don't show up as slot settings.

特定のスロットに固有の (スワップされない) アプリ設定や接続文字列を構成するには、そのスロットの [構成] ページに移動します。To configure an app setting or connection string to stick to a specific slot (not swapped), go to the Configuration page for that slot. 設定を追加または編集し、 [deployment slot setting](スロット設定のデプロイ) を選択します。Add or edit a setting, and then select deployment slot setting. このチェック ボックスを選択して、設定がスワップ可能ではないことを App Service に指示します。Selecting this check box tells App Service that the setting is not swappable.


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

アプリの [デプロイ スロット] ページと [概要] ページで、デプロイ スロットをスワップできます。You can swap deployment slots on your app's Deployment slots page and the Overview page. スロットのスワップに関する技術的詳細については、「スワップ中の動作」を参照してください。For technical details on the slot swap, see What happens during swap.


アプリをデプロイ スロットから運用環境にスワップする前に、運用環境がターゲット スロットになっていること、およびソース スロットのすべての設定が、運用環境に反映させたい内容で正確に構成されていることを確認してください。Before you swap an app from a deployment slot into production, make sure that production is your target slot and that all settings in the source slot are configured exactly as you want to have them in production.

デプロイ スロットをスワップするには:To swap deployment slots:

  1. アプリの [デプロイ スロット] ページに移動し、 [スワップ] を選択します。Go to your app's Deployment slots page and select Swap.

    [スワップ] ボタン

    [スワップ] ダイアログ ボックスに、選択したソース スロットとターゲット スロットの変更される設定が表示されます。The Swap dialog box shows settings in the selected source and target slots that will be changed.

  2. 目的の [ソース] および [ターゲット] スロットを選択します。Select the desired Source and Target slots. 通常、ターゲットは運用スロットになります。Usually, the target is the production slot. また、 [ソースの変更] タブと [ターゲットの変更] タブを選択して、構成の変更が予定されてることを確認します。Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. 完了したら、 [スワップ] を選択することで直ちにスロットをスワップできます。When you're finished, you can swap the slots immediately by selecting Swap.


    スワップを実際に行う前に、新しい設定でのターゲット スロットの動作を確認するには、 [スワップ] を選択しないで、「プレビューでのスワップ」の指示に従います。To see how your target slot would run with the new settings before the swap actually happens, don't select Swap, but follow the instructions in Swap with preview.

  3. 完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。When you're finished, close the dialog box by selecting Close.

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。If you have any problems, see Troubleshoot swaps.

プレビューでのスワップ (複数フェーズのスワップ)Swap with preview (multi-phase swap)

ターゲット スロットとしての運用環境にスワップする前に、スワップ後の設定でアプリの実行を検証します。Before you swap into production as the target slot, validate that the app runs with the swapped settings. ソース スロットは、スワップの完了前にウォームアップもされているため、ミッション クリティカルなアプリケーションに適しています。The source slot is also warmed up before the swap completion, which is desirable for mission-critical applications.

プレビューでのスワップを実行すると、App Service は同じスワップ操作を実行しますが、最初の手順の後に、一時停止します。When you perform a swap with preview, App Service performs the same swap operation but pauses after the first step. その後、スワップを完了する前にステージング スロットでの結果を検証できます。You can then verify the result on the staging slot before completing the swap.

スワップをキャンセルすると、構成要素がソース スロットに再適用されます。If you cancel the swap, App Service reapplies configuration elements to the source slot.

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

  1. デプロイ スロットをスワップする」の手順に従いますが、 [プレビューでスワップを実行] を選択します。Follow the steps in Swap deployment slots but select Perform swap with preview.


    ダイアログ ボックスに、フェーズ 1 でソース スロットの構成がどのように変わり、フェーズ 2 でソース スロットとターゲット スロットがどのように変わるかが表示されます。The dialog box shows you how the configuration in the source slot changes in phase 1, and how the source and target slot change in phase 2.

  2. スワップを開始する準備ができたら、 [スワップの開始] を選択します。When you're ready to start the swap, select Start Swap.

    フェーズ 1 が終了すると、ダイアログ ボックスで通知されます。When phase 1 finishes, you're notified in the dialog box. https://<app_name>-<source-slot-name> に移動して、ソース スロットでのスワップをプレビューします。Preview the swap in the source slot by going to https://<app_name>-<source-slot-name>

  3. 保留中のスワップを完了する準備ができたら、 [スワップ アクション][スワップの完了] を選択し、 [スワップの完了] を選択します。When you're ready to complete the pending swap, select Complete Swap in Swap action and select Complete Swap.

    保留中のスワップを取り消すには、代わりに [スワップの取り消し] を選択します。To cancel a pending swap, select Cancel Swap instead.

  4. 完了したら、 [閉じる] を選択してダイアログ ボックスを閉じます。When you're finished, close the dialog box by selecting Close.

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。If you have any problems, see Troubleshoot swaps.

複数フェーズのスワップを自動化するには、「PowerShell で自動化する」をご覧ください。To automate a multi-phase swap, see Automate with PowerShell.

スワップをロールバックするRoll back a swap

スロットのスワップ後にターゲット スロット (運用スロットなど) でエラーが発生する場合は、同じ 2 つのスロットをすぐにスワップして、スロットをスワップ前の状態に復元します。If any errors occur in the target slot (for example, the production slot) after a slot swap, restore the slots to their pre-swap states by swapping the same two slots immediately.

自動スワップを構成するConfigure auto swap


自動スワップは、Linux 上の Web アプリではサポートされていません。Auto swap isn't supported in web apps on Linux.

自動スワップを使うと、アプリのユーザーにコールド スタートを課したりダウンタイムを生じさせたりすることなく、アプリを連続的にデプロイする効率的な Azure DevOps シナリオを実現できます。Auto swap streamlines Azure DevOps scenarios where you want to deploy your app continuously with zero cold starts and zero downtime for customers of the app. あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、アプリが運用環境にスワップされます。When auto swap is enabled from a slot into production, every time you push your code changes to that slot, App Service automatically swaps the app into production after it's warmed up in the source slot.


運用スロットの自動スワップを構成する前に、非運用環境のターゲット スロットで自動スワップをテストすることを検討してください。Before you configure auto swap for the production slot, consider testing auto swap on a non-production target slot.

自動スワップを構成するには:To configure auto swap:

  1. アプリのリソース ページに移動します。Go to your app's resource page. [デプロイ スロット] > [<目的のソース スロット>] > [構成] > [全般設定] と選択します。Select Deployment slots > <desired source slot> > Configuration > General settings.

  2. [Auto swap enabled](自動スワップ有効化) で、 [オン] を選択します。For Auto swap enabled, select On. [Auto swap deployment slot](自動スワップのデプロイ スロット) で目的のターゲット スロットを選択し、コマンド バーで [保存] を選択します。Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar.


  3. ソース スロットへのコードのプッシュを実行します。Execute a code push to the source slot. しばらくすると自動スワップが実行され、更新がターゲット スロットの URL に反映されます。Auto swap happens after a short time, and the update is reflected at your target slot's URL.

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。If you have any problems, see Troubleshoot swaps.

カスタム ウォームアップを指定するSpecify custom warm-up

一部のアプリでは、スワップ前のカスタム ウォームアップ アクションが必要な場合があります。Some apps might require custom warm-up actions before the swap. web.config の applicationInitialization 構成要素を使用して、カスタム初期化アクションを指定できます。The applicationInitialization configuration element in web.config lets you specify custom initialization actions. スワップ操作では、このカスタム ウォームアップの終了を待ってから、ターゲット スロットとのスワップが行われます。The swap operation waits for this custom warm-up to finish before swapping with the target slot. 以下に、サンプルの web.config フラグメントを示します。Here's a sample web.config fragment.

        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />

applicationInitialization 要素のカスタマイズの詳細については、「Most common deployment slot swap failures and how to fix them (最も一般的なデプロイ スロットのスワップ エラーとその修正方法)」を参照してください。For more information on customizing the applicationInitialization element, see Most common deployment slot swap failures and how to fix them.

次のアプリ設定の 1 つまたは両方を使用して、ウォームアップの動作をカスタマイズすることもできます。You can also customize the warm-up behavior with one or both of the following app settings:

  • WEBSITE_SWAP_WARMUP_PING_PATH:サイトをウォームアップするための ping へのパス。WEBSITE_SWAP_WARMUP_PING_PATH: The path to ping to warm up your site. このアプリ設定を追加するには、値としてスラッシュで始まるカスタム パスを指定します。Add this app setting by specifying a custom path that begins with a slash as the value. たとえば /statuscheck です。An example is /statuscheck. 既定値は / です。The default value is /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES:ウォーム アップ操作の有効な HTTP 応答コード。WEBSITE_SWAP_WARMUP_PING_STATUSES: Valid HTTP response codes for the warm-up operation. HTTP コードのコンマ区切りの一覧で、このアプリ設定を追加します。Add this app setting with a comma-separated list of HTTP codes. たとえば 200,202 とします。An example is 200,202 . 返された状態コードが一覧にない場合、ウォームアップとスワップの操作が停止されます。If the returned status code isn't in the list, the warmup and swap operations are stopped. 既定で、すべての応答コードは有効です。By default, all response codes are valid.


<applicationInitialization> 構成要素は各アプリの起動に含まれますが、2 つのウォームアップの動作を行うアプリの設定はスロット スワップにのみ適用されます。The <applicationInitialization> configuration element is part of each app start-up, whereas the two warm-up behavior app settings apply only to slot swaps.

問題がある場合は、「スワップのトラブルシューティングを行う」を参照してください。If you have any problems, see Troubleshoot swaps.

スワップを監視するMonitor a swap

スワップ操作が完了するまで長い時間がかかる場合、アクティビティ ログでスワップ操作に関する情報を取得できます。If the swap operation takes a long time to complete, you can get information on the swap operation in the activity log.

ポータルのアプリのリソース ページで、左側のウィンドウの [アクティビティ ログ] を選択します。On your app's resource page in the portal, in the left pane, select Activity log.

スワップ操作がログ クエリに Swap Web App Slots として表示されます。A swap operation appears in the log query as Swap Web App Slots. これを展開し、副操作やエラーの 1 つを選択して詳細を表示できます。You can expand it and select one of the suboperations or errors to see the details.

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

既定では、アプリの運用環境の URL (http://<app_name> に対するすべてのクライアント要求は、運用スロットにルーティングされます。By default, all client requests to the app's production URL (http://<app_name> are routed to the production slot. トラフィックの一部を、別のスロットにルーティングできます。You can route a portion of the traffic to another slot. この機能は、新しい更新についてのユーザーのフィードバックが必要であっても、運用環境にリリースできる状態ではない場合に便利です。This feature is useful if you need user feedback for a new update, but you're not ready to release it to production.

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

運用トラフィックを自動的にルーティングするには:To route production traffic automatically:

  1. アプリのリソース ページに移動し、 [デプロイ スロット] を選択します。Go to your app's resource page and select Deployment slots.

  2. ルーティング先のスロットの [トラフィック %] 列で、ルーティングするトラフィックの合計量を表す割合 (0 ~ 100) を指定します。In the Traffic % column of the slot you want to route to, specify a percentage (between 0 and 100) to represent the amount of total traffic you want to route. [保存] を選択します。Select Save.


設定の保存後は、指定した割合のクライアントが、非運用スロットにランダムにルーティングされます。After the setting is saved, the specified percentage of clients is randomly routed to the non-production slot.

クライアントは、特定のスロットに自動的にルーティングされると、そのクライアント セッションの有効期間中はそのスロットに "固定" されます。After a client is automatically routed to a specific slot, it's "pinned" to that slot for the life of that client session. クライアントのブラウザーで、HTTP ヘッダー内の x-ms-routing-name Cookie を調べることにより、セッションが固定されているスロットを確認できます。On the client browser, you can see which slot your session is pinned to by looking at the x-ms-routing-name cookie in your HTTP headers. "ステージング" スロットにルーティングされる要求には、x-ms-routing-name=staging という Cookie が設定されています。A request that's routed to the "staging" slot has the cookie x-ms-routing-name=staging. 運用スロットにルーティングされる要求には、x-ms-routing-name=self という Cookie が設定されています。A request that's routed to the production slot has the cookie x-ms-routing-name=self.


また、Azure portal の次に、Azure CLI の az webapp traffic-routing set コマンドを使用して、DevOps パイプラインやその他のオートメーション システムなどの CI/CD ツールからルーティングの割合を設定することもできます。Next to the Azure portal, you can also use the az webapp traffic-routing set command in the Azure CLI to set the routing percentages from CI/CD tools like DevOps pipelines or other automation systems.

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

App Service では、トラフィックの自動ルーティングだけでなく、特定のスロットに要求をルーティングすることもできます。In addition to automatic traffic routing, App Service can route requests to a specific slot. この方法は、ユーザーがベータ版アプリの利用を選択または拒否できるようにしたい場合に便利です。This is useful when you want your users to be able to opt in to or opt out of your beta app. 運用トラフィックを手動でルーティングするには、x-ms-routing-name クエリ パラメーターを使用します。To route production traffic manually, you use the x-ms-routing-name query parameter.

ベータ版アプリの利用をユーザーが拒否できるようにするには、たとえば次のようなリンクを Web ページに配置します。To let users opt out of your beta app, for example, you can put this link on your webpage:

<a href="<webappname>">Go back to production app</a>

文字列 x-ms-routing-name=self に指定されているのは運用スロットです。The string x-ms-routing-name=self specifies the production slot. クライアント ブラウザーは、リンクにアクセスすると、運用スロットにリダイレクトされます。After the client browser accesses the link, it's redirected to the production slot. 以降のすべての要求には、セッションをその運用スロットに固定する x-ms-routing-name=self cookie が含まれます。Every subsequent request has the x-ms-routing-name=self cookie that pins the session to the production slot.

ベータ版アプリの利用をユーザーが選択できるようにするには、同じクエリ パラメーターを、非運用スロットの名前に設定します。To let users opt in to your beta app, set the same query parameter to the name of the non-production slot. 次に例を示します。Here's an example:


既定では、新しいスロットには、0% のルーティング規則がグレーで表示されます。By default, new slots are given a routing rule of 0%, shown in grey. この値を明示的に 0% に設定すると (黒のテキストで表示されます)、ユーザーは x-ms-routing-name クエリ パラメーターを使用して、ステージング スロットに手動でアクセスできます。When you explicitly set this value to 0% (shown in black text), your users can access the staging slot manually by using the x-ms-routing-name query parameter. しかし、ルーティングの割合は 0 に設定されているため、ユーザーはスロットに自動的にルーティングされません。But they won't be routed to the slot automatically because the routing percentage is set to 0. これは、内部チームにスロットでの変更のテストを許可する一方で、ステージング スロットをパブリックから "非表示" にできる高度なシナリオです。This is an advanced scenario where you can "hide" your staging slot from the public while allowing internal teams to test changes on the slot.

スロットを削除するDelete a slot

アプリを検索して選択します。Search for and select your app. [デプロイ スロット] > <削除するスロット> > [概要] の順に選択します。Select Deployment slots > <slot to delete> > Overview. アプリの種類は App Service (スロット) として表示され、デプロイ スロットが表示されていることを知らせます。The app type is shown as App Service (Slot) to remind you that you're viewing a deployment slot. コマンド バーの [削除] を選択します。Select Delete on the command bar.

デプロイ スロットの削除

PowerShell で自動化するAutomate with PowerShell


この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

Azure PowerShell は、Windows PowerShell から Azure を管理するためのコマンドレットを提供するモジュールです (Azure App Service のデプロイ スロットを管理するためのサポートなど)。Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell, including support for managing deployment slots in Azure App Service.

Azure PowerShell のインストールと構成、Azure サブスクリプションを使用した Azure PowerShell の認証については、「 Microsoft Azure PowerShell のインストールおよび構成方法」を参照してください。For information on installing and configuring Azure PowerShell, and on authenticating Azure PowerShell with your Azure subscription, see How to install and configure Microsoft Azure PowerShell.

Web アプリを作成するCreate a web app

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

スロットを作成するCreate a slot

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

プレビューでのスワップ (複数フェーズのスワップ) を開始し、送信先スロットの構成をソース スロットに適用するInitiate a swap with a preview (multi-phase swap), and apply destination slot configuration to the source slot

$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

保留中のスワップ (レビューでのスワップ) を取り消し、ソースのスロットの構成を復元するCancel a pending swap (swap with review) and restore the source slot configuration

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

デプロイ スロットをスワップするSwap deployment slots

$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

アクティビティ ログでスワップ イベントを監視するMonitor swap events in the activity log

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

スロットを削除するDelete a slot

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

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

Azure Resource Manager テンプレートは、Azure リソースのデプロイと構成を自動化するために使用される宣言型の JSON ファイルです。Azure Resource Manager templates are declarative JSON files used to automate the deployment and configuration of Azure resources. Resource Manager テンプレートを使用してスロットをスワップするには、Microsoft.Web/sites/slotsMicrosoft.Web/sites リソースに 2 つのプロパティを設定する必要があります。To swap slots by using Resource Manager templates, you will set two properties on the Microsoft.Web/sites/slots and Microsoft.Web/sites resources:

  • buildVersion: これは、スロットにデプロイされているアプリの現在のバージョンを表す文字列プロパティです。buildVersion: this is a string property which represents the current version of the app deployed in the slot. たとえば、"v1"、""、または "2019-09-20T11:53:25.2887393-07:00" のようになります。For example: "v1", "", or "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: これは、スロットに必要な buildVersion を指定する文字列プロパティです。targetBuildVersion: this is a string property that specifies what buildVersion the slot should have. targetBuildVersion が現在の buildVersion と等しくない場合は、指定された buildVersion を持つスロットを検索することによってスワップ操作がトリガーされます。If the targetBuildVersion does not equal the current buildVersion, then this will trigger the swap operation by finding the slot which has the specified buildVersion.

Resource Manager テンプレートの例Example Resource Manager template

次の Resource Manager テンプレートでは、ステージング スロットの buildVersion が更新され、運用スロットで targetBuildVersion が設定されます。The following Resource Manager template will update the buildVersion of the staging slot and set the targetBuildVersion on the production slot. これにより、2 つのスロットがスワップされます。This will swap the two slots. このテンプレートは、"staging" という名前のスロットを持つ Web アプリが既に作成されていることを前提としています。The template assumes you already have a webapp created with a slot named "staging".

    "$schema": "",
    "contentVersion": "",
    "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 テンプレートはべき等です。つまり、繰り返し実行して、スロットの同じ状態を生成することができます。This Resource Manager template is idempotent, meaning that it can be executed repeatedly and produce the same state of the slots. 最初の実行後、targetBuildVersion は現在の buildVersion と一致するため、スワップはトリガーされません。After the first execution, targetBuildVersion will match the current buildVersion, so a swap will not be triggered.

CLI で自動化するAutomate with the CLI

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

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

スロットのスワップ中に何らかのエラーが発生した場合、そのエラーは D:\home\LogFiles\eventlog.xml にログ記録されます。If any error occurs during a slot swap, it's logged in D:\home\LogFiles\eventlog.xml. アプリケーション固有のエラー ログにも記録されます。It's also logged in the application-specific error log.

以下に、スワップの一般的なエラーをいくつか示します。Here are some common swap errors:

  • アプリケーション ルートへの HTTP 要求には時間枠が設けられています。An HTTP request to the application root is timed. スワップ操作は、HTTP 要求ごとに 90 秒間待機し、最大 5 回再試行します。The swap operation waits for 90 seconds for each HTTP request, and retries up to 5 times. すべての再試行がタイムアウトになると、スワップ操作は停止されます。If all retries are timed out, the swap operation is stopped.

  • アプリのコンテンツがローカル キャッシュ用に指定されたローカル ディスクのクォータを超過すると、ローカル キャッシュの初期化が失敗することがあります。Local cache initialization might fail when the app content exceeds the local disk quota specified for the local cache. 詳細については、ローカル キャッシュの概要に関するページを参照してください。For more information, see Local cache overview.

  • カスタム ウォームアップ時には、HTTP 要求は (外部 URL を経由することなく) 内部的に作成されます。During custom warm-up, the HTTP requests are made internally (without going through the external URL). Web.config 内に特定の URL 書き換えルールがあると、それらが失敗する可能性があります。たとえば、ドメイン名をリダイレクトするルールや HTTPS を適用するルールは、ウォームアップ要求がアプリ コードに到達するのを妨げることがあります。They can fail with certain URL rewrite rules in Web.config. For example, rules for redirecting domain names or enforcing HTTPS can prevent warm-up requests from reaching the app code. この問題を回避するには、以下のように 2 つの条件を追加して、書き換えルールを変更します。To work around this issue, modify your rewrite rules by adding the following two conditions:

      <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  • カスタム ウォームアップを行わなくても、URL 書き換えルールが HTTP 要求をブロックする場合があります。Without a custom warm-up, the URL rewrite rules can still block HTTP requests. この問題を回避するには、以下のように条件を追加して、書き換えルールを変更します。To work around this issue, modify your rewrite rules by adding the following condition:

      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  • 一部の IP 制限ルールにより、スワップ操作でのアプリへの HTTP 要求の送信が妨げられる可能性があります。Some IP restriction rules might prevent the swap operation from sending HTTP requests to your app. 10. および 100. で始まる IPv4 アドレスの範囲は、デプロイに対して内側です。IPv4 address ranges that start with 10. and 100. are internal to your deployment. これらにアプリへの接続を許可する必要があります。You should allow them to connect to your app.

  • スロットをスワップした後、アプリが予期せず再起動する可能性があります。After slot swaps, the app may experience unexpected restarts. これは、スワップ後にホスト名のバインド構成の同期が切れ、単体では再起動を行うことができないためです。This is because after a swap, the hostname binding configuration goes out of sync, which by itself doesn't cause restarts. ただし、基盤となる特定のストレージ イベント (記憶域ボリュームのフェールオーバーなど) によってこれらの不一致が検出され、すべてのワーカー プロセスが強制的に再起動される可能性があります。However, certain underlying storage events (such as storage volume failovers) may detect these discrepancies and force all worker processes to restart. このような再起動を最小限に抑えるには、すべてのスロットWEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1アプリ設定を設定します。To minimize these types of restarts, set the WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 app setting on all slots. ただし、このアプリケーション設定は Windows Communication Foundation (WCF) アプリでは動作しませんHowever, this app setting does not work with Windows Communication Foundation (WCF) apps.

次のステップNext steps

非運用スロットへのアクセスをブロックするBlock access to non-production slots