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

担当: Reagan Templin

はじめに

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

この記事では、IIS 7 で導入された違いに関する理解を深めるために、IIS 6.0 のアプリケーションの概要を簡単に説明します。 次に、IIS におけるサイト、アプリケーション、仮想ディレクトリの概念を説明し、構成における <sites> セクションを紹介します。

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

IIS 6.0 では、仮想ディレクトリとアプリケーションの概念が混乱を招いていました。 これらは個別の概念として議論されましたが (概念的には機能の観点から異なっていました)、アプリケーションは仮想ディレクトリから物理的に別のオブジェクトではありませんでした。 IIS 6.0 では、アプリケーションは実際には、メタベースに次のプロパティのいずれかまたは組み合わせたものを持つ仮想ディレクトリにすぎませんでした: AppFriendlyName、AppRoot、AppIsolated、AppPoolID。

IIS に対するアプリケーションの重要性は、ASP (Active Server Pages)、ISAPI (Internet Server Application Programming Interface)、ASP.NET などの Web サーバーの機能を拡張するテクノロジよりも低いものでした。 これらのテクノロジは、IIS 6.0 でホストされるアプリケーションに追加の機能と処理を提供し、開発者はより複雑なアプリケーションを作成できるようになりました。 IIS 6.0 に対する重要な問題は、あるアプリケーション プールのアプリケーションがサーバー上の別のアプリケーション プールのアプリケーションに影響を与えないように、当該アプリケーションを分離することでした。

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

IIS 7 以降では、サイト、アプリケーション、および仮想ディレクトリの概念が形式化されています。 仮想ディレクトリとアプリケーションは別々のオブジェクトになり、IIS 構成スキーマでは階層関係に存在します。 簡単に言うと、サイトには 1 つ以上のアプリケーションが含まれ、アプリケーションには 1 つ以上の仮想ディレクトリが含まれており、仮想ディレクトリはコンピューター上の物理ディレクトリにマップされます。

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

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

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

サイト

サイトはアプリケーションと仮想ディレクトリのコンテナーであり、1 つ以上の一意のバインドを通じてアクセスできます。

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

サイトに異なるプロトコルまたはバインド情報が必要な場合、サイトに複数のバインドが含まれている可能性があります。 以前のバージョンの IIS では、HTTP プロトコルと HTTPS プロトコルのみがサポートされていました。 たとえば、サイトのセクションで HTTPS 経由のセキュリティで保護された通信が必要な場合、Web サイトには HTTP バインディングと HTTPS バインディングの両方を含める可能性があります。

IIS 7 以降では、バインドはどのプロトコルにも適用できます。 Windows プロセス アクティブ化サービス (WAS) は、IIS で追加のプロトコルを使用できるようにする新しいサービスです。 このサービスは、アプリケーション プールやメッセージベースのプロセス アクティブ化など、使い慣れた IIS 6.0 プロセス モデルや、迅速な障害保護、正常性監視、リサイクルなどのホスト機能を保持します。 ただし、WAS では、アクティベーション アーキテクチャから HTTP への依存関係が削除されます。 これは、標準プロトコルを介して Web サービスでアプリケーション間通信を提供するテクノロジに有用です。 Windows Communication Foundation (WCF) プログラミング モデルは、伝送制御プロトコル (TCP)、Microsoft Message Queuing (MSMQ)、および名前付きパイプの標準プロトコルを介した通信を可能にするテクノロジの 1 つです。 これにより、プロセスのリサイクル、迅速な障害保護、構成など、これまで HTTP ベースのアプリケーションのみで利用可能だった IIS 機能を、通信プロトコルを使用するアプリケーションでも使用できるようになりました。 WCF プログラミング モデルの詳細については、MSDN の Windows Communication Foundation を参照してください。

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

• 制限: 帯域幅、接続の数、またはサイトへの接続に許可される時間を制限する設定を構成します。
• ログ記録: サイトのログ ファイルの処理と記憶域の設定を構成します。
• 失敗した要求トレース ログ: サイトの失敗した要求トレースをログに記録するための設定を構成します。

アプリケーション

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

IIS 7 以降では、各サイトにルート アプリケーションまたは既定のアプリケーションという名前のアプリケーションが必要です。 ただし、1 つのサイトに複数のアプリケーションを含めることができます。 たとえば、ユーザーがショッピング中にアイテムを収集できるショッピング カート アプリケーションや、ユーザーが購入時に保存された支払い情報を取り消すためのログイン アプリケーションなど、複数のアプリケーションを含むオンライン コマース Web サイトがあるとします。

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

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

仮想ディレクトリ

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

IIS 7 以降では、各アプリケーションには、ルート仮想ディレクトリという名前の仮想ディレクトリが必要です。このディレクトリは、アプリケーションのコンテンツを含む物理ディレクトリにアプリケーションをマップします。 ただし、アプリケーションには複数の仮想ディレクトリを含めることができます。 たとえば、アプリケーションでファイル システム内の別の場所のイメージを含めたいものの、アプリケーションのルート仮想ディレクトリにマップされている物理ディレクトリにイメージ ファイルを移動したくない場合に、仮想ディレクトリを使用できます。

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

必要に応じて、仮想ディレクトリにアクセスするための資格情報とメソッドを指定する必要がある場合は、ユーザー名、パスワード、および logonMethod 属性の値を指定できます。

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

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

<sites> 
    <site name="Default Web Site" id="1"> 
        <application 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>

パス フィールドに "/" が 1 つ表示される場合は、これがルート オブジェクトであることがわかります。 アプリケーション セクションまたは仮想ディレクトリ セクションに含まれているかどうかによって、ルート アプリケーションまたはルート仮想ディレクトリになります。

既定の要素

次のセクションでは、<sites> セクション内のコレクションと要素、および <sites> セクション内の階層関係を一覧表示します。

<sites> section 
<site> collection 
<bindings> collection 
<binding> element 
<clear> element 
<limits> element 
<logFile> element 
<traceFailedRequestsLogging> element 
<application> collection 
<virtualDirectory> collection 
<virtualDirectoryDefaults> element 
<applicationDefaults> element 
<virtualDirectoryDefaults> element 
<siteDefaults> element 
<bindings> collection 
<binding> element 
<clear> element 
<limits> element 
<logFile> element 
<traceFailedRequestsLogging> element 
<applicationDefaults> element 
<virtualDirectoryDefaults> element

複数の場所に表示される 2 つの要素 (<applicationDefaults> 要素と <virtualDirectoryDefaults> 要素) があることに注意してください。 <siteDefaults> 要素もありますが、<sites> セクションでは一箇所しか構成できないため、一度しか表示されません。 既定の要素は、各コレクションで同じ値を繰り返す必要はなく、属性の既定値を構成できるため、特別なものです。

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

次の表は、<applicationDefaults> 要素がどの親要素の下で構成できるかを指定し、その値がアプリケーションに与える影響について説明しています。

次の表は、<virtualDirectoryDefaults> 要素がどの親要素の下で構成できるかを指定し、その値が仮想ディレクトリに与える影響について説明しています。

まとめ

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

WAS および IIS アーキテクチャの詳細については、「IIS.NET での IIS 要求処理アーキテクチャ」を参照してください。 この記事で説明する構成設定に関する詳細については、MSDN の IIS 7 設定スキーマを参照してください。