IIS 7의 구성 설정 시스템

개요

모든 IIS 7의 새로운 관리 기능들은 그 핵심 요소로 전혀 새로운 구성 설정 시스템을 제공해줍니다. 이 새로운 구성 설정 시스템의 특징은 분산 설정이 가능하고, 평범한 텍스트로 작성되며, XML 파일 형태를 띄고 있다는 점으로 IIS와 ASP.NET, 그리고 FTP 7.0 등 각종 구성 요소들을 포함한 웹 서버 플랫폼 전반에 걸친 구성 설정을 담당합니다. 특정 수준에서 구성 설정이 잠겨있지 않은 경우, 선택 여하에 따라 콘텐츠와 동일한 디렉터리에 구성 설정이 같이 존재할 수도 있습니다. 다만, FTP 6.0의 구성 설정은 여전히 메타베이스에 저장된다는 점에 주의하시기 바랍니다.

머신 관리자가 설정하기에 따라 구성 설정 계층구조의 각각의 수준들은 사이트 소유자나 응용 프로그램 개발자 같은 다른 사용자들에게 위임될 수 있습니다. 보안상의 이유로 제품이 출고될 때는 머신의 관리자만 구성 설정을 기록할 수 있도록 기본적인 제약이 걸려 있습니다. (단, DefaultDocument 같은 몇 가지 사이트 관련 설정들은 이 범주에서 제외됩니다.) 그러나, 세련되고 세분화된 잠금 기능을 효과적으로 활용하면 안전하게 잠금을 해제하고 적절한 웹 네임스페이스 범위에 대해서 더 많은 사용자들에게 특정 구성 설정 관리를 위임할 수 있습니다. 뿐만 아니라, 새로운 구성 설정 시스템은 API 수준에서 이전 버전의 IIS와도 하위 호환됩니다. (단, 메타베이스 호환성 레이어가 설치된 상태여야 합니다.)

구성 설정 시스템의 루트 (또는 전역) 수준에는, 두 개의 독립적인 파일이 존재합니다:

• system32\inetsrv\config\applicationHost.config: 웹 서버(IIS) 설정과 관련된 전역 기본값들이 저장됩니다.
• windows\microsoft.net\framework\v2.0.50727\config\machine.config: ASP.NET과 관련된 일부 설정들을 비롯해서 .NET 프레임워크 설정과 관련된 전역 기본값들이 저장됩니다. (그 외의 다른 ASP.NET 관련 설정들은 같은 폴더에 위치한 web.config 파일에 저장되며, 이 파일을 루트 web.config 파일이라고 부릅니다.)

이처럼 두 개의 파일이 개별적으로 존재하는 이유는 (일정이나 제품 측면에서) 두 기술의 버전이 서로 다르기 때문입니다. 즉, IIS는 윈도우의 일부분인 반면 .NET 프레임워크의 버전은 독립적입니다.

그리고, 웹 콘텐츠 디렉터리에는 계층구조 상, 해당 수준과 그 하위 수준의 동작을 제어하는 web.config 파일이 존재할 수 있습니다. 이 파일은 로컬이나 (콘텐츠 디렉터리가 UNC 공유인 경우) 원격지에 존재할 수 있는데, 일반적으로 해당 수준에 지정할 수 있는 IIS 및 ASP.NET 또는 그 밖의 .NET 프레임워크 관련 구성 설정값들이 지정되어 있습니다. 그러나, 대게 웹 콘텐츠 디렉터리에는 web.config 파일을 생성하지 않습니다. *

계층구조

다음 그림에서 볼 수 있는 것처럼 구성 설정 시스템의 계층구조에서 루트 파일은 machine.config이고 그 하위에는 같은 폴더에 위치한 (루트 web.config라고 불리는) web.config 파일이 존재하며, 또 그 하위에 applicationHost.config 파일이 존재하며, 마지막으로 네임스페이스를 따라 선택적인 web.config 파일들이 자리합니다.

섹션

구성 설정 파일은 내부적으로 각각의 설정들을 "섹션"이라는 단위를 기반으로 구성합니다. 구성 설정 섹션은 논리적으로 관련된 설정들의 모음으로, 배포나 등록 해제시에 사용되는 하나의 단위며 보통 한 개의 서버 모듈에 의해 사용됩니다.

이 말은 작업자 프로세스에서 실행되는 거의 모든 런타임 모듈은 그에 대응하는 구성 설정 섹션을 갖고 있다는 뜻입니다. 그리고, 구성 설정 섹션을 확장성의 한 단위로 볼 수도 있는데 구성 설정 스키마에 새로운 설정을 추가하는 작업이 기종의 섹션을 확장하거나 하나 이상의 섹션을 추가함으로서 이뤄지기 때문입니다.

또한, 각각의 섹션들은 "섹션 그룹"이라고 불리는 논리적으로 연관된 컬렉션으로 또 다시 분류될 수 있습니다. 그렇다고 해서, 섹션 그룹이 배포나 등록, 또는 (잠금, 암호화 등과 같은) 기타 실질적인 작업의 단위라는 뜻은 아닙니다. 섹션 그룹은 자체적인 설정을 갖고 있지 않습니다. 섹션 그룹의 용도는 설정들의 구조를 더 구조적으로 체계화하고 구성 설정 섹션들이 단조롭고 길게 늘어지는 것을 막기 위한 것입니다. 주로 설정들의 계층구조를 구축하기 위한 목적으로 사용되며 결과적으로 서로 부모/자식간의 연관 관계를 갖게 됩니다.

