IISの*すべての* HTTP / HTTPSリクエストを一時的に「サーバーメンテナンス」ページにリダイレクトする


10

数百の個別のWebアプリをホストするIISサーバーがあり、これらのアプリをホストする物理データベースサーバーは、メンテナンスのために短期間オフラインになります(所要時間は15分未満です)。

その期間中は、どのWebサイトについても、すべてのトラフィックを「現在メンテナンス中」のページにリダイレクトします。

すべてのWebアプリにアクセスし、そのアプリ内のすべてのリクエストに対してユーザーを別のページに送信するIIS書き換えルールを設定することで、これを実行できることがわかりました。しかし、それを行うには、データベースのメンテナンスを行うよりも時間がかかります!

私は3つのことを試しましたが、どれもうまくいきませんでした。

グローバルIIS書き換えルール

私はすべてのサイトにルールを一度に適用する簡単な方法を探していました。それから、同じように痛みのない手順でそのルールを「元に戻す」ことができます。これまでのところ、私の試みはどれもうまくいきませんでした。この書き換えルールをW:\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config \ web.configにあるグローバルweb.configに入れてみました。

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="redirect all requests" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                    <conditions logicalGrouping="MatchAll">
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" pattern="" ignoreCase="false" />
                    </conditions>
                    <action type="Redirect" url="http://www.somedomain.com/maintenance" appendQueryString="true" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

これはうまくいきませんでした。IISでは64ビットの.NET 4.0を実行していますが、「念のため」に32ビットと2.0のグローバルweb.configファイルに同じものを配置しましたが、変更はありません。

App_Offline.htm "スペシャルファイル"

私が見たもう1つの提案はapp_offline.htmの「特別な」ファイルですが、このファイルをすべてのアプリのアプリルートにデプロイするのに実際にメンテナンスを行うよりも時間がかかるという同じ問題に戻ります。

IISの「オフライン」サイト

すべてのサイトは、単一のIPを使用してIISで設定されています。これは、すべてのアプリが単一のSSL証明書(UCC)を共有するため、SNAがなくても機能します。私に発生したことの1つは、IISで、使用しているIPへのすべてのトラフィックに一致するサイトをセットアップでき、ホストヘッダーの値を指定しなかったことです。より高い「優先順位」を与えることができ、他のサイトが一致する前に、開始時にすべてのトラフィックがそのIPに一致することが期待されました。リクエストURLに関係なく、すべてのリクエストに対して同じページを提供するようにそのサイトを設定できます。

メンテナンス中はそのサイトを開始し、終了したら停止します。

しかし、IISはHTTPリクエストをより具体的なサイトよりも具体的なサイトに一致させるように見えるため、これも機能させることができませんでした。したがって、この「オフラインであることをユーザーに伝える」サイトのホストヘッダー値を省略すると、リクエストに別のサイトと一致するホストヘッダー値がない場合を除いて、一致しませんでした。これにより、各Webアプリに手動でアクセスしてオフラインにするアクションを実行し、メンテナンスが完了したらオンラインに戻すという同じ問題に戻ることができます。

これを達成する簡単な方法はありますか?私たちがこの問題に遭遇するのは最初ではないようです。

-ジョシュ


1つのオプションは、Apacheまたは別のWebサーバーのインスタンスをインストールして、それに申し訳ありませんサイトをセットアップすることです。次に、時間が来たら、IISを停止してApacheを起動し、すべての要求を処理します。
フィーバス2013年

私たちが一般的にこれを行う方法は、サーバーの前のデバイス(ロードバランサーなど)に申し訳ありませんページを表示することです。
フェーバス2013年

回答:


6

私はあなたの第三のアプローチとなるだろう"We're offline" Site in IISあなたはそれを名前の言う、Offlineそれはホストヘッダーは、それが一致するホストヘッダーを持っている他のサイトのいずれかによって拾わないすべての要求にサービスを提供します指定されていない場合、。これを防ぐには、他のすべてのサイトを停止するだけです。

IISスクリプトがインストールされていると仮定して、管理者特権のPowerShellを開きます。

import-module webadministration

これで、オフラインサイトを除くすべてのサイトを停止できます。

Get-ChildItem IIS:\Sites | Where {$_.Name -ne "Offline"} | Stop-WebSite

