デプロイ スロットを作成する
Web アプリ、Linux 上の Web アプリ、モバイル バックエンド、または API アプリを Azure App Service にデプロイするときに、既定の運用スロットではなく別個のデプロイ スロットを使用できます。
デプロイ スロットについて知っておくべきこと
デプロイ スロットの特性を詳しく見てみましょう。
デプロイ スロットは、独自のホスト名を持つライブ アプリです。
デプロイ スロットは、Standard、Premium、Isolated の App Service 価格レベルでのみ使用できます。 デプロイ スロットを使用するには、アプリがこれらのレベルのいずれかで実行されている必要があります。
Standard、Premium、Isolated のレベルでは、それぞれ異なる数のデプロイ スロットが提供されます。
アプリのコンテンツと構成の各要素は、(運用スロットを含む) 2 つのデプロイ スロットの間でスワップすることができます。
デプロイ スロットを使用する際の考慮事項
App Service アプリでデプロイ スロットを使用すると、いくつかの利点があります。 次の利点を確認し、それらが App Service の実装をどのようにサポートできるかについて考えてください。
検証を考慮する。 アプリの変更を運用スロットのコンテンツとスワップする前に、ステージング デプロイ スロットでアプリへの変更を検証できます。
ダウンタイムの削減を考慮する。 スロットにアプリをデプロイした後に運用サイトにスワップすると、運用サイトへのスワップ前にスロットのすべてのインスタンスが準備されます。 このオプションにより、アプリをデプロイする際のダウンタイムがなくなります。 トラフィックのリダイレクトはシームレスであるため、スワップ操作によって破棄される要求はありません。 スワップ前の検証が必要ない場合、自動スワップを構成することで、ワークフロー全体を自動化できます。
最後の既知の正常なサイトの復元を考慮する。 スワップ後も、以前にステージングされたアプリを含むスロットに前の運用アプリが残るようになりました。 運用スロットにスワップした変更が想定どおりでない場合は、"適切な動作が確認されている元のサイト" にすぐに戻すことができます。
自動スワップを考慮する。 自動スワップは、コールド スタートとアプリ顧客にとってのダウンタイムを発生させずにアプリを連続的にデプロイしたいという Azure パイプラインのシナリオを合理化します。 あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、アプリが運用環境にスワップされます。 自動スワップは、Linux 上の Web アプリではサポートされていません。