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 App Service でステージング環境を設定する方法が説明されています。

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

前提条件

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

スロットを追加する

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

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

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

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

スワップ中の動作

スワップ操作の手順

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

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

   • スロット固有のアプリ設定と接続文字列 (該当する場合)。
   • 継続的デプロイの設定 (有効になっている場合)。
   • App Service の認証の設定 (有効になっている場合)。

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

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

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

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

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

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

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

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

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

スワップされる設定

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

スワップされる設定:

• 言語スタックとバージョン、32/64 ビット
• アプリ設定 (スロット固有として構成可能)
• 接続文字列 (スロット固有として構成可能)
• マウントされたストレージ アカウント (スロット固有として構成可能)
• ハンドラー マッピング
• パブリック証明書
• Web ジョブ コンテンツ
• ハイブリッド接続 *
• サービス エンドポイント *
• Azure Content Delivery Network *
• パスのマッピング

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

スワップされない設定:

• スワップされる設定に記載されていない全般設定
• 発行エンドポイント
• カスタム ドメイン名
• パブリックでない証明書と TLS/SSL 設定
• スケールの設定
• Web ジョブ スケジューラ
• IP 制限
• 常時接続
• 診断設定
• クロスオリジン リソース共有 (CORS)
• 仮想ネットワークの統合
• マネージド ID と関連する設定
• サフィックス _EXTENSION_VERSION で終わる設定
• サービス コネクタによって作成された設定

特定のスロットに固有の (スワップされない) アプリ設定や接続文字列を構成するには、そのスロットの [構成] ページに移動します。 設定を追加または編集し、 [deployment slot setting](スロット設定のデプロイ) を選択します。 このチェック ボックスをオンにすると、設定がスワップ可能ではないことが App Service に伝達されます。

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

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

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

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

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

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

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

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

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

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

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

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

自動スワップを構成する

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

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

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

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

一部のアプリでは、スワップ前のカスタム ウォームアップ アクションが必要な場合があります。 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 またはルート パス、/ が含まれます。

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

スワップを監視する

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

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2023-07-07 | where{$_.OperationName -eq 'Swap Web App Slots'}

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

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

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

クライアントが特定のスロットに自動的にルーティングされると、そのスロットに 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 に設定されているため、ユーザーはスロットに自動的にルーティングされません。 これは、内部チームにスロットでの変更のテストを許可する一方で、ステージング スロットをパブリックから "非表示" にできる高度なシナリオです。

スロットを削除する

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

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 つの方法があります。

  1. スワップ操作を取り消して、サイトを古い状態にリセットします
  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) アプリでは動作しません。

次のステップ

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