13

ユーザーに手間をかけずに.NETWebアプリケーションをIIS（7.5）に展開しようとしています。Disable Overlapped RecycleがFalseであることを確認しましたが、それでも毎回同じ問題が発生します。

サイトに新しいバイナリをアップロードするたびに、IISは新しいバイナリを開始する前にワーカープロセスを強制終了します。したがって、新しいバイナリをアップロードするたびに、ユーザーは次のエラーメッセージを受け取ります。

'/'アプリケーションのサーバーエラー。ファイルまたはアセンブリ'MyApplicationWeb'またはその依存関係の1つを読み込めませんでした。別のプロセスによって使用されているため、プロセスはファイルにアクセスできません。（HRESULTからの例外：0x80070020）

これをシームレスに行う方法がわかりません。今はバイナリをアップロードするだけです。ただし、アップロード（またはローカルコピー）が発生している間は、上記の動作が得られます。Webガーデンも使ってみましたが、同じ結果になりました。

私が探していないもの：

  • 外部ロードバランサーを使用して解決する方法（これは機能的なソリューションですが、パフォーマンス的には少数のサーバーにとっては悪いソリューションであり、サーバーが1つしかない場合はまったく機能しません）
  • カスタムエラーページを更新してハックアラウンドを作成する方法（明らかな問題がいくつかありますが、さらに重要なことに、Webサービス/ ajaxではまったく機能しません）。

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/24e3c22e-79a9-4f07-a407-dbd0e7f35432.mspx?mfr=trueを考えると、これは実行可能であると本当に思います。

更新：上記の記事で彼らは言う：

ただし、シャットダウンまたはスタートアップのシャットダウンタイムアウト値は構成可能であるため、制限時間内に既存の要求の処理が完了しない場合は、要求の処理中にワーカープロセスを終了できます。

この値がどこにあるのか、デフォルトが何なのかわかりません。それが数秒未満の場合、それは私の結果を説明するかもしれません。

ps。SF /ウェブマスターなどではなく、SOに投稿しているのは、開発に積極的でない人の間では、この種の知識はおそらく最小限になると思うので、これで大丈夫だと思います。

4

5 に答える 5

17

ASP.Netアプリケーションを展開するとき、サーバー上に新しいフォルダーを作成し、IIS内のWebサイトのホームディレクトリを変更します。これにより、ダウンタイムの展開がゼロになり、予期しない問題が発生した場合の迅速なロールバック位置が提供されます。将来の更新では、古いバージョンを廃棄してプロセスを繰り返し、常に単一のロールバック位置が存在するようにします。

更新-シャットダウンの制限時間

ワーカーのシャットダウン時間制限の構成の詳細については、http： //www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/processModelを参照してください。デフォルトは1分30秒です。リンク先のページでshutdownTimeLimitセクションを探します。

更新-詳細情報

素晴らしい答えのある同様の質問

この要点は、既存のファイルを上書きするため、コピーメカニズムがファイルを排他的にロックし、app_offline.htmまたは上記のようなメカニズムを使用せずに見かけのない展開を行うことはできないということです。リンクされた回答を読んで、さらに深く掘り下げてください。

于 2011-03-18T21:49:19.250 に答える
4

2番目のフォルダーを更新し、IISホームディレクトリを変更して他のフォルダーを指すようにするというSmirkinの応答に同意します。これのもう1つの利点は、ロールバックパスが簡単なことです（IISホームディレクトリを元に戻すだけです）。

Powershellを使用してこれを行う方法についてのスクリプトを含む投稿を作成しました-それが役立つことを願っています：http：//davidduffett.net/post/4833657659/blue-green-deployment-to-iis-with-powershell

このスクリプトは、継続的インテグレーションシステムから直接使用できるはずです。

于 2011-04-22T16:45:13.843 に答える
3

Smirkinの回答は、管理者がダウンタイムをほとんどまたはまったく発生させずにサイトをデプロイするための優れたシームレスな方法を提供しますが、コードベースに重大な変更がある場合（つまり、古いページの削除、フォームなど）、この方法を使用すると、切り替え前にプロセスを開始し、切り替え後にプロセスを完了する（つまり、切り替え前にページを要求し、入力を開始する）ユーザーにとっては「面倒」になる可能性があります。 、新しいディレクトリに切り替えた後、ページを送信します）。

私に言わせたくないのはわかっていますが、Sticky-Sessionsが有効になっているロードバランサーがないと、新しいバージョンの処理を終了するまで、古いバージョンのサイトを引き続き使用することはできません。新しいバージョンでのセッション-アプリケーションのホームディレクトリを変更することにより、IISはアプリの再コンパイルを実行し、プロセスを再起動します。このようにして、現在の接続を引き続き提供するように古いサーバーを設定できますが、新しい接続をサーバーに送信しないように負荷分散に指示します。

ただし、これによく見られる問題を軽減するために実行できる別の手順があります。

MachineKeyをではなく定数値に構成しAutoGenerateます。これは、AppPoolがリサイクルされるときに同じキーを使用するため、セッションCookie、ビューステートなどを復号化できることを意味します。

于 2011-03-22T17:06:28.423 に答える
2

私の推測では、ウイルススキャナーまたは他の種類のインデックス作成プロセスがあり、ファイルをコピーするとすぐにファイルがロックされます。

于 2011-03-18T21:43:07.037 に答える
-2

app_offline.htmを使用できます

このソリューションはシームレスではありませんが、

<meta http-equiv="refresh" content="5" />

htmファイル内にあるため、ブラウザはjavascriptなしで自動的に更新します。

乾杯

于 2011-03-22T17:11:11.440 に答える