ウェブサイトの新しいバージョンを展開するには、次のことを行います。
このプロセスはすべてスクリプト化されており、非常に迅速に行われますが、古いファイルが削除され、新しいファイルが展開されるときに、10 ～ 20 秒のダウンタイムが発生する可能性があります。
ダウンタイム 0 秒の方法に関する提案はありますか?
2 つのサーバーとロード バランサーが必要です。手順は次のとおりです。
この場合でも、「スティッキー セッション」を使用している場合は、アプリケーションの再起動とセッションの損失が発生します。データベース セッションまたは状態サーバーがある場合は、すべて問題ありません。
Microsoft Web Deployment Toolは、これをある程度サポートしています。
Windows トランザクション ファイル システム (TxF) のサポートを有効にします。TxF サポートが有効になっている場合、ファイル操作はアトミックです。つまり、完全に成功するか失敗するかのどちらかです。これにより、データの整合性が保証され、データやファイルが「途中」または破損した状態で存在することが防止されます。MS Deploy では、TxF はデフォルトで無効になっています。
トランザクションは同期全体のようです。また、TxF は Windows Server 2008 の機能であるため、このトランザクション機能は以前のバージョンでは機能しません。
フォルダーをバージョンとして使用し、IIS メタベースを使用して、スクリプトをダウンタイム 0 に変更することは可能だと思います。
この方法には、次の利点があります。
異なるポート上の 2 つのローカル IIS サイト間のソフトウェア ロード バランサーとして IIS のアプリケーション リクエスト ルーティングを利用することにより、単一サーバー上でゼロ ダウンタイムの展開を実現できます。これは、ブルー グリーン デプロイ戦略として知られており、ロード バランサーで常に 2 つのサイトのうち 1 つだけを使用できます。「ダウン」しているサイトにデプロイし、ウォームアップしてロード バランサーに取り込み (通常はアプリケーション リクエスト ルーティングのヘルス チェックに合格することにより)、その後、「プール」からアップしていた元のサイトを取得します (再びヘルスチェックを失敗させることによって)。
私は最近これを経験し、私が思いついた解決策は、IIS で 2 つのサイトをセットアップし、それらを切り替えることでした。
私の構成では、A サイトと B サイトごとに次のような Web ディレクトリがありました。 c:\Intranet\Live A\Interface c:\Intranet\Live B\Interface
IIS には、2 つの同一のサイト (同じポート、認証など) があり、それぞれに独自のアプリケーション プールがあります。サイトの 1 つが実行されており (A)、もう 1 つのサイトが停止しています (B)。ライブのものにはライブホストヘッダーもあります。
ライブに展開するときは、STOPPED サイトの場所に公開するだけです。ポートを使用して B サイトにアクセスできるため、最初のユーザーがアプリケーションを起動しないように、サイトを事前にウォームアップできます。次に、バッチ ファイルを使用してライブ ホスト ヘッダーを B にコピーし、A を停止して B を開始します。
Microsoft.Web.Administration の ServerManager クラスを使用して、独自の展開エージェントを開発できます。
秘訣は、VirtualDirectory の PhysicalPath を変更することです。これにより、古い Web アプリと新しい Web アプリの間でオンラインのアトミック スイッチが発生します。
これにより、古い AppDomain と新しい AppDomain が並行して実行される可能性があることに注意してください。
問題は、データベースなどへの変更を同期する方法です。
古いまたは新しい PhysicalPath を持つ AppDomain の存在をポーリングすることにより、古い AppDomain がいつ終了したか、および新しい AppDomain が起動したかどうかを検出できます。
AppDomain を強制的に開始するには、HTTP 要求を行う必要があります (IIS 7.5 は自動開始機能をサポートしています)。
ここで、新しい AppDomain の要求をブロックする方法が必要です。名前付きミューテックスを使用します。これは、配置エージェントによって作成および所有され、新しい Web アプリの Application_Start によって待機され、データベースの更新が行われると配置エージェントによって解放されます。
(Web アプリでマーカー ファイルを使用してミューテックス待機動作を有効にします) 新しい Web アプリが実行されたら、マーカー ファイルを削除します。
OK、2008年に私が書いた答えに誰もが反対票を投じているので* ...
2014 年の現在の方法について説明します。現在 ASP.NET MVC を使用しているため、Web サイトを使用しなくなりました。
ロード バランサーと 2 台のサーバーが必要なわけではありません。維持しているすべての Web サイトに 3 台のサーバーがある場合は問題ありませんが、ほとんどの Web サイトでは完全にやり過ぎです。
また、Microsoft の最新のウィザードには依存していません。遅すぎて、隠された魔法が多すぎて、名前を変更しがちです。
方法は次のとおりです。
生成された DLL を「bin-pub」フォルダーにコピーするビルド後のステップがあります。
Beyond Compare (優れている**) を使用して、変更されたファイルを検証し、本番サーバーまで (FTP は広くサポートされているため、FTP 経由で) 同期します。
ウェブサイトには、「bin-pub」のすべてを「bin」にコピーするボタンを含む安全な URL があります (迅速なロールバックを可能にするために最初にバックアップを取ります)。この時点で、アプリは自動的に再起動します。次に、ORM は、追加する必要があるテーブルまたは列があるかどうかを確認し、それらを作成します。
それはわずか数ミリ秒のダウンタイムです。アプリの再起動には 1 ～ 2 秒かかる場合がありますが、再起動中はリクエストがバッファリングされるため、実質的にダウンタイムはゼロになります。
デプロイ プロセス全体は、変更されたファイルの数と確認する変更の数に応じて、5 秒から 30 分かかります。
この方法では、Web サイト全体を別のディレクトリにコピーする必要はなく、bin フォルダーだけをコピーする必要があります。また、プロセスを完全に制御でき、何が変化しているかを正確に把握できます。
**私たちは常に、展開している変更をすばやく確認します - 土壇場での再確認として、何をテストすればよいかを把握し、問題があればすぐに対応できるようにします。FTP 経由でファイルを簡単に比較できるため、Beyond Compare を使用します。私は BC なしでは決してこれを行いません。何を上書きしているのかわかりません。
*一番下までスクロールして確認してください :( ところで、Web サイトは構築に時間がかかり、半分コンパイルされた一時ファイルでひどくクラッシュする可能性があるため、Web サイトはお勧めしません。ファイル単位でより機敏に処理できるため、以前は Web サイトを使用していました。マイナーな問題を非常に迅速に修正し、デプロイしているものを正確に確認できます (もちろん、Beyond Compare を使用している場合 - そうでない場合は忘れてください)。
私が考えることができる唯一のゼロ ダウンタイムの方法は、少なくとも 2 台のサーバーでホストすることです。
これは私がそれを行う方法です：
絶対最小システム要件:
1 台のサーバーと
ワークフロー:
トランザクション myupdate を開始
try
Web-Service: Tell all applications on all web-servers to go into primary read-only mode
Application switch to primary read-only mode, and responds
Web sockets begin notifying all clients
Wait for all applications to respond
wait (custom short interval)
Web-Service: Tell all applications on all web-servers to go into secondary read-only mode
Application switch to secondary read-only mode (data-entry fuse)
Updatedb - secondary read-only mode (switches database to read-only)
Web-Service: Create backup of database
Web-Service: Restore backup to new database
Web-Service: Update new database with new schema
Deploy new application to apt-repository
(for windows, you will have to write your own custom deployment web-service)
ssh into every machine in array_of_new_webapps
run apt-get update
then either
apt-get dist-upgrade
OR
apt-get install <packagename>
OR
apt-get install --only-upgrade <packagename>
depending on what you need
-- This deploys the new application to all new chroots (or servers/VMs)
Test: Test new application under test.domain.xxx
-- everything that fails should throw an exception here
commit myupdate;
Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
@client: notify of reload and that this causes loss of unsafed data, with option to abort
@ time x: Switch load balancer from array_of_old_webapps to array_of_new_webapps
Decomission/Recycle array_of_old_webapps, etc.
catch
rollback myupdate
switch to read-write mode
Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try
単一のサーバーについて、次のようにジョージの答えを少し改良します。
手順 4 により、IIS ワーカー プロセスがリサイクルされます。
InProc セッションを使用していない場合、ダウンタイムはゼロです。可能であれば、代わりに SQL モードを使用してください (さらに良いのは、セッション状態を完全に避けることです)。
もちろん、複数のサーバーやデータベースの変更がある場合は、もう少し複雑になります....
ある種のロードバランサー（または同じサーバー上の単なるスタンバイコピー）に依存していたsklivvzの回答を拡張するには
データベースのスナップショット/コピーを作成することで、スモーク テストを導入することは可能ですが、常に実行できるとは限りません。
可能で必要な場合は、異なるテナント URL (customerX.myapp.net) や異なるユーザーなどの「ルーティングの違い」を使用して、知らないモルモットのグループに最初に展開します。何も失敗しない場合は、全員にリリースします。
データベースの移行が伴うため、以前のバージョンにロールバックすることは多くの場合不可能です。
イベント キューや再生メカニズムを使用するなど、これらのシナリオでアプリケーションをより適切に再生する方法はありますが、使用中のものに変更をデプロイすることについて話しているため、絶対確実な方法はありません。
そこに古いファイルを保持し、単純に上書きすることをお勧めします。そうすれば、ダウンタイムは単一ファイルの上書き時間に制限され、一度に失われるファイルは 1 つだけになります。
ただし、これが「Web アプリケーション」に役立つかどうかはわかりません (それがあなたが使用しているものだと言っていると思います)。これが、私たちが常に「Web サイト」を使用する理由です。また、「Web サイト」をデプロイしても、サイトが再起動されず、すべてのユーザー セッションがドロップされません。