【IIS7】 コンフィグレーションシステム Part II
構成システムがどんな”イメージ”なのかについて Part I でふれました。Part II では管理ツールと構成システムの関係に触れようと思います。
IIS7 ではまったく新しい 横にペインが３つ並んだ最近のMS製品の管理ツールとしては標準的な形をしている Web Server Manager という名称の管理ツールを用意しています。名前に関してはまだ変更があるかもしれませんので最終確定ではありません。
当然構成情報をGUI で設定する場合、このツールを使うわけですが、メタベースがなくなったことによってこのツールでの変更も Part I で登場した.config ファイルに対して行われます。従って、xmlベースの configファイルを直接変更しても、 GUI で変更しても、 あるいはまだこのブログでは書いていない構成管理系の API を使うにしても、はたまた互換性のある WMI などのスクリプトから利用できるテクノロジーを使用しても すべて .config に反映がなされる統一感が実現されています。
もう一つ今回触れておくと、新管理ツールの説明ではよくやるんですが、IIS7からはサーバーに接続するだけでなく サイトレベルやアプリケーションレベルに接続できるようになりました。そうです。ADでOUのどこかの階層以下の管理を組織内で委任できるのと同じように今度はサイト単位あるいはアプリケーション単位で管理を委任することができます。管理者にとっては個別のアプリの環境を委任することができるため、かなり便利になりますし、今後書いていこうと思いますが、当該サーバーの特定設定に関しては委任した先の人が変更（階層構造なので上書きともいう）できないようにすることもできます。このことによって管理者はサーバー全体に影響を及ぼすような操作をされる心配なく委任できますし、逆の視点ではアプリ開発者は自由に自分のアプリを設定することができるようになります。
そして構成システム上はサーバー全体の設定に関しては applicationHost.config をメンテし 、サイト単位であればサイトで指定した仮想ディレクトリのルートにある web.config、アプリケーションの場合も実際のディスク上のパスのルートに web.config を置き、それぞれの階層でメンテナンスできます。そしてその config の中ではASP.NETの設定も入っていれば、IIS 上での稼動設定も入っています。随分すっきりした感じです。ちなみに Web Server Manager での GUI 操作設定もこの階層構造にうまく融合しており、例えばアプリケーション単位の設定を変更するとアプリケーションに割り当てられた web.config がなければ作成し、あれば変更する動きをします。
ということで Part II では管理ツールと構成システムの関係を中心に、管理の委任にもふれてみました。
