Tomcat 설정 파일

Tomcat 설정

◎ Tomcat 설정 파일

Tomcat 관련 설정 파일들은 이전에 Tomcat 설치를 진행하며 간단히 설명을 하긴 했지만 여기에 다시 정리하겠다.

• server.xml : Tomcat의 메인 Config 파일. Catalina 초기 상태 및 부팅, 구성 요소의 빌드 순서 등을 정의한다.
• tomcat-users.xml : Tomcat 서버의 많은 유저들에 대한 Username, 패스워드 및 Role에 대해 정의한다.
• web.xml : 버퍼 크기, 디버깅 레벨 등의 Jasper 옵션, MIME 유형 및 웹페이지 Index 파일 같은 Servlet 정의를 포함하여 Tomcat Instance에 로드되는 모든 응용 프로그램에 적용되는 설정이다.
• context.xml : Tomcat에 구동되는 애플리케이션(프로그램)에 적용될 설정들을 정의한다.
  • context.xml은 프로그램 전체에 적용될 설정, web.xml은 로드되는 페이지 1개에 적용되는 설정이라고 생각하면 된다.

특히 Tomcat Server의 메인 설정이라 할 수 있는 server.xml 파일을 분석해 볼 필요가 있다.

아래 설명할 Option 외에도 다른 여러가지 Option이 존재하지만 필자는 핵심 설정 몇 가지만 알아보겠다.

 

0. 카탈리나(Catalina)

Tomcat에 대해 본격적으로 알아보기 전 Tomcat Catalina에 대해 알아볼 필요가 있다.

 

Tomcat은 여러 가지의 Engine으로 이루어져 있다. 대표적으로 JSP 페이지 요청을 처리하는 서블릿인 Jasper, TCP를 통한 프로토콜을 지원하는 Coyote, 그리고 Java Servlet을 호스팅 하는 Catalina가 존재한다.

 

Coyote가 HTTP 요청을 받아 Catalina 서블릿 컨테이너에게 요청을 전달하면 Java 웹 애플리케이션에서 이를 해석하고 Jasper에 처리한 데이터를 반환한다.

이후 Jasper가 받은 데이터를 활용해 JSP 요청을 처리하는 과정으로 Tomcat이 동작한다.

 

여러 가지 기능 중 Core Engine이라고 할 수 있는 것이 Catalina로써 톰캣 서버를 가동시킨다는 것은 곧 Catalina를 구동시킨다는 것과 동일한 의미이다.

(참고로 서블릿 컨테이너 디자이너 Craig McClanahan이라는 사람이 카탈리나 섬을 사랑하셔 Catalina라는 이름이 지어졌다고 한다)

 

1. <Server>

<Server port="8025" shutdown="SHUTDOWN">

최상위 Element로써 Shutdown 요청 처리를 위한 설정을 가지고 있다.

• port : 톰캣 종료 전용 포트
• shutdown : 종료 명령

 

2. <Service>

<Service name="Catalina">

<Connector>와 <Engine>으로 구성되어 있는 설정으로써 클라이언트의 요청(Request) 처리 정보를 담는다.

대부분 name="Catalina"로 설정하여 활용한다.

 

2.1 <Connector>

클라이언트의 요청(Request)을 수신하고 응답(Response)을 전송할 인터페이스 정보이다.

<Connector port="8020" protocol="HTTP/1.1" URIEncoding="UTF-8" connectionTimeout="20000" 
              								        redirectPort="8443" />

• URIEncoding : 클라이언트에서 보내는 Request 인코딩 방식
• Protocol : Connector가 사용할 프로토콜 버전
• port : 톰캣이 Request를 Listen할 TCP Port
• connectionTimeOut  : port에 TCP 연결 요청이 도착한 후 모든 Request 패킷이 올 때까지 대기하는 시간
• redirectPort  : connectionTimeout 설정 시간이 지났을 경우 Redirect 되는 Port 번호

connectionTimeout과 RedirectPort를 활용하여 무조건 https://로 Redirect되도록 설정할 수도 있다.

 

2.2 <Engine>

<Engine name="Catalina" defaultHost="localhost">

클라이언트가 서버에 요청을 보내면 Engine에서 이 요청을 확인한다. 이후 Engine은 Request에 포함된 HTTP Header를 분석해 이 요청을 처리할 Host(프로그램)로 전달해 준다.

• name : Request를 확인할 Engine 이름
• defaultHost : 접속 시 기본값으로 대처할 호스트
• jvmRoute : 로드 밸런서가 여러 Tomcat 인스턴스를 구분하기 위해 사용

위에서 말했듯 Java 프로젝트의 경우 Catalina 서블릿 컨테이너에서 Request를 처리하므로 name을 Catalina로 설정했음을 확인할 수 있다.

 

2.3 <Realm>

<Realm className="org.apache.catalina.realm.LockOutRealm">
     <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>

보안을 위하여 Role이나 사용자 이름, 비밀번호 매핑을 외부 DB에서 가져오는 장치이다.

tomcat은 UserDataBase, Memory, JDBC, JNDI 등 몇 개의 <Realm>을 가지고 있다.

