デプロイ スロットを作成する

多くの場合、組織はデプロイの前に Web アプリをテストするために、それを分離された環境で実行する必要があります。 また、迅速に、かつユーザーに影響を与えることなくデプロイする必要もあります。

ご自身のソーシャル メディア システムに Web アプリをデプロイする効率的な方法として、スロットを使うかどうか決定しようとしているとします。 デプロイ スロットによってデプロイの間のダウンタイムが短くなるかどうか、ロールバックが容易になるかどうか、またそれらを Azure で設定できるかどうかについて明らかにする必要があります。

ここでは、デプロイ スロットによって新しいコードのテストとロールアウトが容易になるしくみを学習します。

デプロイ スロットを使う

1 つの Azure App Service Web アプリ内に、複数のデプロイ スロットを作成できます。 各スロットは、その Web アプリの別々のインスタンスであり、別々のホスト名を持っています。 異なるバージョンの Web アプリを、各スロットにデプロイできます。

スロットの 1 つは運用スロットです。 このスロットは、ユーザーが接続したときに表示される Web アプリです。 このスロットにデプロイするアプリは、安定していて十分にテストされたものであることを確認します。

追加のスロットを使用して、新しいバージョンの Web アプリをホストします。 これらのインスタンスに対し、統合テスト、受け入れテスト、キャパシティ テストなどのテストを実行できます。 運用スロットにコードを移動する前に問題を修正します。 追加のスロットは独自の App Service インスタンスのように動作します。そのため、テストによって運用環境でアプリがどのように動作するかが示されていることを信頼できます。

新しいバージョンのアプリのテスト結果に満足したら、そのスロットを運用スロットとスワップすることで、それをデプロイします。 コードのデプロイとは異なり、スロットのスワップは一瞬です。 スロットをスワップすると、スロットのホスト名が交換されて、アプリの新しいバージョンに運用トラフィックがすぐに送信されます。 スロットのスワップを使用してデプロイすると、アプリが部分的にデプロイされた状態でパブリックな Web に公開されることがなくなります。

注意深いテストにもかかわらず、新しいバージョンに問題が見つかった場合は、スロットをスワップして戻すことでバージョンをロールバックできます。

個別の Azure リソースとしてのスロットを理解する

Web アプリ用に複数のデプロイ スロットを使用する場合、それらのスロットはその Web アプリの個別のインスタンスとして扱われます。 たとえば、それらは Azure portal の [すべてのリソース] ページ上で別々に一覧表示されます。 そのそれぞれが独自の URL を持っています。 ただし、各スロットは、仮想マシンのメモリと CPU やディスク領域など、App Service プランのリソースを共有します。

デプロイ スロットの作成とサービス レベル

デプロイ スロットは、Web アプリで Standard、Premium、または Isolated サービス レベルの App Service プランが使用されている場合にのみ利用できます。 作成できるスロットの最大数を次の表に示します。

スワップ中のコールド スタートを回避する

Web アプリの作成に開発者が使用するテクノロジの多くでは、ユーザーにページを配信する前に、サーバー上で最終的なコンパイルやその他の操作を行う必要があります。 これらのタスクの多くは、アプリが起動して要求を受け取ったときに行われます。 たとえば、ASP.NET を使用してアプリを構築した場合、最初のユーザーがページを要求したときに、コードがコンパイルされてビューが完成します。 コードが既にコンパイルされているため、そのページに対する後続の要求では応答がより速く返されます。

この初期遅延は、"コールド スタート" と呼ばれます。 スロットのスワップを使って運用環境にデプロイすることで、コールド スタートを回避できます。 運用環境にスロットをスワップすると、自分の操作によってサイトのルートに要求が送信されるため、アプリを "ウォームアップ" させることになります。 ウォームアップ要求により、すべてのコンパイル タスクとキャッシュ タスクが完了していることが保証されます。 スワップの後、サイトは何日も前からデプロイされている場合と同じ速さで応答します。

デプロイ スロットを作成する

スロットを作成する前に、Web アプリが Standard、Premium、または Isolated サービス レベルで実行されていることを確認します。

1. Azure portal で Web アプリを開きます。

2. [デプロイ スロット] ペインを選択します。

3. [スロットの追加] を選択します。

4. スロットに名前を付けます。

5. 別のスロットから設定を複製するかどうかを選択します。 複製を選択すると、指定したスロットから新しいスロットに設定がコピーされます。

   

[追加] を選択して、新しいスロットを作成します。 これで、[デプロイ スロット] ページの一覧に新しいスロットが表示されるようになります。 そのスロットを選択して管理ペインを表示します。

スロットにアクセスする

新しいスロットのホスト名は、Web アプリの名前とそのスロットの名前から派生します。 [デプロイ スロット] ページでスロットを選択すると、このホスト名を取得できます。

運用スロットにデプロイする場合と同じ方法で、新しいスロットにコードをデプロイできます。 使用するデプロイ ツールの構成で、新しいスロットの名前または URL を代わりに使うだけです。 FTP を使用してデプロイする場合は、スロットの URL のすぐ下に FTP のホスト名とユーザー名が表示されます。

新しいスロットは、実質的に別のホスト名を持つ個別の Web アプリです。 そのため、そのホスト名を知っていれば誰でもインターネットでアクセスできます。 スロットを検索エンジンに登録したり、クロールされたページからこれにリンクしたりしない限り、スロットは検索エンジンのインデックスに表示されません。 これは、一般的なインターネット ユーザーからは隠ぺいされたままになります。

IP アドレスの制限を使用することで、スロットへのアクセスを制限できます。 スロットへのアクセスを許可する IP アドレスの範囲のリストか、スロットへのアクセスを拒否する範囲のリストを作成します。 これらのリストは、ファイアウォール上で設定できる許可範囲や拒否範囲に似ています。 このリストを使用して、会社や開発チームに属しているコンピューターにのみアクセスを許可します。