SQL-Serverがバックアップされたら、それらを再度起動します。

Get-ChildItem IIS:\Sites | Where {$_.Name -ne "Offline"} | Start-WebSite

FTPサイトもある場合、FTPサイトをStop-WebSiteコマンドレットにパイプできないため、コマンドはエラーを表示しますが、すべてのWebサイトで引き続き機能します。

通常は実行されないサイトがある場合は、次のように2番目のコマンドでそれらを除外する必要があります。

Where {$_.Name -ne "Offline" -and $_.Name -ne "foobar.com"}

IIS用のPowerShellコマンドレットがインストールされていない場合は、appcmd.exeを使用して同じことを行うことができますが、私は何年も使用していません。


2

すべてのサイトは、単一のIPを使用してIISで設定されています。

1)古いデスクトップを取得し、ライブLinuxディストリビューションを実行し、IISボックスと同じIPを与えます。ネットワークに接続しないでください。

2)ライブLinuxボックスでnginxを起動し、好きなようにダウンタイムページを作成し、ラップトップに接続されたオフラインスイッチ/ハブを使用してテストします

3)IISボックスのイーサネットケーブルを取り外し、ライブのLinuxボックスに接続します。

4)スイッチ(またはロール電源)のMACアドレスキャッシュをクリアします。ダウンタイムサイトが稼働しています。


0

Apacheをインストールし、次のように仮想ホストを作成しますpath\to\apache\conf\extra\httpd-vhosts.conf

<VirtualHost *:80>
    DocumentRoot C:/Apache/htdocs
    ServerName anyname.net

    # Other directives here
</VirtualHost>

次に、上記の設定で指定したドキュメントルートで、オフラインメッセージを含むindex.htmlファイルを作成します。

次の手順は非常に重要です。Apacheを実行する前に、ポート80を使用する可能性のあるすべてのサービスを停止する必要があります。あなたはこのリンクでそれらの大多数のリストを見つけるかもしれません


0

これは古いことはわかっていますが、古いWindows 2008 r2ボックスでこれを実行する必要がありました。これは、質問のタイトルに対する回答です。質問の詳細については、「IISでオフラインサイト」設定するための1つの方法にすぎません

これは、IISと静的HTML以外には依存しません。IISの「HTTPリダイレクト」機能は必要なものを処理しませんが、それをシミュレートする別の方法があります。サイトのすべての「エラーページ」を変更して、メンテナンスページを指定するだけです。はい、これはIISで「サイト」全体を使用できる場合にのみ機能します。

私の場合、サイトのルートフォルダ(c:\ InetPub \ wwwrootなど)には "default.htm"ファイルが1つあります。したがって、すべての「エラーページ」は「このサイトでURLを実行する」ように設定され、パス「/default.htm」を使用します。ファイルでは絶対URL(「/」で始まる)を使用しているため、パブリックURLがどのように表示されても、そのコンテンツはブラウザーで正しく実行されます。

この構成の最終結果は、サイトへのすべて/すべてのリクエストが私のメンテナンスページのコンテンツを提供することです。リクエストが何であるかは関係ありません。

また、IISはルートフォルダーにweb.configファイルを生成することにより、この変更に影響を与えることに注意してください。これは私のために作成したものです:

 <?xml version="1.0" encoding="UTF-8"?>
 <configuration>
     <system.webServer>
         <httpErrors>
             <remove statusCode="502" subStatusCode="-1" />
             <remove statusCode="501" subStatusCode="-1" />
             <remove statusCode="500" subStatusCode="-1" />
             <remove statusCode="412" subStatusCode="-1" />
             <remove statusCode="406" subStatusCode="-1" />
             <remove statusCode="405" subStatusCode="-1" />
             <remove statusCode="404" subStatusCode="-1" />
             <remove statusCode="403" subStatusCode="-1" />
             <remove statusCode="401" subStatusCode="-1" />
             <error statusCode="401" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="403" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="404" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="405" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="406" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="412" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="500" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="501" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
             <error statusCode="502" prefixLanguageFilePath="" path="/default.htm" responseMode="ExecuteURL" />
         </httpErrors>
     </system.webServer>
 </configuration>
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.