適切な Web 配置手法を選択する

作成者: Jason Lee

インターネット インフォメーション サービス (IIS) Web 展開ツール (Web 配置) 2.0 以降を使用する場合、パッケージ化された Web アプリケーションを Web サーバーに取得するために使用できる 3 つのメインアプローチがあります。 次のいずれかを実行できます。

• ターゲット サーバー上の Web Deployment Agent サービス ("リモート エージェント" とも呼ばれます) をターゲットにして、リモートの場所からアプリケーションをデプロイします。
• Web Deploy On Demand ("一時エージェント" とも呼ばれます) を使用して、リモートの場所からアプリケーションをデプロイします。
• ターゲット サーバー上の IIS Web 配置ハンドラー をターゲットにして、リモートの場所からアプリケーションを展開します。
• Web パッケージをコピー先サーバーに手動でコピーし、IIS マネージャーを使用してインポートして、アプリケーションを展開します。

移行先の Web サーバーを構成する方法は、使用する展開方法によって異なります。 このトピックは、デプロイに適したアプローチを決定するのに役立ちます。

次の表は、各デプロイ アプローチのメインの長所と短所と、各アプローチに最も一般的に適したシナリオを示しています。

アプローチ	長所	短所	標準のシナリオ
リモート エージェント	設定は簡単です。 Web アプリケーションとコンテンツの定期的な更新に適しています。	ユーザーは、ターゲット サーバーの管理者である必要があります。 ユーザーは代替の資格情報を指定できません。	開発環境。 テスト環境。
一時エージェント	ターゲット コンピューターに Web 配置をインストールする必要はありません。 最新バージョンの Web 配置が自動的に使用されます。	ユーザーは、ターゲット サーバーの管理者である必要があります。 ユーザーは代替資格情報を指定できません。	開発環境。 テスト環境。
Web 配置ハンドラー	管理者以外のユーザーはコンテンツを展開できます。 Web アプリケーションとコンテンツの定期的な更新に適しています。	設定ははるかに複雑です。	ステージング環境。 イントラネットの運用環境。 ホストされている環境。
オフライン展開	セットアップは非常に簡単です。 分離された環境に適しています。	サーバー管理者は、Web パッケージを毎回手動でコピーしてインポートする必要があります。	インターネットに接続された運用環境。 分離されたネットワーク環境。

リモート エージェントの使用

既定の設定を使用して Web 配置を移行先サーバーにインストールすると、Web Deployment Agent サービス ("リモート エージェント") が自動的にインストールされて開始されます。 既定では、リモート エージェントはこのアドレスで 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 認証のみがサポートされます。 一時エージェントのアプローチでは、移行先環境の初期構成がさらに多く必要になります。

一時エージェントの使用方法の詳細については、「 How to: Install a Deployment Package Using the deploy.cmd File and Web Deploy On Demand」を参照してください。

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 Deploy On Demand の使用の詳細については、「 Web Deploy On Demand」を参照してください。

前へ次へ