IIS 7.0 でのサイト、アプリケーション、および仮想ディレクトリについて

発行日 : 2007 年 11 月 23 日 (作業者 : saad(英語))
更新日 : 2008 年 3 月 13 日 (作業者 : saad(英語))

はじめに

IIS 7.0 でサイト、アプリケーション、および仮想ディレクトリを作成して、インターネット、イントラネット、またはエクストラネットを介してユーザーと情報を共有できます。この概念は IIS の以前のバージョンにもありましたが、IIS 7.0 での変更によって、この概念の定義および機能が影響を受けます。最も重要なのは、サイト、アプリケーション、および仮想ディレクトリが、オンライン コンテンツのホスティングおよびオンライン サービスのプロビジョニングを行うための基本的な構成要素として階層関係で共に機能するようになっていることです。

この記事では、IIS 6.0 のアプリケーションを概観し、IIS 7.0 で変更された点についての理解を深めます。次に、IIS 7.0 におけるサイト、アプリケーションおよび仮想ディレクトリの概念について説明し、構成の <sites> セクションについて解説します。

この記事には次のような内容が含まれています。

• IIS 6.0 でのサイト、アプリケーション、および仮想ディレクトリについて

• IIS 7.0 でのサイト、アプリケーション、および仮想ディレクトリについて

• サイト

• アプリケーション

• 仮想ディレクトリ

• IIS 7.0 の構成 :<sites> セクション

• まとめ

IIS 6.0 でのサイト、アプリケーション、および仮想ディレクトリについて

IIS 6.0 では、仮想ディレクトリの概念とアプリケーションの概念がわかりにくくなっていました。仮想ディレクトリとアプリケーションは別々の概念とされていました (そして機能の視点から見れば概念的に異なっていました) が、アプリケーションは、仮想ディレクトリから物理的に独立したオブジェクトではありませんでした。IIS 6.0 におけるアプリケーションは、プロパティ AppFriendlyName、AppRoot、AppIsolated、および AppPoolID の 1 つまたは組み合わせをメタベースに持つ仮想ディレクトリに過ぎませんでした。

注 : サイトのルートは例外で、これらのプロパティが設定されていなくても暗黙的にアプリケーションとして扱われました。

Active Server Pages (ASP)、Internet Server Application Programming Interface (ISAPI)、および ASP.NET といった Web サーバー機能を拡張するテクノロジーと比較して、アプリケーションは、IIS にとってあまり重要ではありませんでした。これらのテクノロジーによって IIS 6.0 でホストされるアプリケーションに追加機能と処理が提供され、デベロッパーはより複雑なアプリケーションを作成できるようになりました。IIS 6.0 の重要な課題は、そのようなアプリケーションを、あるアプリケーション プールのアプリケーションが、サーバー上の別のアプリケーションプールのアプリケーションに影響を及ぼさないように分離することでした。

IIS 7.0 でのサイト、アプリケーション、および仮想ディレクトリについて

IIS 7.0 では、サイト、アプリケーション、および仮想ディレクトリの概念が正式に確立されています。仮想ディレクトリとアプリケーションは別々のオブジェクトであり、IIS 7.0 構成スキーマの階層関係内に存在します。簡単に言えば、サイトは 1 つまたは複数のアプリケーションを含み、アプリケーションは 1 つまたは複数の仮想ディレクトリを含み、仮想ディレクトリはコンピューター上の物理ディレクトリにマップします。

IIS 6.0 と同じように、サイトは、そのサイトに関連付けられたすべてのコンテンツ (静的コンテンツも動的コンテンツも含む) を含みます。ただし、各サイトに少なくとも 1 つのアプリケーションを含む必要があります。このアプリケーションをルート アプリケーションと呼びます。各アプリケーション (ルート アプリケーションを含む) には、少なくとも 1 つの仮想ディレクトリを含む必要があります。この仮想ディレクトリをルート仮想ディレクトリと呼びます。これらのオブジェクトが共に機能してサイトを形成します。

さらに、IIS 7.0 では、アプリケーションの概念が、IIS および IIS 機能を拡張するテクノロジーの両方に対して意味を持ちます。アプリケーションは、実行時にサーバーにとって重要なオブジェクトです。これは、以前はマネージ コード アプリケーションについてのみ提供されていた機能をコンテンツで利用できるようにするために、IIS 7.0 では IIS および ASP.NET 要求処理パイプラインが統合されているためです。たとえば、各マネージ コード アプリケーションはアプリケーション ドメイン (AppDomain) で動作します。アプリケーションは複数の仮想ディレクトリを持つことができます。それぞれの仮想ディレクトリは、それぞれが属するアプリケーションと同じ AppDomain によってサービスを受けます。

次のセクションで、サイト、アプリケーション、仮想ディレクトリ、およびそれらの関連構成について詳しく説明します。

サイト

サイトは、アプリケーションおよび仮想ディレクトリのコンテナーです。サイトには、1 つまたは複数の一意のバインドを介してアクセスできます。

