そのため、Microsoft Azureはアプリケーションを自動的に更新するための非常に広範な手段を提供し、原則として他の人が現在アプリケーションを使用しているため、最も重要な問題はオンザフライで、つまり目に見えないように更新することです。 Microsoft Azureアプリケーションに適用できるすべての可能な方法を見てみましょう。
Web展開
この更新メカニズムは、テストおよび開発プロセスでのみ適用されます。 ご存じのとおり、Microsoft AzureはPaaSとIaaSの2つのアプリケーション展開メカニズムをサポートしています。 Web配置バリアントは、PaaSの一部として実行されます。 一般的に、Visual Studioからのアプリケーションの公開メカニズムは次のとおりです。
- すべての依存関係を持つアプリケーションを構築する
- アーカイブ
- Azure Storageにアップロードする
- イメージから仮想マシンを展開する
- Azure Storageから仮想マシンディスクにアーカイブをコピーする
- アーカイブの解凍
- IISセットアップ
開発チームのメンバーが新しい機能を積極的に導入しており、その一部はすでにテスターが確認できているとします。 完全な展開プロセスには多くの時間がかかるため、いくつかの小さな変更のため、毎回実行する必要はありません。 この場合、WebDeployメカニズムを使用できます。 そのスキームを以下に示します。
このメカニズムは次のように機能します。 アプリケーションのバージョン1.0を実行している仮想マシンがすでにあるとします。 かなり小さな変更が加えられた1.0.1に更新する必要があるため、変更のデルタ（アーカイブサイズ）は小さくなります。 この場合、Web Deployはプロジェクトを（自然に）ビルドし、変更されたファイルのみをアーカイブし、変更を含むアーカイブをAzure Storageにアップロードします。 その後、RDPプロトコル（仮想マシンの必須要件）を使用して、 動作中の仮想マシンに変更を加えたアーカイブをコピーします。 アーカイブが解凍され、IISディレクトリ内の変更されたファイルの置換があります。 その後、IISが再起動します。
このアプローチの長所と短所を見てみましょう。
長所：
- アプリケーションの新しいバージョンの展開時間を短縮します
- 小さなサイズの変更
- Visual Studioから直接公開する
短所：
- マシンがリサイクルされる場合、Web配置プロセス中に行われた変更は、元のアーカイブ（パッケージ、.cspkg）には入りません。
- Webロールのみがサポートされています。 ワーカーロールはサポートされていません
- 仮想マシンへのRDP接続が前提条件です
- クラウドサービスごとに1つの仮想マシンのみがサポートされます（クラウドサービス）
- この方法は、PaaS展開にのみ適用できます。
ご覧のとおり、この方法は生産と見なすことはほとんどできませんが、独自の利点もあるため、生命の権利があります。
VIPスワップ
PaaS展開の一環として、引き続きアプリケーションのアップグレードオプションを検討します。 前のバージョンとは異なり、次のアプローチは非常に適用可能で、実稼働環境に適用されます。
顧客が（contoso.cloudapp.net）でアプリケーションバージョン1.0を使用するとします。 私たちのタスクは、ユーザーに見えないようにアプリケーションのバージョンを1.1に更新することです。
Microsoft Azureは、クラウドサービスのスロットという便利な概念を提供します。 Visual Studioを介してクラウドにアプリケーションを公開するとき、アプリケーションを公開するスロット（ステージングまたはプロダクション）を常に尋ねられます。
したがって、これらのスロットの違いは、実稼働スロットに特定の名前（test-app-1.cloudapp.netのテスト）に関連付けられたDNSがあり、ステージングにはGUID.cloudapp.netという形式の名前があることだけです。 したがって、同じアプリケーションの複数のバージョンを1つのクラウドサービスに同時に保持できます。 上で述べたように、顧客は実稼働スロットを使用し、リリース用の環境のテストまたは準備にステージングを使用できます。
クラウドサービスを作成するとき、Azureの内部ロードバランサーは特定のDNS名に関連付けられたIPアドレスのテーブルを作成します。 VIPスワップのアイデアは非常にシンプルです。ステージングスロットに関連付けられているマシンのIPアドレスを、実稼働スロットに関連付けられているマシンのIPアドレスに置き換えます。 Azure Load Balancerの内部IPアドレステーブルの更新操作には数秒かかります。 したがって、ユーザーの観点からは、アプリケーションを新しいバージョンにすぐに更新します。
このアプローチの長所と短所を見てみましょう。
長所：
- ロードバランサーテーブルのIPアドレスの変更には数秒かかります
- テスト環境と本番環境は互いに分離されています
- 必要に応じて、「すべてを戻す」可能性があります（反対方向に交換）
- Webロールとワーカーの両方のサポート
- Visual Studioから直接展開する
短所：
- ステージングスロットとプロダクションスロットの仮想マシンの構成は同じである必要があります
- IaaSで展開された仮想マシンのサポートなし
- パラレルスロットにデプロイされた仮想マシンの追加コスト
この更新方法を分析すると、実稼働環境での使用に非常に適していることがわかります。 アプリケーションの展開にPaaSアプローチを使用する場合、これは最も最適な方法の1つです。
今日は、これが私があなたに伝えたかったことのすべてです。 次回は、IaaSの一部としてデプロイされたアプリケーションをアップグレードするために使用できるMicrosoft Azureツールを確認します。 切り替えないでください！