안녕하세요. IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 어플리케이션 개발자 / 관리자 분들이라면 모두가 고민하는 웹 어플리케이션의 구성/관리/배포에 대한 내용입니다.
단순히, 웹사이트 설치나 웹사이트 이전, 백업 하는 정도라고 생각하기 쉽습니다만, 웹사이트 및 응용프로그램들이 가지는 다양한 종속성(Dependency)등에 대한 고려와 시스템 / 웹사이트에 대한 설정까지 다양한 환경이 정확히 생성/관리/배포 되어야 하기 때문에 관리 작업에서 가장 어렵고 시간이 많이 소요되는 힘든 과정이 바로 이 구성/관리/배포가 아닐까 생각합니다.
또한, 한 두대의 웹서버를 관리하시는 분들부터, 5~10대의 서버를 관리해야 하는 경우, 또는 수백대의 웹서버를 자동화 기능들을 통해 관리해야 하는 호스팅사까지 다양한 환경에 맞는 스크립트나 배포 도구, 또는 필요할 경우 배포나 유지관리를 위한 툴을 직접 제작해야 하는 경우까지, 다양한 환경에 맞는 기능을 선택하는 것도 필요하실 겁니다. 이런 비지니스 구조, 환경에 맞는 툴들이나 방법은 어떻게 선택해야 할까요?
예를 들어, 한 서버에서 대략 300개 정도의 운영 중인 웹사이트에 하드웨어 적인 장애가 발생해 다른 시스템으로 이전해야 하는 상황이 발생하는 (웹호스팅) Shared Hosting 환경이라면 어떨까요? 더더욱 자동화된 배포나 이전, 백업 등에 대해서 고민하시게 될겁니다.
이 복잡한 작업들을 어떻게 쉽고 빠르게 해결 가능할까요?
IIS7은 여려 배포를 위한 훌륭한 기능들을 제공하고 있는데요. 그 배포 기능들을 차례대로 소개해 드리려고 합니다. ^_^
IIS의 다양한 배포 도구
(1) 웹 플랫폼 설치 관리자 – WPI 
웹플랫폼 설치 관리자는 설치 과정을 GUI로 쉽게 구성 가능하도록 돕는 도구 입니다. 특히, Dependency가 있는 웹 어플리케이션을 자동으로 설치하거나, 관리툴, 개발도구, 다양한 확장기능들을 설명과 함께 선택이 가능하기 때문에 유용한 도구 입니다.
- 가장 손쉽고 자동화된 설치 환경 제공
- 국내&전세계의 다양한 웹 어플리케이션 기본 탑재
- 웹서버/데이터베이스서버/프레임워크/도구들을 설치 가능
- 웹 어플리케이션 설치시 종속적인 웹서버 기능이나 데이터베이스 기능들을 자동 설치
WPI 기술소개 링크 : http://www.iis.net/webpi
WPI 다운로드 : http://www.microsoft.com/web/downloads/default.aspx
웹플랫폼 설치 관리자는 단순한 배포 도구를 넘어선, 훨씬 중요한 역할을 Microsoft 웹 플랫폼 아키텍쳐와 관련해 수행하게 되는데요. 관련해서는 따로 상세하게 소개해 드릴 예정이니 도움 되시길 바랍니다.
(2) 웹 배포 도구 – Web Deployment Tool 
웹 배포 도구는 웹사이트나 웹서버에 대해서 배포를 가능하게 돕는 IIS7의 확장기능(Extension)입니다. 특히, IIS6에서 IIS7으로의 마이그레이션이나 구성파일 패키징 기능을 지원하기 때문에 다양한 웹사이트 구성을 쉽게 이전이 가능한 특징이 있습니다. 여러대의 서버를 관리하는 경우라면 이 웹 배포 도구가 많은 도움이 되실 겁니다.
링크 : http://www.iis.net/extensions/WebDeploymentTool
- 패키징 기능으로 전체 웹사이트 파일, 포함된 데이터베이스, 권한 및 레지스트리정보 등을 패키지 가능
- IIS6를 IIS7으로 손쉽게 마이그레이션 가능
- 서버간 동기화(Synchronization) 가능
- IIS Manager와 연계해 이용 가능
웹 배포 도구 관련된 내용 역시 곧 포스트를 통해 상세히 전달해 드릴 예정입니다.
(3) IIS7의 파워쉘(Power Shell) 부가기능
파워쉘은 윈도우서버에 대해서 관심있는 분들은 잘 알고계시는 기능일텐데요. 윈도우 서버의 다양한 작업들을 파워쉘을 이용하면 모두 스크립트로 자동화가 가능한 것처럼, IIS7도 파워쉘을 이용해 모든 기능들을 스크립트화 시킨 후 웹사이트 생성부터 유지관리까지의 작업을 스크립트로 자동화시켜 실행 가능합니다. 다수의 웹서버를 관리하실 경우에 유용하며, 호스팅 환경 등에서도 활용 가능합니다.
- IIS7의 구성 정보들을 파워쉘 스크립트로 관리
- 웹사이트, 응용프로그램 풀, 웹응용프로그램, 가상디렉토리, 작업자 프로세스 등을 관리 가능
- 파워쉘의 다양한 스크립팅 기능으로 대규모의 복잡한 IIS 관리 기능을 처리 가능
- 파워쉘 2.0의 원격 기능을 이용해, 원격 서버를 파워쉘로 제어 가능
마찬가지로, IISKOREA 팀블로그에서 이 파워쉘을 이용한 유지 관리도 준비하고 있으니 기대해 주세요.
(4) 프로그래밍 API를 이용한 사용자 정의(Custom) 배포/관리툴 제작을 위한 기능
API를 이용한 방법은 자신이 소속된 회사에 적합한 패턴의 웹서버 생성, 관리 및 배포를 위한 프로그램을 직접 제공되는 기능을 이용해 제작 가능하게 합니다. 즉, 수백대가 넘는 호스팅사와 같은 IIS 웹서버 관리에 필요한 기능들을 이 제공되는 프로그래밍을 위한 API로 제작해 회사에 맞는 관리/배포를 위한 프로그램 직접 생성 가능하게 합니다. – 이미 나와있는 관리 솔루션들도 있지요.
WMI(Windows Management Instrument)
http://learn.iis.net/page.aspx/163/managing-applications-and-application-pools-on-iis-7-with-wmi/
Microsoft.Web.Administration
http://learn.iis.net/page.aspx/165/how-to-use-microsoftwebadministration/
자~ 이렇게 IIS는 비지니스 방식과 운용 규모 등에 맞는 다양한 관리/배포 도구를 제공하고 있습니다. 각각의 기능들에 대해서는 차후에 IISKOREA의 팀블로그를 통해 계속 소개해 드리도록 하겠습니다.
감사합니다.
"Internet Information Service"에 해당되는 글 10건
- 2009/10/27 IIS7의 다양한 설치/구성/관리/배포 기능 및 도구 소개
- 2009/10/21 IIS7 관련 국내 세미나 자료와 영상 링크
- 2009/10/20 PHP 삽질그만 #1 - MySQL & MSSQL DB를 GUI와 IIS7로 빠르게 개발
- 2009/10/19 URL Rewrite 1.1 (URL 재작성) - (6) Rewrite Map 사용
- 2009/10/16 URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
- 2009/10/15 URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
- 2009/10/15 URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
- 2009/10/14 URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
- 2009/10/14 IIS프런티어 - 10월 스터디 자료 공유 (1)
- 2009/10/14 URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
안녕하세요. IISKOREA 팀블로그 의 김대우 입니다.
IIS7과 관련된 국내 세미나나 발표 자료들이 어떤 것들이 있을까… 해서 찾던 도중 이런 내용들을 찾게 되어서 공유해 드리고 싶은 마음에 포스트로 링크를 걸어 봅니다.
먼저, 2008년 4월에 있었던 박중석님과 송원석님(저희 IISKOREA 필진이십니다)이 진행하신 세미나 내용입니다.
http://www.microsoft.com/korea/msdn/events/2008/0405_seminar_1/detail.aspx
ASP.NET 개발자가 알아야 하는 IIS7 (초,중급)
IIS7 응용 프로그램 풀 통합 모드와 ASP.NET 2.0(중급)
중간 정도에 보시면 찾을 수 있습니다.
송원석님이 진행 하셨던 IIS7 Inspiration 내용으로 발표 자료와 데모 동영상 모두가 있네요.
http://www.microsoft.com/korea/msdn/events/msdnweekly2/
- IIS7의 특징 - IIS7을 구성하는 40개 이상의 모듈들
- IIS7의 설치 – IIS7 통합모드와 클래식 모드, 새로운 구성설정 시스템
- IIS7 통합 모드와 클래식 모드
- 새로운 구성 설정 시스템
- IIS 관리자의 특징 - IIS7과 IIS 관리자 확장
또, 송원석님이 진행 하신 내용으로...
- IIS7 사용자 정의 구성설정 추가
- 사용자 정의 구성설정 값을 사용하는 HttpHandler 작성
- 사용자 정의 구성설정 관리를 위한 IIS 관리자 확장
http://www.microsoft.com/korea/eseminar/content.aspx?num=1206&CateID=0&page=12
더 많이 있을텐데… 제가 찾은건 이정도네요. 혹시 아시는 링크나 정보가 있다면 댓글 부탁 드립니다.
감사합니다.
PHP 삽질그만 #1 - MySQL & MSSQL DB를 GUI와 IIS7로 빠르게 개발
안녕하세요, IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 살짝 도발적이기도 할 것 같은데요. 당연히 IIS와 관련된 내용이기도 합니다. 혹시, SQL서버의 쿼리 툴을-정확히는 GUI기반 툴을- 사용해본 경험이 있으신지요? 
SQL2008의 GUI 관리 툴인 SQL Server Management Studio
SQL2000 시절에는 GUI 툴의 쌍두마차인, 엔터프라이즈 관리지와 쿼리 분석기가 있었지요. GUI로 편리하게 쿼리를 작성 가능하고, 데이터 조회, 프로시져 생성 등의 개발과정에 필수적인 쿼리 작성에 꼭 필요한 여러 기능들을 모두 담고 있는 유용한 녀석입니다. 특히, 조회한 결과를 그리드(표형식)로 볼 수 있고 쿼리 제작과 수정도 용이하기 때문에(vi 쓰시는 분들 말고 ^^;;) 개발 시간을 엄청나게 단축해 주는 녀석이기도 하지요. 하지만, 웹서버에 이 툴들을 설치하기도 애매한 노릇이고, DB서버마다 원격 접속하기도 쉽지 않지요. 특히, 여러 DB를 다루면서 개발과 관리를 동시에 해야 하는 PHP 개발자 분들은 시간이 많이 소요되는 작업이실 겁니다. - DB도 MySQL만 하는게 아니라 MSSQL도 같이 관리 하신다면? 가히 서버 관리 때문에 머리가 터져버릴지도…
IIS7는 PHP를 위한 최고의 개발 / 서비스 환경입니다.
IIS7은 윈도우 기반으로 Vista 및 Win7, Windows Server 2008에서도 이용 가능합니다. 즉, 주로 개발을 진행하시는 윈도우 환경에서 쉽게 구축이 가능하며, FastCGI를 통해 PHP를 아주 깔끔하게~ 지원합니다. 이런 개발용 PC에서 원격지의 SQL서버나 MySQL DB 처리, 또는 개발을 쉽게 할 수는 없을까요?
특히, PHP 개발 과정에서 주로 사용하는 + MySQL 또는 MSSQL은 DB에 접속해 개발하시기 어떤가요? – 쓸만한 GUI 쿼리 툴?
MySQL GUI 툴들 세트 가 있긴 하지만 2%가 아닌 20% 넘게 부족한 느낌입니다. 또한, 한 PHP 하시는 분들께 비교적 잘 알려진 SQLyog 라는 녀석이 있긴 합니다만, 유료라는게 좀~ 부담스럽습니다. 무료에 깔끔한, PHP 개발에 이용 가능한 그런 녀석은 없을까요? 있습니다. 바로, IIS 데이터베이스 관리자(Database Manager) 입니다.
IIS 데이터베이스 관리자로 MySQL과 MSSQL 웹 개발을 더욱 더 편리하게~
IIS의 기능 설치 관리를 위한 핵심 툴인 웹 플랫폼 설치 관리자 를 실행 하시고, 웹플랫폼 – 웹서버 – 관리 항목에서 “데이터베이스 관리자”를 선택 가능합니다. 이어서 설치를 진행하시면 몇몇 종속성 기능들과 함께 설치가 완료됩니다.
참고 정보 : IIS Database Manager
Database Manager가 제공하는 기능
- 로컬 또는 원격지의 MSSQL, MySQL 데이터베이스를 관리 가능합니다.
- 테이블 추가, 수정, 삭제, 이름바꾸기 가능
- View 및 테이블 개체(PK, FK, 색인) 등을 관리 가능
- 테이블의 데이터를 GUI로 손쉽게 수정 가능
- 쿼리 제작 및 실행 가능
- 저장 프로시져 및 View 생성,수정,삭제 가능
- MSSQL 서버에 대해 백업과 복구 가능
- MSSQL과 MySQL을 제외한 다른 DBMS에 대해 관리 기능 확장을 위한 API 제겅(즉, 타 DB도 개발해 IIS 모듈로 추가 가능)
이렇게 흥미로운 기능들을 Database Manage가 제공합니다. 그럼, 실행하고 직접 DB에 붙어 볼까요.
Database Manager 실행
설치가 완료되면 IIS7의 관리 툴에서 Database Manager를 실행합니다.
이어서 MSSQL이나 MySQL 연결을 추가합니다.
Add connection을 클릭히고
Connection을 추가합니다. 물론, MySQL을 선택 하고 연결 정보를 입력하시면 물론 MySQL에 연결 가능합니다.
데이터를 그리드에서 조회가능하며, 다양한 작업을 수행 가능합니다.
테이블 스키마 정보도 확인 가능하며 
PHP 개발 과정에서 꼭~ 필요한 쿼리 제작 및 수행도 손쉽게 처리 가능합니다.이렇게 데이터베이스를 쉽게 IIS에서 조회 가능하고, 쿼리 수행도 가능하며 원격 서버 관리 기능도 포함되기 때문에 개발하실때 유용할 것 같네요. 개인적인 생각에 MSSQL과 거의 동일한 인터페이스이기 때문에 MSSQL에 약간이라도 경험이 있다면 도움말이나 설명 없이도 슥슥~ 사용 가능하실 것 같습니다.
이렇게 간단히 IIS7의 Database Manager에 대해서 알아 보았습니다. IIS7은 PHP 개발과 배포에도 좋은 환경입니다. – 특히 관리 및 보안에 장점이…. 이런 여러 좋은 장점들에 대해서도 차근차근 풀어 보도록 하겠습니다. 감사합니다.
참고자료
IIS Database Manager
Using the IIS Database Manager
Basics of the IIS Database Manager
URL Rewrite 1.1 (URL 재작성) - (6) Rewrite Map 사용
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
안녕하세요. IISKOREA의 김대우 입니다. 이번에 소개해 드릴 내용은 Rewrite Map에 대한 내용인데요.
간단히 말씀 드리자면, 모든 URL 변환 처리를 패턴을 이용해 프로그래밍적으로 처리 가능하다면 행복할 겁니다. 하지만, 모든 URL 처리가 이렇게 패턴에 매핑 가능한 것은 아닐겁니다. 바로 이럴 경우, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 즉, 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 Rule의 수가 줄어들게 되니 정규표현식 처리가 줄게되고 이어서 시스템리스소도 적게 사용할 수 있을 겁니다.
Rewrite Map 제작
마찬가지로, 테스트를 위해 예전 포스트에서 작성한 심플한 article.aspx 파일 을 이용해 볼께요.
<%@ Page Language="C#" %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>URL Rewrite Module Test</title>
</head>
<body>
<h1>URL Rewrite Module Test Page</h1>
<table>
<tr>
<th>Server Variable</th>
<th>Value</th>
</tr>
<tr>
<td>Original URL: </td>
<td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td></tr>
<tr>
<td>Final URL: </td>
<td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
</tr>
</table>
</body>
</html>
테스트를 위해 http://localhost/article.aspx 링크를 접속해 보면 아래와 같은 결과를 보실 수 있을 겁니다.
(만약 안 나오신다면 ASP.NET 서비스를 설치해 주세요.)
Rewrite Map 생성
그렇다면, 본격적으로 Rewrite Map을 생성해 보겠습니다.
URL Rewrite를 선택해 주세요.
Manage rewrite map을 선택해 Rewrite Map을 생성합니다.
이렇게 이름을 “StaticRewrite”로 설정하고 “Add Mapping Entry”를 선택해 다음 Entry들을 넣습니다.
각각 값을 “/article1” 그리고 New Value를 “/article.aspx?id=1&title=some-title” 으로 지정합니다. 즉, /article1 요청이 들어오면 뒤에 나오는 URL로 rewrite 하라는 의미이지요.
| Original URL | New URL |
| /some-title | /article.aspx?id=1&title=some-title |
| /post/some-title.html | /article.aspx?id=1&title=some-title |
이런 형태로 값을 넣어 줍니다. 이어서 확인할 내용! 과연 이 매핑 정보는 어디에 저장될까요? 넵! 바로 web.config에 저장되게 됩니다. 어떻게? XML 형태로요.
1: <rewrite> 2: <rewriteMaps>3: <rewriteMap name="StaticRewrites" defaultValue="">
4: <add key="/article1" value="/article.aspx?id=1&title=some-title" />
5: <add key="/some-title" value="/article.aspx?id=1&title=some-title" />
6: <add key="/post/some-title.html" value="/article.aspx?id=1&title=some-title" />
7: </rewriteMap> 8: </rewriteMaps> 9: </rewrite>이렇게 보시는 것처럼 web.config에 차곡차곡 저장되게 됩니다. 주의해서 보실 것은 Rewrite Rule이 아니라 rewriteMap 하위에 저장된다는 것이지요.
그렇다면, 이 Rewrite Map을 어떻게 Rewrite Rule에 매핑 시킬까요? 바로 새로운 Rule을 만들고, 그 Rule에 이 Map을 걸어 주는 형태로 완성됩니다. 
”Add Rule”을 실행하고, Rule with rewrite map을 선택합니다. 
이어서 Rule Action은 “Rewrite”, rewrite map은 당연히 조금 전에 위에서 생성한 “StaticRewrite”를 선택 가능합니다.
그렇다면 확인을 위해 web.config를 열어 볼까요?
1: <rewrite> 2: <rewriteMaps>3: <rewriteMap name="StaticRewrite">
4: <add key="/article1" value="/article.aspx?id=1&title=some-title" />
5: <add key="/some-title" value="/article.aspx?id=1&title=some-title" />
6: <add key="/post/some-title.html" value="/article.aspx?id=1&title=some-title" />
7: </rewriteMap> 8: </rewriteMaps> 9: <rules>10: <rule name="Rewrite rule1 for StaticRewrite">
11: <match url=".*" />
12: <conditions>13: <add input="{StaticRewrite:{REQUEST_URI}}" pattern="(.+)" />
14: </conditions>15: <action type="Rewrite" url="{C:1}" appendQueryString="false" />
16: </rule> 17: </rules> 18: </rewrite>10번 라인부터 16번 라인까지 보시면 Rewrite Map을 처리하는 Rule을 확인 가능하지요.
11번 라인의 “<match url=".*" />”은 모든 인입되는 URL에 대해서 동작한다는 의미 입니다.
13번 라인의 내용은 StaticRewrite Map에서 리턴되는 값이 빈 문자열이 아니라는 조건 처리 입니다.
15번 라인의 Action은 이 Rewrite Map에서 나온 결과값으로 URL을 Rewrite하는 동작을 수행하라는 의미 입니다.
그렇다면, 우리가 만든 Rewrite Map이 잘 동작하는지 확인을 위해 테스트를 해 볼까요.
http://localhost/article1
http://localhost/some-title
http://localhost/post/some-title.html
위의 테스트 작업을 수행하면 아래처럼 결과가 잘 나오는 것을 확인 가능할 것입니다.
그렇다면, “Redirect”는 어떻게 처리 가능할까요? Rewrite와 같습니다. 
Rewrite Map을 Rule에 매핑하던 화면 기억 나시는지요? 여기에서 Rewrite 대신 Redirect를 선택하시면 됩니다.
마침 - Rewrite Map을 왜 사용하는가?
모든 URL 처리가 패턴 규칙으로 매핑 가능하지는 않습니다. 이렇게, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 여럿 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 단순 Rule들을 나열하는 것보다 부하를 줄일 수도 있다고 합니다.
이렇게 해서 전반적인 URL Rewrite 기능에 대해 알아 보았습니다. URL Rewrite만 해도 유용한 Fancy URL 제작 기능부터 보안 기능 등 다양한 내용이 포함되어 있는 것 같습니다. 이 외에도 IIS에 대한 수많은 유용한 기능들이 있는데요, IISKOREA 팀분들과 차근차근 좋은 내용으로 풀어 나가 보도록 하겠습니다. 감사합니다.
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
참고자료
서버주무르기 - IIS 7, URL Rewrite Module (URL 재작성 모듈)
Using Rewrite Maps in URL Rewrite Module
Using URL Rewrite Module
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 아파치(Apache) 웹서버에서 이용하는 Rewrite인 mod_rewrite 의 규칙들을 그대로 가져와 IIS에서 사용하는 방안에 대해서 소개해 드리려고 합니다.
간단히, 국내에서 많이 사용되는 PHP 어플리케이션인 텍스트큐브(Textcube) 나 XpressEngine(제로보드XE) 를 통해 말씀 드리자면, IIS의 URL Rewrite에 맞는 Rule을 제공하거나, .htaccess 파일에 존재하는 Rule을 그대로 가져와 URL Rewrite에서 이용 가능합니다.
XpresssEngine(제로보드XE)에서 URL Rewrite를 사용하는 방법- Import만 하면 순식간에 끝납니다!
XpressEngine의 경우 Rewrite를 이용하기 위한 설치 옵션이 있습니다. IIS에서 설치하실 경우에도 체크 하세요.
설치된 URL Rewrite를 실행하고 규칙 가져오기(Rule Import)를 진행합니다.
Import Rules을 선택하고
가져올 파일은 당연히 .htaccess의 파일을 선택합니다.
가져온 파일에서 이렇게 Import를 수행하고 적용하시면 끝~ 아파치 웹서버의 mod_rewrite rule 가져오기~ 참 쉽죠잉~
텍스트큐브(Textcube)에서 URL Rewrite를 적용하는 방법 – 설치시 옵션이 기본 제공됩니다.
텍스트큐브 설치 화면에서 이렇게 웹서버가 체크되면 IIS를 자동으로 인식해 IIS Rewrite Module 설치 가능 여부를 알려 줍니다. 텍스트큐브 조아요~
이렇게, IIS7을 선택해 주시고 다음을 누르시면 됩니다. 참고로, IIS6 등에서 이용 하실 경우에는 다른 URL Rewrite도 이용 가능하시지만, 권장해 드리고 싶지 않습니다.
지금 보고 계신 이 IISKOREA 팀블로그도 윈도우즈서버2008 웹에디션 + IIS7 으로 운영되고 있는데요. 텍스트 큐브 잘되고 좋네요.
이렇게 아파치(Apache) 웹서버에서 이용되는 mod_rewrite 규칙을 IIS의 URL Rewrite로 가져오는(Import)하는 방법에 대해서 알아 보았습니다. IIS의 URL Rewrite의 기능들을 이제 거의 알아보았는데요, 국내의 여러 멋진 오픈소스들과 함께 앞으로 유용하게 잘 사용되면 좋겠습니다.
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 ASP.NET 라우팅(Routing)과 URL Rewrite에 대한 내용입니다.
ASP.NET 라우팅이란 무엇인가?
URL Rewrite와 마찬가지로, ASP.NET에서 사용자 & 검색엔진 친화적인 URL을 이용 가능하도록 돕는 ASP.NET의 기능입니다. 대략 느낌이 오는 것처럼 .NET Managed Code와 Native Code의 차이점이 주가 될 것 같은 느낌이 들지요?
URL Rewrite는 왼쪽에서 보는 것처럼, HTTP 처리 파이프라인 중 “Begin Request” 영역에서 주로 처리되는 Native 처리기능을 수행합니다. 바꿔말하자면, HTTP 요청을 처리하는 절차들 중에서 비교적 앞쪽에서 일종의 Filter 형태로 동작하게 됩니다. ASP.NET 라우팅은 Managed Code로 작성되며 Resove Cache 처리와 Map Handler 처리에서 이루어지고 Execute Handler에서 역시 처리되게 됩니다. ASP.NET 라우팅 관련 내용은 아래 내용을 참고해 보세요.
링크 : ASP.NET 라우팅에 대한 상세한 정보
그렇다면, ASP.NET 라우팅과 URL Rewrite의 차이점은 무엇일까? 언제 URL Rewrite를 이용해아 하는지?
- URL Rewrite는 ASP, ASP.NET, PHP나 정적 HTML 파일(Static HTML file)과 같은 웹서버에서 처리되는 파일들에 대해서 동작 가능하다. 그러나, ASP.NET 라우팅은 오직 ASP.NET 웹 어플리케이션으로만 동작 가능하다.
- URL Rewrite는 도메인명, HTTP 헤더, 서버변수(Server variables)에 대해서 처리 가능하나, ASP.NET 라우팅은 URL Path와 HTTP Method 헤더에 대해서만 처리 가능하다.
- URL rewrite는 HTTP 리다이렉트(Redirect), 커스텀 상태코드(Custome status code), 요청 중단(Abort Request)가 가능하나, ASP.NET 라우팅은 이러한 처리를 하지 못한다.
- URL Rewrite는 제공되는 정해진 Rule 엔진(정규표현식 등)만을 이용해 처리 가능해 Rule에 대한 확장이 어려우나 ASP.NET 라우팅은 개발자가 얼마든지 기능을 확장하거나 커스터마이징이 가능하다.
이렇게 ASP.NET의 라우팅과 URL Rewrite의 차이점에 대해서 알아 보았습니다. 비슷한 역할을 하는 두 서비스는 각각 사용처가 어쩌면 명확해 보이네요. 감사합니다.
참조 : IIS URL Rewriting and ASP.NET routing
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 IIS7의 URL Rewrite 기능 세번째 시간으로, 요청필터링(Request Filtering) 기능과 URL Rewrite 기능에 대한 비교 내용입니다.
요청 필터링(Request Filtering)이 뭔가요?
요청 필터링은 IIS7에서 기본적으로 제공하는 보안 기능입니다. 혹시 아실지 모르겠습니다만, 이전에는 URLScan 이라는 녀석의 기능과 비슷하기도 합니다. 간단히 이녀석이 수행하는 기능은 IIS의 내장된 보안 기능으로 특정 URL이 들어올 경우 필터링, 특정 파일 확장자(Extension)을 요청할 경우 필터링, ASP.NET의 App_code와 같은 폴더에 대한 접근 필터링, HTTP 헤더의 길이 제한, HTTP의 특정한 verb에 대한 필터링 등이 가능합니다.
아울러, 요청 필터링은 이러한 보안 필터링 기능을 웹사이트단위 또는 웹서버 전체에 대해서 적용 가능합니다. 기존 URLScan3.0 버젼까지와는 약간 틀린 부분이지요.
참고로, 기존의 URLScan 3.0 버젼까지는 이러한 보안 기능들이 전체 웹서버에 대해서 적용되었습니다.
하지만, URLScan3.1부터는 보안기능들을 웹사이트 단위로도 구성이 가능하다고 하니 도움 되시길 바랍니다.
URLScan3.1 정보
요청 필터링에 대한 내용은 아래를 참고 하세요.
How to Use Request Filtering
Request Filtering <requestFiltering>
또 참고로, 요청 필터링을 IIS관리자에서 실행해 보고 싶으시다면?
먼저, IIS Administration Pack을 설치합니다. 
다운로드 링크에 가시면 웹 플랫폼 설치 관리자가 실행되고 여기에서 “관리 팩 1.0”을 설치하세요. 
그러면 IIS 관리자에서 Request Filtering을 수행 가능합니다.
자~ 그렇다면 다시 오늘의 주제인 요청 필터링과 URL Rewrite의 기능 비교에 대해서 알아 보도록 하지요.
요청 필터링과 URL Rewrite의 비슷한점은 무엇인가요?
두가지 기능 모두 URL이나 HTTP Request에 대한 보안 기능을 적용 가능하다는 점에서는 유사합니다. 하지만 아래와 같은 차이점이 있지요.
요청필터링은 순수한 보안 목적으로 제작되었습니다. URL Rewrite는 범용적인 URL 처리를 위한 목적으로 제작되었으며, URL Rewrite가 제공하는 보안 기능은 여러가지 기능들 중의 일부입니다.
간략히 표현된 요청 필터링과 URL Rewrite의 비교표 입니다. – 각각의 보안 기능들에 대해서 차이점이 존재 합니다.
그렇다면, 성능적인 측면에서는 어떨까요?
성능 측면에서는 두가지 기술 모두 영향을 줄 정도로 부하가 높지는 않습니다. 하지만, URL Rewrite의 경우 정규표현식을 이용하기 때문에 요청 필터링 보다는 약간 더 높은 시스템 리소스를 이용하게 됩니다. 요청 핕터링은 문자열에 대한 추출 작업만을 진행해 비교하기 때문에 시스템 리소스를 상대적으로 덜 사용하게 됩니다.
URL Rewrite와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능합니다. 많은 도움 되시길 바랍니다.
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
지난 포스트 링크
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치
지난 시간에 간략히 URL Rewrite의 역할과 기능을 소개해 드렸습니다. 이번 시간에는 URL Rewrtie를 실제로 사용해 보고 어떻게 이용하는지 간략히 설명 드리려고 합니다.
먼저, URL Rewrite를 왜 써야 합니까?
그렇다면 왜 URL Rewrite를 알아야 하는가? 간단하다, 다양한 웹 어플리케이션인 블로그나 CMS, 쇼핑몰 등도 Fancy URL과 Permanent Link가 제공하는 장점들을 기본적으로 제공하고 있다.
- XpressEngine
- Textyle
- Textcube
국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션들이며 모두 Rewrite 동작에 기반한 Fancy URL을 제공하고 있다. IIS7에서 역시 이러한 어플리케이션들을 구동시킬 수 있으며, 당연히 Rewrite 동작들을 어플리케이션들에 맞게 제공 가능하다. - Rewrite는 먼나라 이야기가 아니라, IIS를 운영하기 위한 필수적인 확장 기능이며, 당연히 IIS의 URL Rewrite는 국내 오픈소스 어플리케이션에서 제공하는 Rewrite Rule을 그대로 이용 가능하다.
Rewrite Rule 따라해보기
간단히 아래와 같은 역할을 수행한다고 가정해 보자.
Fancy URL http://localhost/article/342/some-article-title 을
http://localhost/article.aspx?id=342&title=some-article-title 으로 변환 하는 것이 목표다. – 그냥 보기에도 어려워 보인다. 흠…
Fancy URL인 위의 구조는 사람이나 검색엔진에는 친화적인 URL이지만, 개발자가 어플리케이션에 의해 처리되는 Request들을 받아 처리하기에는 적절하지 못하다.
당연히 Rewrite를 통해 Fancy URL을 재작성(Rewrite)하는 과정이 필요하다. 어떻게 진행 할 수 있을까?
<%@ Page Language="C#" %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>URL Rewrite Module Test</title>
</head>
<body>
<h1>URL Rewrite Module Test Page</h1>
<table>
<tr>
<th>Server Variable</th>
<th>Value</th>
</tr>
<tr>
<td>Original URL: </td>
<td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td></tr>
<tr>
<td>Final URL: </td>
<td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
</tr>
</table>
</body>
</html>
테스트를 위해 위와 같은 텍스트 파일을 생성하고, 파일 이름을 article.aspx 파일로 저장한다. 이후, IIS의 웹사이트 루트에 저장하도록 한다. 본인의 경우는 http://localhost/article.aspx 형태가 되도록 구성했다. 이어서 Rule을 작성해 보도록 하자.
그렇다면 Rule(규칙), Pattern(패턴), Action(동작)이란 무엇인가?
알아야할 세가지 키워드가 존재한다. Pattern은 URL의 패턴을 의미한다. 즉, URL이 abc.com/article/123/abcd 형태라고 한다면 서버의 DNS 주소 뒤에 article이 오고 숫자가 오고 문자가 오는 형태의 패턴이라고 말할 수 있다. 즉, 이런 패턴을 치환하는 동작이 바로 Action이라고 보면 된다. 이렇게 패턴에 따라 정의한 동작이 있는 것이 하나의 Rule이라고 보면 되며 이런 Rule들이 여러개 조건에 따라 존재할 수 있다. 이 Rule들을 관리하게 쉽게 돕는것이 바로 URL Rewrite라고 보면 된다.
URL Rewrite를 실행
웹사이트를 선택하고, 이렇게 URL Rewrite를 실행한다.
우측 상단의 Add Rule을 실행한다.
Blank Rule을 선택합니다. – 물론 필요할 경우 Template 등을 선택할 수도 있습니다.
이어서, 위와 같이 Rule을 구성합니다.
Pattern 부분을 주의해서 보시면
^article/([0-9]+)/([_0-9a-z-]+)
이런 내용이 보이는데요. 의미하는 바는
- 시작 문자열이 article로 시작되고
- 하나 이상의 숫자가 처음 “/” 부터 존재하고
- 하나 이상의 “_” 또는 “-” 또는 알파벳 문자열이 두번째 “/” 이후에 존재하는
패턴을 의미 합니다. 즉, 이런 패턴일 경우에만 이 Rule이 동작 하겠지요.
이어서 Action 부분을 주의해서 봐 보시면
article.aspx?id={R:1}&title={R:2}이런 내용이 보이는데요. {R:1}은 Rewrite된 패턴의 첫번째 리턴값, {R:2}는 두번째 리턴값이 들어간다고 보시면 됩니다.
URL Rewrite의 Rule은 어디에 저장 되는가?
IIS는 똑똑하게도 이러한 Rule을 기본적으로 웹사이트 루트디렉토리에 포함된 web.config에 저장하게 된다. 만약, 시스템 전체에 적용되는 Rewrite Rule을 이용하고 싶을 경우에는 당연히 시스템에서 구성하면 되며, 시스템에 구성한 Rule은 applicationhost.config에 저장되며 모든 웹사이트가 상속받아 실행하게 된다. 그렇다면, web.config에 저장된 rewrite rule은 어떤 모습일까?
1: <rewrite> 2: <rules>3: <rule name="Rewrite to article.aspx">
4: <match url="^article/([0-9]+)/([_0-9a-z-]+)" />
5: <action type="Rewrite" url="article.aspx?id={R:1}&title={R:2}" />
6: </rule> 7: </rules> 8: </rewrite>이런 형태로 web.config에 저장된다. 즉, URL Rewrite 툴은 이런 Rule을 쉽게 제작하도록 도와주는 툴인 것이고, 실제 동작은 IIS의 Filter로 동작하게 되는 것이다. 그렇다면, URL Rewrite를 실행해 보면?
테스트 URL : http://localhost/article/234/some-title
이렇게 Rewrite가 처리되는 것을 볼 수 있다. Fancy URL에 대한 처리가 이렇게 가능해 진다. URL Rewrite는 이렇게 URL을 재작성해 어플리케이션에서 이용 가능하도록 URL을 재작성한다. URL “Redirect”는 어떨까? Redirect는 URL을 아예 옮겨버리는 작업을 진행하는 차이점이 있다.
URL Redirect를 테스트 해 보도록 하자.
이런 URL을 http://localhost/blog/some-other-title/543
http://localhost/article/543/some-other-title 이런 URL로 Redirect 시키려 할 경우를 진행해 보면
Pattern :
^blog/([_0-9a-z-]+)/([0-9]+)
Action 을 “Redirect”로 설정하고 Redirect URL을 아래처럼 구성한다.
article/{R:2}/{R:1}
테스트를 하기 위해 아래 링크를 수행한다.
http://localhost/blog/some-other-title/323
브라우져의 결과가 Redirect되어 http://localhost/article/323/some-other-title 로 이동된 것을 확인 가능하다.
Access Block Rule을 이용할 수도 있다.
이 경우는 해킹 시도와 같이 호스트명으로 처리되는 요청이 아닌 IP로 요청되는 시도를 blocking 할 수 있는 Rule이다. 즉, http://123.123.123.123 과 같은 형태의 요청을 기본적으로 block하고 http://abc.com 형태로 요청될 경우에만 통과 시키는 규칙으로 구성가능하다.(당연하겠지만, 이런 형태의 방어 처리는 IIS의 바인딩 설정이나 URL Scan 등에서도 처리 가능하다)
1: <rule name="Fail bad requests">
2: <match url=".*"/>
3: <conditions>4: <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
5: </conditions>6: <action type="AbortRequest" />
7: </rule>- 2번 라인은 Rule이 모든 URL 스트링에 대해서 동작하라는 의미이다.
- 4번 라인은 HTTP_HOST 값이 “localhost”이 아닐 경우에 대한 조건 처리이다.
- 6번 라인은 조건일 경우 요청을 취소 시키는 처리이다.
테스트를 위해서 http://127.0.0.1/article/234/some-title 과 같은 IP로 요청을 수행할 경우 Request가 중단되는 것을 확인 가능하다.
이렇게 URL Rewrite의 핵심적인 3개 기능을 알아 보았습니다.
1. Rewrite 기능을 이용한 URL 처리
2. Redirect 동작
3. Access Block 처리
다음 내용에서는
- 요청필터링과 URL Rewrite 비교
- ASP.NET 라우팅과 URL Rewrite 비교
- Apache의 mod_rewrite Rule을 Import해서 처리 가능한 URL Rewrite의 import 기능
- Rewrite Map 이용
내용에 대해서 알아 보도록 하겠습니다. 감사합니다.
[지난포스트 링크]
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치
전선필 : Planning Your IIS 7.0 Architecture - IIS 아키텍쳐
김대우 : IIS7의 URL Rewrite 기능 – 김대우
발표자료는 아래 링크에서 다운로드 가능하며, 모두 PPT 파일과 XPS 파일로 공유해 드려요.
발표자료 다운로드
오늘도 좋은 하루 되시길 바랍니다.
더 많은 자료는 http://www.iiskorea.net 에서 보실 수 있습니다.
URL Rewrite의 기본 역할? 어디에 쓰는 건가요?
URL Rewrite는 사용자가 기억하기 더 쉽고, 검색 엔진에 의해 검색될 수 있도록 하는 URL을 만들어 주는 IIS의 확장기능(Extension) 입니다. Rewrite 본연의 기능을 보시려면, 아래의 화면을 통해 말씀 드리겠습니다.
이렇게 복잡한 URL 링크는 사용자나 검색엔진에게 친화적이지 않습니다. 보통 이런 URL을 Dirty Link 라고도 표현하는데요, 이를 보완하기 위해 아래에 보시는 깔끔한 링크처럼 사용자 편의적이고 검색엔진에 친화적인 URL로 만들어주는(Fancy URL) 기능이 바로 URL Rewrite가 지원하는 대표 기능입니다.(느끼시는 것처럼 그 외에도 다양하고 많은 기능들을 제공합니다.)
Rewrite에서 말하는 Rule 이란 무엇입니까?
이렇게, IIS Rewrite에서 특정 조건의 URL을 Fancy URL로 바꿔주는 하나하나의 규칙을 “Rule” 이라고 표현합니다.
Rule template이나 rewrite map 등을 쉽게 구축 가능하도록 돕는 이 기능은 HTTP 헤더의 URL과 서버변수(Server variable) 등에 대해서 처리가 가능하며 재정의된 응답을 사용자에게 내려 보내거나 HTTP 요청을 중지하는 다양한 규칙을 만들 수도 있으며, 보안 기능 등에도 활용 가능합니다. - 차근차근 보여 드리겠습니다.
URL Rewrite의 주요한 특징 및 기능
- Rule을 기반으로 동작해 다양한 로직이나 표현식, 개발 루틴 등을 이용 가능해 강력한 rewrite 처리가 가능하빈다.
- 정규 표현식을 이용 가능합니다. ECMA-262 호환 정규 표현식 구문을 사용 가능합니다.
- 와일드카드(wild card) 패턴 매칭을 이용 가능합니다.
- Rewrite는 HTTP 헤더에 기반한 URL과 서버변수(Server variable)에 대해서 처리합니다.
- 다양한 rule 동작을 제공해, 단순한 rewriting 뿐만 아니라, HTTP 리다이렉트, HTTP 요청 중지, 커스텀 상태 코드를 클라이언트에 전달하는 처리 역시 가능합니다.
- IIS 커널 모드와 User 모드 출력 캐시를 지원해 빠른 성능을 제공합니다.
- 문자열 처리 함수를 제공합니다. 기본 포함된 문자열 처리 함수들과 다양한 변환 함수 등의 Action 처리가 가능합니다.
- Rewrite map을 지원합니다. ? 이는 다수의 매핑 rule에 대한 정의가 편리합니다. GUI로도 생성 가능합니다.
- Rule 템플릿을 지원
- IIS의 관리툴과 완벽하게 상호 작용해 관리의 편의성이 높고 GUI 기반의 rule 생성, 체크 테스트,디버깅 등을 도와 줍니다.
- mod_rewrite의 rule도 손쉽게 GUI를 통해 import를 할 수 있습니다.
- 국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션의 rewrite rule도 완벽하게 지원합니다. 요것도 차근차근 보여 드리겠습니다.
URL Rewrite 다운로드
개인적으로는 웹 플랫폼 인스톨러(Web Platform Installer)-WPI 2.0을 이용해 다운로드 하실 것을 추천해 드립니다. 웹 플랫폼 인스톨러 http://www.microsoft.com/web/downloads/platform.aspx
웹 플랫폼 인스톨러는 윈도우 서버에서 사용되는 모든 웹 플랫폼 프레임워크, 웹 어플리케이션, IIS 확장 기능 및 SQL서버와 같은 제품 등에 대한 설치와 구성을 돕는 최고의 툴입니다. ? IIS로 웹 어플리케이션을 구동하기 위한 최적의 툴이지요.
웹플랫폼 - 웹서버의 사용자 지정 - 일반 HTTP 기능에서 설치 가능합니다.
또는 http://www.iis.net/extensions/URLRewrite 링크에서 다운로드 가능합니다. X86용과 X64용이 모두 제공되는 적절한 파일을 받으시면 됩니다. 더 많은 다양한 IIS 관련 강좌는 IISKOREA 커뮤니티 http://www.iiskorea.net 에서 확인 하실 수 있습니다.
Comments