バインドには、通信にとって重要な 2 つの属性 (バインド プロトコルおよびバインド情報) が含まれます。バインド プロトコルは、サーバーとクライアントとの間の通信に使用するプロトコルを定義します。バインド情報は、サイトへのアクセスに使用する情報を定義します。たとえば、Web サイトのバインド プロトコルは HTTP または HTTPS であり、バインド情報は IP アドレス、ポート、およびオプションのホスト ヘッダーの組み合わせです。

サイトに異なるプロトコルやバインディング情報が必要な場合、1 つのサイトに複数のバインドを含めることができます。IIS の以前のバージョンでは、サポートされていたプロトコルは HTTP および HTTPS だけでした。たとえば、サイト内のセクションで HTTPS を使用してセキュリティ保護された通信が必要なときは、HTTP バインドと HTTPS バインドの両方を使用した場合がありました。

IIS 7.0 では、任意のプロトコルに対してバインドを適用できます。IIS 7.0 で追加プロトコルを使用できるようにしている新しいサービスは、Windows プロセス起動サービス (WAS) です。このサービスは、アプリケーション プールやメッセージベースのプロセス起動といった IIS 6.0 プロセス モデルの他に、迅速な障害保護、状態監視、およびリサイクルといったホスティング機能を引き続き保持します。ただし、WAS によって、起動アーキテクチャは HTTP に依存しなくなります。これは、標準のプロトコルを使用して Web サービスにおけるアプリケーション間通信を提供するテクノロジーにとって便利です。このようなテクノロジーの 1 つに Windows Communication Foundation (WCF) プログラミング モデルがあります。このモデルによって、伝送制御プロトコル (TCP)、Microsoft Message Queuing (MSMQ)、および名前付きパイプという標準プロトコルを介した通信が可能になります。これによって、通信プロトコルを使用するアプリケーションが、従来は HTTP ベースのアプリケーションでしか利用できなかったプロセスのリサイクル、迅速な障害保護、および構成といった IIS 機能を利用できるようになります。WCF プログラミング モデルの詳細については、MSDN の「Windows Communication Foundation」を参照してください。

サイトは、(仮想ディレクトリを含む) アプリケーションを含み、バインドを指定します。その他に、次の構成設定がサイトに属します。

• 制限 : 帯域幅、接続数、またはサイトへの接続の許容時間を制限する設定を構成します。
• ログ : サイトのログ ファイルの処理および保存に関する設定を構成します。
• 失敗した要求トレース ログ : サイトの失敗した要求トレース ログに関する設定を構成します。 

アプリケーション

アプリケーションは、HTTP などのプロトコルを介してコンテンツ配信やサービス提供を行うファイルの集まりです。IIS でアプリケーションを作成すると、アプリケーションのパスがサイトの URL の一部になります。

IIS 7.0 では、各サイトが、ルート アプリケーションまたは既定のアプリケーションと呼ばれるアプリケーションを持つ必要があります。ただし、1 つのサイトに複数のアプリケーションを含めることができます。たとえば、オンライン取引 Web サイトには、ユーザーが買い物中に商品を集めておくことができるショッピング カート アプリケーション、ユーザーが買い物をするときに保存された支払い情報を表示するためのログインアプリケーションといった、複数のアプリケーションがあります。

アプリケーションは、サイトに属するだけでなく、アプリケーション プールにも属します。アプリケーション プールは、1 つのアプリケーションを、サーバー上の他のアプリケーション プールのアプリケーションと分離します。マネージ コード アプリケーションの場合は、必ず、そのアプリケーションに必要な .NET Framework のバージョンが動作しているアプリケーション プールに関連付けてください。

「サイト」のセクションで説明したように、IIS 7.0 は既定で HTTP および HTTPS をサポートしますが、その他のプロトコルも使用できます。各サイトに対して 1 つまたは複数のバインドを指定し、サイト内のコンテンツとのやり取りやアクセスを行います。親サイトのバインドで指定されたプロトコルを使ってアプリケーションが通信するには、プロトコルを有効化する必要があります。このために、アプリケーションの enabledProtocols 属性でプロトコルを指定し、適切なリスナー アダプターがサーバー上にあって構成の <listenerAdapters> セクションで指定されていることを確認します。

仮想ディレクトリ

仮想ディレクトリは、IIS で指定するディレクトリ名 (パスとも言います) で、ローカル サーバーまたはリモート サーバー上の物理ディレクトリにマップします。このディレクトリ名はアプリケーションの URL の一部になり、ユーザーは、ブラウザーからこの URL を要求してWeb ページや追加ディレクトリやファイルのリストといった物理ディレクトリ内のコンテンツにアクセスできます。仮想ディレクトリ名に物理ディレクトリと異なる名前を指定すると、URL がサイトのルートに直接マップしないので、ユーザーがサーバーの実際の物理ファイル構造を知るのが難しくなります。

