#概要
IIS の以下について一体何なのかを調べた備忘録。
- アプリケーションプール
- サイト
- アプリケーション
- 仮想ディレクトリ
について公式ドキュメント読んでも謎だったのでまとめた。
#参考
https://qiita.com/matarillo/items/2d713603f23b0ac165f3
https://qiita.com/matarillo/items/c7ec64ae8e3b9a65f5ea
https://blogs.technet.microsoft.com/jpiis/2014/12/15/iis-7-5-windows-server-2008-r2/
#全体像
##サイト
「IPアドレスとポートとホスト名（FQDN）」と 1対1 に紐づけられるディレクトリ。
##アプリケーションプール
ちょっと長い説明ですが、「HTTPリクエスト(http://example.co.jp など)を受けた際、その url(ここでは http://example.co.jp) に対応するサイトを動作させるためのプロセス」の設定。「どういうプロセスで動かすか？」を表すテンプレートといってもよい。
##アプリケーション
サイトをプログラムとして動作させる単位。↑のアプリケーションプールの説明内に 「サイトを動作させる」という記述があるが、サイトというのはあくまで「『IPアドレスとポートとホスト名（FQDN）』と 1対1 に紐づけられるディレクトリ」、つまり単なるディレクトリなので IIS からみて動作させる単位が必要であり、その動作させる単位がアプリケーションと呼ばれる。
サイト作成時には、サイトの物理パスと同じパスに「ルートアプリケーション」というものが自動で生成される。なので、アプリケーションを一つも自分で作らなくても、サイトには必ず1つのルートアプリケーションが紐づく。
また、1つのサイト内には複数のアプリケーションを作ることができる。
###サイトとアプリケーションに紐づくアプリケーションプール
後で記述するが、サイト作成時にはアプリケーションプールを指定する。サイトと同時に作られるルートアプリケーションは、このサイトに紐づくアプリケーションプールから生成されるプロセスで処理される。
対して、自分で手動でサイト内に作るアプリケーションはサイトに紐づく以外のアプリケーションプールを割り当てることもできる。
##仮想ディレクトリ
名前の通り、「サイト内にパスを自由に変えて作れるディレクトリ」。前述のアプリケーションはアプリケーションプールの設定ができるのだが、仮想ディレクトリは設定できない。
単にディレクトリを伸ばしたもの(Linux でいうマウントでディレクトリが追加された、みたいなイメージ)という理解でよい。
各アプリケーション(ルートアプリケーションも)には一つの仮想ディレクトリが紐づいている。言い換えると、物理パスを紐づける役割が仮想ディレクトリといってもいい(アプリケーションは自身の物理パスの紐づけに仮想ディレクトリを使っている、ということ)。
#実際に作ってみる
vbscript で試してみます。
##ディレクトリ構成
C:/
├ IISSample
│ ├ application1
│ │ └ test.asp
│ │
│ ├ application2
│ │ └ test.asp
│ │
│ └ VirtualDirectory
│ └ test.asp
└ test.asp
###各ファイル内容
<html>
<body>
<%
Response.Write "IIS Sample"
%>
</body>
</html>
<html>
<body>
<%
Response.Write "application 1"
%>
</body>
</html>
<html>
<body>
<%
Response.Write "application 2"
%>
</body>
</html>
<html>
<body>
<%
Response.Write "virtual directory"
%>
</body>
</html>
###前提
IIS のサイトは、ディレクトリ構成そのままの url で基本アクセスできる。
つまり、サイトのホスト名(urlのドメイン)が site1-local で、サイト内部の applciation1/test.asp にアクセスしたい場合は、
「http://site1-local/application1/test.asp」 でアクセスできる。
##アプリケーションプール作成
##サイト作成
↑で作ったアプリケーションプールを紐づけます。サイト名は IIS 上で識別するための名前です。
外部に公開する際に使うのはホスト名(今回は site1-local)。
サイトの物理パスと同じ物理パスを持つルートアプリケーションが登録されているのがわかります。
###ブラウザでアクセスしてみる
site1-local という url をサイト作成時に設定しましたが、site1-local という url が localhost(=127.0.0.1)を示す設定が必要です。
127.0.0.1 site1-local
ちゃんと動いているのが確認できます。
###サイトを動かすプロセス
アプリケーションはサイトを動作させるプロセスを生み出すテンプレート、といったのを覚えてますでしょうか。
プロセスを確認してみます。
w3wp.exe というのがサイトを動作させているプロセス(=ワーカープロセス)です。
プロセスの実行ユーザー名がアプリケーションプール名 ApplicationPool-1 になっているのも注目です。
(実行ユーザーと読み取れるディレクトリの制限で重要になってきます)。
##サイト内にアプリケーションを作成
application2 ディレクトリを、今作った application1 ディレクトリをルートとするサイトから読み取れるようにします。
ブラウザでアクセスしてみます。
##サイト内に仮想ディレクトリを追加
VirtualDirectory ディレクトリを、今作った application1 ディレクトリをルートとするサイトから読み取れるようにします。
アプリケーションと比べて、アプリケーションプールの設定がないことがわかります。
ブラウザでアクセスしてみます。
#応用編
##複数のアプリケーションプールを一つのサイト内で使ってみる
アプリケーションプールを追加します。
サイト内のアプリケーションが紐づくアプリケーションプールを新しいアプリケーションプール(ApplicationPool-2)に変更します。
動作は正しいです(表示するまで少し時間がかかるかもしれません)
###複数のアプリケーションプール=複数のプロセス
ApplicationPool-2 という実行ユーザーのプロセスが新たに確認できます。
##上位のディレクトリのアプリケーションに紐づくアプリケーションプールを停止した場合
サイトのルートアプリケーションが紐づくアプリケーションプール ApplicationPool-1 を停止してみます。
内部に手動で作ったアプリケーションへのアクセスをブラウザで確認してみます。
正しく動いています。
ではルートアプリケーション内はどうでしょうか？
こちらは 503 で動いていないことがわかります。
つまりディレクトリやアプリケーションの階層ではなく、プロセス単位でサイトへのアクセスが生きているか死んでいるかが決まることがわかります。
プロセスも 実行ユーザー ApplicationPool-1 は存在していないことがわかります。
###仮想ディレクトリはどうなった？
仮想ディレクトリもアプリケーションプールを設定できない(=今回はルートアプリケーションと同じ)ので、同じく 503 となります。
####仮想ディレクトリを手動で追加したアプリケーションの下に追加する
ブラウザでアクセスしてみます。
正しく動いています。
仮想ディレクトリはアプリケーションプールを設定できないので、仮想ディレクトリがサイトとして動作するときのアプリケーションプールは、仮想ディレクトリをどのアプリケーション内に作成するか(そのアプリケーションが紐づくアプリケーションプール)で決まることがわかります。