Realm 종류는 어디로부터 정보를 가져왔는지의 차이만 존재하며 주로 UserDataBase 이외의 <Realm>은 주석 처리를 통해 무효 처리되어 있다.

 

2.3 <Host>

<Host name="sample.com" unpackWARs="true" xmlValidation="false">

 

아마 server.xml의 핵심 부분이 아닐까 싶다.

이 <Host>와 <Host>의 Sub Config들을 잘 알아야지만 나중에 설명할 내용들을 이해할 수 있다.

 

긴 설명을 하기 전 몇 가지 Option들을 설명하고 가자.

• name : 특정 Host name으로 요청이 올 경우 해당 name을 가진 Host가 Request를 처리함
• appBase : Host의 Web Root Directory. 지정하지 않을 경우 Root Directory
• unpackWars : war 파일로 배포시킬 경우 "false", 압축을 푼 후 배포시킬 경우 "true"로 설정해야 프로그램 실행 가능
• xmlValidation : "true"일 경우 web.xml 및 web-fragment.xml 파일의 구문 분석 시 XML 검증 Parser가 사용됨. 하지만 이 특성이 True일 경우 성능 저하가 발생함

여기에서 중요한 것이 "name"의 설정이다.

 

먼저 Host 중 무조건 <Engine>의 defaultHost와 동일한 Name을 가진 Host가 존재해야 한다.

즉, 위에서 <Engine name="localhost">로 설정되어 있으므로 <Host name="localhost">라는 값을 가진 Host도 존재해야 한다.

 

두 번째로 2개 이상의 Host를 사용할 경우 무조건 defaultHost를 사용하는 것이 아닌 Request의 목적지로 지정된 Host name을 가진 Host 프로그램이 Request를 처리한다는 것이다.

예를 들어 "localhost", "sample.com", "test.com"이라는 name의 Host가 존재한다고 가정하자.

이 경우 "sample.com"으로 웹 서버에 접근할 경우 defaultHost인 "localhost" 설정이 아닌 "sample.com" Name을 가진 Host가 실행하는 프로그램에서 Request를 처리한다는 것이다.

 

이를 활용하면 1개의 Tocmat에 여러 개의 war 파일을 실행할 수 있게 되는 것이다.

 

2.3.1 <Context>

<Context path="" docBase="/home/sample/www" reloadable="false" useHttpOnly="true">

Host Config의 Sub Config이자 Tomcat의 감초 역할을 담당하는 <Context>이다.

<Host>의 설정과 <Context>가 합쳐져 Request를 처리할 프로젝트의 위치 및 처리 방식이 완벽히 정해진다고 할 수 있다.

 

Context 가 생략될 경우 path="/", war 파일 명은 ROOT.war로 정해져 있다.

• docBase : 기본 값은 ROOT이다. 해당 Directory 내부에 있는 war 파일 혹은 압축이 풀린 war 파일(컴파일 파일) 프로젝트가 Request를 처리한다.
• path : Default Path
• reloadable : reloadable=true일 경우 일정 주기마다 ROOT경로의 class 파일 변경여부를 확인한 뒤 자동으로 재기동하여 리로드 시켜준다. 
• useHttpOnly : Https를 활용하지 않음

최종적으로 모든 Host는 "[appBase]+[docBase]" 위치에 존재하는 프로그램이 Request 처리를 수행한다고 생각하면 된다.

 

path 같은 경우 Default Path라고 설명해 놓아 약간 이해가 어려울 수 있다.

예시를 들면 바로 알 수 있을 것이다. 예를 들어 Host name이 "www.sample.com"인 경우에 path="/target"이라고 설정했다 가정하자.

이 경우 "www.sample.com"의 Index Page에 접근하기 위해선 "www.sample.com/target"으로 접근해야 한다.

즉, 웹 프로젝트에 접근하기 위한 기본 URL은 "www.sample.com/target"으로 설정되는 것이다.

 

reloadable=true로 설정할 경우 일정 주기마다 자동으로 변경 여부를 파악하므로 사용성이 좋다고 생각할 수 있다.

하지만 자동 리로드 시 기존 클래스 파일을 메모리 상에서 지워버리는 게 아니라 기존 클래스 파일을 백업 파일로 만든 뒤 신규 클래스 파일을 위한 메모리를 새롭게 할당하여 사용하는 방식이므로 OOM 문제가 발생할 수 있다.

따라서 reloadable=true를 사용하더라도 주기적으로 서버를 재시작시켜줘야 한다.

또한 Jenkins를 통한 자동 배포 시 오류가 발생할 수 있어 reloadable=false로 설정하는 경우가 더 많다.

 

2.3.2 <Valve>

<Valve className="org.apache.catalina.valves.AccessLogValve" 
                directory="logs" prefix="access_log." suffix=".txt" 
                timestamp="true" pattern="common" resolveHosts="false"/>

Client의 요청을 처리하는 과정 중 특정 기능을 수행하게 하는 요소로써 특히 로그 파일을 남길 목적으로 자주 사용된다.