IIS 7.0 では、各アプリケーションが仮想ディレクトリ (ルート仮想ディレクトリと呼びます) を持つ必要があります。この仮想ディレクトリは、アプリケーションを、そのアプリケーションのコンテンツがある物理ディレクトリにマップします。ただし、1 つのアプリケーションが複数の仮想ディレクトリを持つことができます。たとえば、ファイル システム内の別の場所にあるイメージをアプリケーションに含めたいけれども、アプリケーションのルート仮想ディレクトリにマップされる物理ディレクトリにそのイメージ ファイルを移動したくない場合に、仮想ディレクトリを使用することができます。

既定では、IIS は、仮想ディレクトリがマップされている物理ディレクトリ内、およびその物理ディレクトリ内の子ディレクトリの Web.config ファイルの構成を使用します。子ディレクトリ内の Web.config ファイルを使用したくない場合は、仮想ディレクトリの allowSubDirConfig 属性を false に指定します。

オプションで、仮想ディレクトリにアクセスするための資格情報およびメソッドを指定する必要がある場合は、username、password、および logonMethod 属性に値を指定します。

IIS 7.0 の構成 : <sites> セクション

では、IIS 7.0 の既定の <sites> セクションを見てみましょう。以下に、Windows Server® 2008 に IIS をインストールした後の、%windir%\system32\inetsrv\config \ にある ApplicationHost.config ファイルの内容を示します。

<sites>
<site name="Default Web Site"id="1" > 

<path="/"> 

<virtualDirectory path="/"physicalPath="%SystemDrive%\inetpub\wwwroot" /> 

</application> 

<bindings> 

<binding protocol="http" bindingInformation="*:80:" /> 

</bindings> 

</site> 

<siteDefaults> 

<logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" /> 

<traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />

</siteDefaults> 

<applicationDefaults applicationPool="DefaultAppPool" /> 

<virtualDirectoryDefaults allowSubDirConfig="true" /> 

</sites> 

パス フィールドに単一の "/" がある場合、これがルート オブジェクトであることがわかります。アプリケーション セクションにある場合はルート アプリケーション、仮想ディレクトリ セクションにある場合はルート仮想ディレクトリを表します。

既定の要素

次のセクションは、<sites> セクション内のコレクションおよび要素、および <sites> セクション内の階層関係のリストです。

<sites> セクション

<site> コレクション

<bindings> コレクション

<binding> 要素

<clear> 要素

<limits> 要素

<logFile> 要素

<traceFailedRequestsLogging> 要素

<application> コレクション

<virtualDirectory> コレクション

<virtualDirectoryDefault> 要素

<applicationDefaults> 要素

<virtualDirectoryDefaults> 要素

<siteDefaults> 要素

<bindings> コレクション

<binding> 要素

<clear>要素

<limits> 要素

<logFile> 要素

<traceFailedRequestsLogging> 要素

<applicationDefaults> 要素

<virtualDirectoryDefaults> 要素 

<applicationDefaults> 要素と <virtualDirectoryDefaults> 要素の 2 つは、複数の場所に現れます。<siteDefaults> 要素もありますが、この要素は <sites> セクションの 1 箇所でしか構成できないので、1 度しか現れません。既定の要素は、特別に、各コレクションで同じ値を繰り返さずに属性の既定値を構成できます。

1 つの属性が複数のレベルで構成されている場合、最下位レベルの値が使用されます。たとえば、<sites> セクションと <site> コレクションの両方で <applicationDefaults> 要素の既定値を指定した場合、<site> コレクションの値が使用されます。また、既定の要素とオブジェクトのコレクションの両方で同じ属性または子要素が構成されている場合、コレクションの値が使用されます。たとえば、<applicationDefaults> 要素および <application> コレクションで属性を構成した場合、<application> コレクションの値が使用されます。

次の表は、<applicationDefaults> 要素をどの親要素の下で構成できるかを示し、その値がアプリケーションに及ぼす効果について説明しています。

親要素

説明

<sites> セクション

サーバー上のすべてのアプリケーションの既定の設定を指定します。

**<site>**コレクション

親サイト内のすべてのアプリケーションの既定の設定を指定します。

次の表は、<virtualDirectoryDefaults> 要素をどの親要素の下で構成できるかを示し、その値が仮想ディレクトリに及ぼす効果について説明しています。

まとめ

ここでは、IIS 7.0 におけるサイト、アプリケーション、および仮想ディレクトリについて、理解を深めました。IIS 7.0 は IIS 6.0 と異なり、構成においてアプリケーションおよび仮想ディレクトリは明確に別のオブジェクトとなり、Web サーバーに対する固有の目的、およびサイトに対する関係が明らかになっています。また、HTTP および HTTPS 以外のプロトコルを使用するアプリケーションをサイトに含めることができるようになりました。これによって、IIS 6.0 で導入されたプロセス モデルの利点は保持しつつ、サイトの機能が拡張されました。

WAS および IIS 7.0 のアーキテクチャについての詳細は、IIS.NET の「Introduction to IIS 7.0 Architecture」を参照してください。この記事で説明した構成設定の詳細は、MSDN の「IIS 7.0 Settings Schema(英語)」を参照してください