또한, 섹션 그룹은 중첩될 수도 있습니다. 반면, 하나의 섹션은 항상 하나의 섹션 그룹에만 속할 수만 있으며, 다른 섹션이나 섹션 그룹을 포함할 수 없습니다. 특정 섹션 그룹은 부모 섹션 그룹에 속할 수 있으며 0개 이상의 자식 섹션 그룹을 포함할 수 있습니다. 일반적으로 섹션 그룹은 둘 이상의 자식 섹션을 포함하고 있는데, 만약 그렇지 않다면 근본적으로 그다지 존재할 필요가 없는 섹션 그룹이라고 볼 수 있습니다. * (그렇기는 하지만, 여전히 다양한 이유로 섹션을 하나만 갖고 있는 사용자 정의 섹션 그룹을 생성해서 스키마을 확장할 수는 있습니다.)

다음은 섹션과 섹션 그룹의 사례를 보여주는 예제입니다:

<!-- 웹 서버 구성 설정을 위한 섹션 그룹 -->
<system.webServer>
  <!-- 웹 서버 보안 구성 설정을 위한 섹션 그룹 -->
  <security>
    <!-- 웹 서버 인증 구성 설정을 위한 섹션 그룹 -->
    <authentication>
      <!-- 인증을 위한 세 개의 섹션 -->
      <basicAuthentcation ... />
      <windowsAutnentication ... />
      <anonymousAuthentication ... />
    </authentication>
  </security>
</system.webServer>

모든 섹션에는 자신의 이름이 존재합니다. 짧은 이름은 섹션 자신의 이름이며, 긴 이름은 모든 섹션 그룹의 이름들을 포함한 전체 이름입니다. 가령, "windowsAuthentication" 섹션의 전체 이름은 "system.webServer/security/authentication/windowsAuthentication"입니다. 계층구조 조직에 같은 이름을 가진 섹션이나 섹션 그룹이 존재할 수는 있지만, 반드시 서로 다른 섹션 그룹에 위치해야 합니다.

그리고, URL 네임스페이스의 모든 수준에는 연관된 구성 설정이 존재할 수 있습니다. 특정 수준의 구성 설정은 자식 수준에서 재정의하지 않는 이상 그대로 상속됩니다. URL별로 구성을 설정하는 가장 간단한 방법은 가상 경로에 맵핑된 물리적 파일 시스템 폴더에 web.config 파일을 작성하는 것 입니다. 루트 수준이나 컴퓨터 수준에서 설정하려면, 구성 설정 섹션 그룹에 따라 각각 별도의 파일을 이용해야 합니다. (나중에 문서로 정의되겠지만, 일단은 구성 설정을 담고 있는 XML 요소의 이름만 참고하시기 바랍니다.):

그리고, 구성 설정이 XML 형태로 영속화되기 때문에 구성 설정 시스템의 구조적 단위를 XML 용어와 맵핑하여 표현하면 많은 도움이 됩니다. 섹션 그룹과 섹션은 XML의 요소 형태를 갖고 있으며, 섹션 내부의 설정들은 XML 용어와 밀접하게 연관된 보다 작은 단위들로 구성되어 있습니다:

구성 설정 시스템의 핵심 영역은 선언적 스키마에 의해 동작됩니다. 구성 설정 스키마는 몇 개의 파일에 분리되어 있으며 널리 알려져 있는 system32\inetsrv\config\schema\ 폴더에 위치해있습니다. 기본적으로 머신 관리자만 이 폴더에 접근할 수 있으며, 고객이나 서드 파티에서는 이 위치에 사용자 정의 섹션에 대한 스키마 파일을 복사해서 새로운 스키마를 추가할 수 있습니다. 그러면, 구성 설정 시스템이 시작될 때 구성 설정을 위해 호출자의 프로세스 과정 중에 자동으로 해당 파일들을 찾아줍니다. 이미 구성 설정 시스템이 실행 중이라면 변경된 스키마나 새로운 파일들이 반영되지 않을 것입니다.

이 디렉터리에 설치된 IIS 관련 스키마 파일이나 다른 스키마 파일들을 함부로 편집하지 마십시오. 만약, 스키마가 손상되면 오류가 발생하거나 아예 서버가 시작조차 되지 않을 수 있습니다.

노트: 전통적인 파일 접근 API나 XML 파싱/편집 기법을 제외하면 스키마 파일을 읽어오거나 설정하기 위한 고수준의 프로그래밍 인터페이스는 존재하지 않습니다. 따라서, 항상 수정을 하기 전에는 정상적인 상태의 스키마 폴더를 백업하는 것이 권장됩니다.

웹 서버 플랫폼의 전체 스키마는 다음과 같은 세 개의 파일에 나눠져 있습니다:

• IIS_schema.xml: Windows Activation System과 IIS 웹 서버의 설정 및 섹션 그룹을 담고 있습니다.
• ASPNET_schema.xml: ASP.NET의 설정 및 섹션 그룹을 담고 있습니다.
• FX_schema.xml: 다양한 섹션 그룹을 통해서 다른 .NET 프레임워크의 설정들을 담고 있습니다.

만약, IIS 7 FTP 기능을 설치했다면 추가로 FTP_schema.xml 파일도 발견할 수 있을 것입니다.