適切な Web 配置手法を選択する
作成者: Jason Lee
インターネット インフォメーション サービス (IIS) Web 配置ツール (Web 配置) 2.0 以降を使用する場合、パッケージ化された Web アプリケーションを Web サーバーに配置するために使用できる 3 つの主要なアプローチがあります。 次のいずれかを実行できます。
- 宛先サーバー上の "Web 配置エージェント サービス" ("リモート エージェント" とも呼ばれます) をターゲットにして、リモートの場所からアプリケーションを配置します。
- Web 配置オンデマンド ("一時エージェント" とも呼ばれます) を使用して、リモートの場所からアプリケーションを配置します。
- 宛先サーバー上の "IIS Web 配置ハンドラー"をターゲットにして、リモートの場所からアプリケーションを配置します。
- Web パッケージを宛先サーバーに手動でコピーし、IIS マネージャーを使用してインポートして、アプリケーションを配置します。
宛先 Web サーバーを構成する方法は、使用する配置手法によって異なります。 このトピックは、適切な配置手法を決定するのに役立ちます。
次の表は、各配置アプローチの主な長所と短所、および各アプローチに通常最も適したシナリオを示しています。
| アプローチ | 長所 | 短所 | 標準のシナリオ |
|---|---|---|---|
| リモート エージェント | 設定は簡単です。 Web アプリケーションとコンテンツの定期的な更新に適しています。 | ユーザーは、ターゲット サーバーの管理者である必要があります。 ユーザーは代替資格情報を指定できません。 | 開発環境。 テスト環境。 |
| 一時エージェント | ターゲット コンピューターに Web 配置をインストールする必要はありません。 最新バージョンの Web 配置が自動的に使用されます。 | ユーザーは、ターゲット サーバーの管理者である必要があります。 ユーザーは代替資格情報を指定できません。 | 開発環境。 テスト環境。 |
| Web 配置ハンドラー | 管理者以外のユーザーもコンテンツを配置できます。 Web アプリケーションとコンテンツの定期的な更新に適しています。 | 設定ははるかに複雑です。 | ステージング環境。 イントラネット運用環境。 ホステッド環境。 |
| オフライン配置 | 設定は非常に簡単です。 分離された環境に適しています。 | サーバー管理者は、Web パッケージを毎回手動でコピーしてインポートする必要があります。 | インターネットに接続された運用環境。 分離されたネットワーク環境。 |
リモート エージェントの使用
既定の設定を使用して Web 配置を宛先サーバーにインストールすると、Web 配置エージェント サービス ("リモート エージェント") が自動的にインストールされて、開始されます。 既定では、リモート エージェントは、以下のアドレスで HTTP エンドポイントを公開します。
http://[server]/MSDEPLOYAGENTSERVICE
Note
[server] は、Web サーバーのマシン名、Web サーバーの IP アドレス、または Web サーバーに解決されるホスト名に置き換えることができます。
サーバー管理者は、このエンドポイント アドレスを指定することで、開発者用マシンやビルド サーバーなどのリモートの場所から Web パッケージを配置できます。 たとえば、Fabrikam, Inc. の Matt Hink 氏が、開発者用マシンに ContactManager.Mvc Web アプリケーション プロジェクトをビルドしたとします。 ビルド プロセスでは、パッケージのインストールに必要な Web 配置コマンドを含む .deploy.cmd ファイルとともに、Web パッケージが生成されます。 Matt が TESTWEB1 サーバーのサーバー管理者である場合は、開発者用マシンで以下のコマンドを実行することで、Web アプリケーションをテスト Web サーバーに配置できます。
ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM
実際には、マシン名を指定した場合、Web 配置実行可能ファイルはリモート エージェントのエンドポイント アドレスを推測できるため、Matt は次のように入力するだけで済みます。
ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /a:NTLM
Note
Web 配置コマンド ライン構文と .deploy.cmd ファイルの詳細については、「方法: deploy.cmd ファイルを使用して配置パッケージをインストールする」を参照してください。
リモート エージェントにより、リモートの場所からコンテンツを配置する簡単な方法が提供されます。この方法は、ワンクリックまたは自動配置によって適切に機能します。 ただし、配置コマンドを実行するユーザーは、ドメイン管理者、または宛先サーバーのローカル管理者グループのメンバーのいずれかである必要もあります。 さらに、リモート エージェントは基本認証をサポートしていないため、コマンド ラインで代替資格情報を渡すことはできません。
リモート エージェントは、開発またはテストのシナリオにおける配置に役立つアプローチを提供します。これらのシナリオでは、開発者がテスト サーバー環境に対する完全な管理者制御を持っていることは珍しくなく、アプリケーションは通常、非常に頻繁に再構築され、再配置されます。 ただし、このアプローチは通常、ステージング環境や運用環境ではあまり許容されません。
リモート エージェントのアプローチを使用するシナリオのエンド ツー エンドの例については、「シナリオ: Web 配置のテスト環境を構成する」を参照してください。
一時エージェントの使用
配置に対する一時エージェントのアプローチは、リモート エージェントのアプローチと似ています。 ただし、リモート エージェントのアプローチとは異なり、Web 配置を宛先 Web サーバーにインストールする必要はありません。 代わりに、配置を実行すると、Web 配置は、Web 配置エージェント サービスの一時的なバージョンを宛先サーバーにインストールし、これを使用してコンテンツを IIS に配置します。 配置が完了すると、すべての一時ファイルが削除されます。
一時エージェント プロバイダー設定を使用する場合は、次のように、配置コマンドに /g のフラグを追加します。
ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /g:true
Note
Web 配置エージェント サービスが宛先コンピューターにインストールされている場合、そのサービスが実行されていない場合でも、一時エージェントは使用できません。
この方法の利点は、宛先サーバーで Web 配置のインストールを管理する必要がないということです。 さらに、ソースと宛先のコンピューターで同じバージョンの Web 配置が実行されていることを確認する必要もありません。 ただし、このアプローチでは、リモート エージェントのアプローチと同じプリンシパルの制限が適用されます。つまり、コンテンツを配置するには、宛先サーバーのローカル管理者である必要があり、また、NTLM 認証のみサポートされています。 一時エージェントのアプローチでは、配置先環境の初期構成もさらに多く必要になります。
一時エージェントの使用に関する詳細については、「方法: deploy.cmd ファイルを使用して配置パッケージをインストールする」および「Web 配置オン デマンド」を参照してください。
Web 配置ハンドラーの使用
IIS 7 以降では、Web 配置は IIS Web 配置ハンドラーを使用した代替の配置手法を提供します。 Web 配置ハンドラーは、ユーザーがリモートの場所から IIS Web サイトを管理できるように設計された IIS Web 管理サービス (WMSvc) と密接に統合されています。
既定では、リモート エージェントは、以下のアドレスで HTTP エンドポイントを公開します。
https://[server]:8172/MSDeploy.axd
Note
[server] は、Web サーバーのマシン名、Web サーバーの IP アドレス、または Web サーバーに解決されるホスト名に置き換えることができます。
リモート エージェントと一時エージェントと比較したときの Web 配置ハンドラーの大きな利点は、管理者以外のユーザーがアプリケーションとコンテンツを特定の IIS Web サイトに配置できるように IIS を構成可能なことです。 Web 配置ハンドラーでは基本認証もサポートされているため、代替資格情報を Web 配置コマンドのパラメーターとして指定できます。 主な欠点は、Web 配置ハンドラーの設定と構成が最初はかなり複雑であるということです。
非管理者ユーザーの場合、Web 管理サービス (WMSvc) により、ユーザーはサーバー レベルの接続ではなく、サイト レベルの接続を使用して IIS に接続することのみ許可されます。 特定のサイトにアクセスするために、次のように、サイト固有のクエリ文字列をエンドポイント アドレスに含めることができます。
https://[server]:8172/MSDeploy.axd?site=DemoSite
たとえば、ビルドが成功するたびにステージング環境に Web アプリケーションを自動的に配置するようにビルド プロセスが構成されているとします。 リモート エージェントのアプローチを使用した場合は、ビルド プロセス ID を宛先サーバーの管理者にする必要があります。 これに対し、Web 配置ハンドラーのアプローチを使用すると、管理者以外のユーザー (この場合は、FABRIKAM\stagingdeployer) に特定の IIS Web サイトのみへのアクセス許可を付与できます。また、ビルド プロセスは、Web パッケージを配置するためにこれらの資格情報を提供できます。 次の例では、%ContactManagerPublishPassword% を使用しており、パスワード値を環境変数からプルしていることに注意してください。 スクリプトを正常に実行するには、%ContactManagerPublishPassword% 変数を正しい値で定義する必要があります。
msdeploy.exe
-source:package='…\ContactManager.Mvc.zip'
-dest:auto,
computerName='https://STAGEWEB1:8172/MSDeploy.axd?site=DemoSite',
userName='FABRIKAM\stagingdeployer',
password=%ContactManagerPublishPassword%,
authtype='Basic',
-verb:sync
-setParamFile:"…\ContactManager.Mvc.SetParameters.xml"
-allowUntrusted
Note
Web 配置のコマンド ライン操作と構文の詳細については、「Web 配置コマンド ライン リファレンス」を参照してください。 .deploy.cmd ファイルの使用方法の詳細については、「方法: deploy.cmd ファイルを使用して配置パッケージをインストールする」を参照してください。
Web 配置ハンドラーは、ステージング環境、ホステッド環境、イントラネット ベースの運用環境での配置に役立つアプローチを提供します。これらの環境では、サーバーへのリモート アクセスは利用可能ですが、管理者の資格情報は使用できません。
Web 配置ハンドラーのアプローチを使用するシナリオのエンド ツー エンドの例については、「シナリオ: Web 配置のステージング環境を構成する」を参照してください。
オフライン配置の使用
場合によっては、リモートの場所から IIS Web サイトにアプリケーションとコンテンツを配置することが不可能だったり、現実的でなかったりすることがあります。 たとえば、ソースと宛先のコンピューターが分離されたネットワークやネットワーク セグメントにある場合や、ファイアウォール ポリシーでリモート アクセスが許可されない場合などがあります。
このようなシナリオでは、Web 配置のパッケージ化と発行の機能を引き続き使用できますが、リモートの場所からそれらを使用することはできません。 代わりに、宛先サーバーの管理者は、Web パッケージをサーバーにコピーして、IIS マネージャーを使用してそれをインポートする必要があります。
オフライン配置のアプローチは、通常、境界ネットワーク内のサーバーが内部ネットワーク内のコンピューターとの接続を制限している可能性がある、インターネットに接続する運用環境で役立ちます。
オフライン配置のアプローチを使用するシナリオのエンド ツー エンドの例については、「シナリオ: Web 配置の運用環境を構成する」を参照してください。
もっと読む
Web 配置のコマンド ライン操作と構文の詳細については、「Web 配置コマンド ライン リファレンス」を参照してください。 .deploy.cmd ファイルの使用方法の詳細については、「方法: deploy.cmd ファイルを使用して配置パッケージをインストールする」を参照してください。
リモート コンピューターから Web パッケージを配置するためのさまざまな方法に関する一般的なガイダンスについては、「Web 配置をリモートで使用する」を参照してください。 Web 配置オンデマンドの使用に関する詳細については、「Web 配置オンデマンド」を参照してください。