Category: WAS

WAS 에 대한 카테고리

JBOSS EAP 6 Standalone 환경 구성하기

JBOSS EAP 6 설치를 끝내고 나면 Standalone 이나 Domain 모드로 운영하기 위한 환경 구성을 해야 한다. JBOSS EAP 6 Standalone 환경 구성은 설치한 JBOSS 에서 Standalone 디렉토리를 복사해서 구성하게 된다.

JBOSS 를 설치는 JBOSS_HOME 을 설치하는 것이다. 이것 자체로 서버를 운영할수 있지만 이것을 GLOBAL 로 하고 각각의 운영위한 서버는 JBOSS_HOME 에 Standalone, Domain 디렉토리를 복사하고 Localize 해서 만들어진다. 이는 마치 Tomcat 의 Multi Instance 구성하기와 유사하다.

기본환경

먼저 기본적인 환경을 체크하고 넘어가자. 다음과 같다.

  • Linux: CentOS 6, 7
  • JAVA_HOME: /opt/jdk1.8.0_91
  • JBOSS_HOME: /opt/EAP-6.4.0

기본적으로 위와 같은 환경이 기본으로 갖추고 있어야 한다. 이를 기반으로 서비스를 위한 Local 서버를 구성할 수 있게 된다.

Command Line Parameter

JBOSS EAP 6 는 독자적인 서비스 노드를 구성하기위해서 Command Line Parameter 를 제공한다. 이를 이용하면 JBOSS EAP 6 에게 값을 전달할 수 있고 JBOSS EAP 6 행동을 제어할 수 있게 된다. 유용한 Command Line Parameter 는 다음과 같다.

Standalone

속성 이름사용법기본값
java.ext.dirsJDK 확장 디렉토리 경로null
jboss.home.dirJBOSS EAP 6 설치된 ROOT 디렉토리$JBOSS_HOME 환경변수로 standalone.sh 파일에 지정되 있음
jboss.server.base.dir서버 컨텐츠를 위한 기본 디렉토리jboss.home.dir/standalone
jboss.server.config.dir기본 설정 디렉토리jboss.server.base.dir/configuration
jboss.server.data.dirpersistent 데이터 파일 스토리지를 위해 사용되는 디렉토리jboss.server.base.dir/data
jboss.server.log.dirserver.log 파일을 가지는 디렉토리jboss.server.base.dir/log
jboss.server.temp.dir임시파일 스토리지를 위한 디렉토리jboss.server.base.dir/tmp
jboss.server.deploy.dir배포된 컨텐츠를 저장하하는데 사용되는 디렉토리jboss.server.base.dir/deployments

위 파라메터는 standanlone.sh 스크립트를 시작할때에 명령행 인자로 줄수 있다. 다시 바꿔 말하면 쉘 환경변수로 저장해 놓고 사용할 수 있다는 걸 의미한다.

이제 본격적으로 독자적인 서비스 노드를 구성해 보자.

독자적인 서비스 노드 구성

독자적인 서비스 노드를 구성하기 위해서 시스템 계정을 하나 만들고 JBOSS_BASE_DIR 로 쓰일 nodes 디렉토리를 생성한다.

그리고 JBOSS_HOME 디렉토리에 standalone 디렉토리를 /home/jboss/nodes/node1 으로 복사한다.

WAS 서비스를 위해서 JBOSS_HOME 을 이용하는게 아니라 node1 을 이용하게 하는게 목적이다. 모든 서비스는 node1 을 통해서 이루어진다. WAS 의 설정, 컨텐츠 배포, 또 다른 WAS 와 연동등도 모두 node1 을 통해서 이루어지게 된다. 결국에는 JBOSS_HOME 은 일종의 라이브러리와 같은 역활을 담당하게 된다.

그렇다면 node1 을 구동시키기 위한 스크립트가 필요하다. 그리고 이러한 스크립트는 앞에서 설명한 Command Line Parameter 를 이용해서 구동환경을 조성하게 된다.

구동 스크립트

구동스크립트를 만들때에는 다음과 같은 세가지 영역을 포함한다.

  • JBOSS 를 위한 변수
  • JVM  옵션 변수
  • 시작 스크립트

각각의 영역은 파일로 작성되어지고 시작스크립트에서 호출되어서 사용되어지게 될 것이다. 앞으로 작성하게될 파일들의 목록은 다음과 같다.

  • jboss-env.conf
  • jboss-env.sh
  • jboss.properties
  • jvm-env.conf
  • jboss-run.sh
  • jboss-cli.sh

한가지 덧붙이자면, 꼭 이렇게 파일들을 조각낼 필요는 없다. 조각난 파일들로 인해서 오히려 효율이 떨어지고 실수가능성이 높아지는 경우도 많다. 하나의 파일에서 모두 다 처리해도 상관이 없다.

jboss-env.conf

이 파일은 JBOSS EAP 6 를 위한 환경 변수들을 정의한다. 그 내용은 다음과 같다.

이 파일은 시스템 환경변수를 지정하는데 있다. 이러한 시스템 환경변수는 나머지 환경파일이나 실행스크립트에서 활용하게 된다.

내용을 간단하게 보면 JBOSS_HOME 과 JBOSS_NODE_BASE_DIR 를 정의해주고 있다. 그리고 JBOSS EAP 6에서 이용할 각종 포트와 주소들도 함께 정의해주고 있다.

jboss-env.sh

이 파일은 실제 JBOSS EAP 6 에 명령행 파라메터를 작성한다. 내용은 다음과 같다.

jboss-env.conf 파일에서 정의한 환경변수들을 사용하고 있다.

jvm-env.conf

이름에도 알수 있듯이 jvm 설정을 위한 내용을 담고 있다. 내용은 다음과 같다.

JVM 이 사용할 메모리양과 GC 종류를 정의해주고 있다.

jboss-run.sh

이 파일은 독자적인 서비스 노드인 node1 을 시작하고 중지시키기위한 스크립트이다. 위에서 설명한 모든 파일들을 Source 해 사용하고 JBOSS EAP 6 가 제공하는 레드햇 계열의 init 스크립트를 활용한다. JBOSS EAP 6 를 설치를 하고 나면 JBOSS_HOME/bin/init.d 디렉토리에 레드햇 계열 리눅스를 위한 서비스 시작, 중지 스크립트가 있다. jboss-run.sh 는 위에서 기술한 모든 환경변수 세팅 파일들을 읽어서 최종적으로  JBOSS EAP 6 의 init 스크립트를 실행시키게 된다. 내용은 다음과 같다.

맨 마지막이 바로 JBOSS EAP 6 에서 제공하는 init 스크립트를 호출하는 부분이다. $1 인자값은 start, stop 등으로 시작과 중지를 시킬수 있도록 했다.

jboss.properties

이 파일은 key=value 형태로 값을 지정하고 JBOSS EAP 6 실행시 값을 반영할 수 있게 해준다. 이는 명령행 인자 전달과 동일한 효과를 내지만 오로지 JBOS EAP 6 속성만을 지정해야 한다. 명령해 인자 파라메터는 정확하게 JBOSS EAP 6 에 전달하는것이 아니라 JVM 으로 전달해 JBOSS EAP 6 이 그것을 읽는 방식일 취한다.

어쨌든, jboss.properties 의 내용은 다음과 같다.

jboss-cli.sh

JBOSS EAP 6 로 넘어오면서 많은 변화가 있었지만 그중에 하나가 바로 명령행 콘솔에서 JBOSS EAP 6 을 제어할 수 있다는데 있다. 이것은 JBOSS_HOME/bin/jboss-cli.sh 파일을 통해서 실행되는데, 여기서 jboss-cli.sh 파일을 별도로 만드는 이유는 node1 에 맞추기 위해서다. 내용을 보면 이해가 될 것이다.

node1 을 위한 jboss-env.sh 를 소스하고 있다. 이렇게 함으로써 node1 을 위한 환경변수들을 사용해 node1 을 위한 명령행 콘솔로 진입하게 된다.

정리

지금까지 기술한 것을 정리하면 다음과 같다.

  • /opt/EAP-6.4.0/standalone 디렉토리를 /home/jboss/nodes/node1 으로 복사
  • node1 안에 위에서 기술한 파일들을 작성

시작, 중지

이제 모든 파일을 다 만들었다면, node1 서비스를 시작, 중지 시켜보자. 시작과 중지는 다음과 같이 한다. 참고로 이 스크립트의 실행은 반드시 슈퍼유저인 root 로 해야한다.

init 스크립트를 이용하기 때문에 자동으로 백그라운드로 전환되고 화면에는 아무것도 나오지 않는다. 구동시에 화면에 뿌려지는 내용은 로그로 기록된다.

중지는 다음과 같이 한다.

정상적으로 종료 되는 것을 볼 수 있으며 보다 자세한 내용은 로그를 보면 된다.

JBoss EAP 6.4 설치

 JBoss EAP 6.4 설치

JBoss EAP 6.4 설치에 대해 다룬다. JBoss EAP 6.4 설치는 GUI와 Text 기반 설치 두가지를 지원 한다. 여기서는 Linux 터미널에서 Text 기반 설치에 대해서 다룬다.

사전준비

JBoss EAP 6.4 를 설치하기 위해서는 JDK 1.7 이상 필요하다. JDK 1.6도 지원한다고 되어 있지만 현시점(2016. 06) 에서 1.6은 너무나 구형이라 권장하지 않는다.

설치를 위해서는 설치 파일이 필요한데, zip 파일과 installer 파일 형태로 제공된다. zip 파일은 그냥 압축해제하면 되지만 installer 는 인스톨 과정을 거쳐야 한다. 여기서는 installer를 이용한 설치에 대해서만 다룬다.

설치

설치 레이아웃은 다음과 같다.

  • JBOSS_HOME: /opt/EAP-6.4.0
  • JAVA_HOME: /opt/jdk1.8.0_40

JBoss EAP 6.4 의 인스톨 파일은 jboss-eap-6.4.0-installer.jar 이다. Text 기반으로 설치를 위해서는 다음과 같이 명령어를 쳐주면 시작된다.

설치 중간중간에 관리자가 선택해야할 사항들이 존재한다. 설치할 패키지들 목록과 포트 설정, 서버 설정, 로깅 설정등을 보다 디테일하게 할 수도 있다.

삭제

삭제는 설치한 디렉토리를 삭제하면 되지만 uninstaller 를 제공한다. EAP_HOME 디렉토리에 Uninstaller 디렉토리에 보면 uninstaller.jar 파일을 제공한다. 역시 Text 기반 삭제는 다음과 같이 하면 된다.

 

JBoss 5 MySQL Replication 접속

Jboss EAP

만일 MySQL 이 Replication 되어 있다고 한다면 Master 는 read/write 를 Slave 는 read Only 만 하도록 접속을 하고 싶을 것이다. MySQL Connector/J 의 최신버전은 이러한 접속을 지원 한다.

다음은 MySQL Replication 접속을 위한 mysql-ds.xml 예제다.

‘connection-url’, ‘driver-class’ 을 유심히 봐야 한다.

mysql-ds 에서의 설정은 MySQL 의 접속을 이중으로 하도록만하고 실제 쿼리를 분기하기 위해서는 DAO 에서 @Transactional(readOnly=true) 를 주어야 한다. 이 어노테이션은 읽기만을 하다는 것을 알려주고 이는 MySQL Slave 에 접속하게 된다.

각 메소드마다 어노테이션을 주기 싫다면 AOP 를 이용하는 방법도 있다.

service 클래스에 get* 메소드들에는 자동으로 read-only=true 가 설정된다. 이렇게 되면 쿼리를 보낼때마다 Slave 서버에 보내게 되어 쿼리연산이 분산된다.

JBoss EAP 5 MySQL JNDI 설정

Jboss EAPJNDI 는 자바 애플리케이션 서버라면 거의 다 지원하는 기능이다. 이는 특정한 자원의 접근을 디렉토리 접근하듯이 하도록 해준다. 여기서 자원이라면 대부분 외부 서버에 있는 저장소들을 말한다.

MySQL, PostgreSQL, Oracle, MS SQL 등 외부 저장소에 접속할때마다 저수준의 드라이버를 올리고 인증을 넣는게 아니라 자바 애플리케이션이 구동되면서 접속하을 해놓고 이것을 디렉토리화해서 올려놓으면 자바 애플리케이션에서는 이 디렉토리에 접근하는 것만으로 외부자원에 접속이 끝이 나게 되어 간편해진다.

이 글은 JBoss EAP 5 MySQL JNDI 설정에 관한 글이다.

MySQL Connector/j

MySQL에서는 자바 애플리케이션을 위해서 접속 드라이버를 제공한다. jar 파일로 작성되 배포되고 있어 다운받아서 지정된 위치에 넣기만 하면 된다.

JBoss EAP 5 는 글로벌 library 디렉토리, Node Library 디렉토리가 존재하는데 node 디렉토리에 다운받아 넣는다. 다시말하면, Jboss EAP 5 의 경우에, jboss-as/server 아래에보면 all, default, production, standard 등의 디렉토리가 보이는데 이걸 node 라고 한다. 여기서 나는 all node 에 lib 디렉토리에 MySQL Connector/J 를 넣어주면 된다.

현 시점에서의 버전은 5.1.39 이다.

 

MySQL DataSource

이제 JBoss 에 MySQL DataSource 를 설정해준다. 앞에서 잠깐 말했지만 특정 node 에 설정을 해주게되는데 나는 all 노드에 설정을 할 것이다.

일단 mysql-ds.xml 파일을 다음과 같이 작성한다.

  • 11번째 줄이 아주 중요하다. JNDI 이름인데, 이 이름을 가지고 자원을 호출하게 된다.
  • 12번째 줄은 접속 서버 정보이다. 호스트네임이나 IP주소, 접속 데이터베이스명을 적어주면 된다. Unicode 와 CharacterEncoding 은 옵션으로 MySQL 서버와 맞게 설정해 주어야 한다.
  • 14번, 15번 줄은 접속을 위한 인증정보를 적어준다.

이걸 mysql-ds.xml 로 저장한 후에 $JBOSS_HOME/server/all/deploy/ 디렉토리에 넣으면 된다.

애플리케이션 WEB-INF/jboss-web.xml 작성

자바 애플리케이션을 작성할때에 WEB-INF 디렉토리를 만나게 된다. Deployment Descriptor 로 정의되는 web.xml 파일이 위치하는 디렉토리다. 여기에 jboss-web.xml 파일을 다음과 같이 작성한다.

  • 12,13 줄이 아주 중요하다. JNDI 명을 적어주는데, 앞에 mysql-ds.xml 파일에서 설정한 이름만 적어주는게 아니라 jdbc, java: 등을 함께 적어준다. 이거 의외로 안 적어주고 안된다는 사람이 많으니 주의해서 적어주자.

애플리케이션 WEB-INF/web.xml 작성

Deployment Descriptor 파일로 불리우는 web.xml 파일에 다음과 같은 내용을 추가해준다.

  • 5줄 에 JNDI 이름을 적어준다. jdbc/ 를 꼭 붙여준다.

여기까지가 JNDI 설정에 관한 것이다. 이 이상은 프로그래머가 사용하는  ORM 에 따라서 JNDI 호출 방법이 달라진다. 하지만 JBOSS 에서 JNDI가 잘 설정되어 있는지를 살펴볼 수있다.

root Context 설정

이제 애플리케이션에서 JNDI를 설정해 보면 다음과 같다.

jndiName 설정을 어떻게 하는지 주의깊게 봐야 한다.

 

확인하기

설정한 JNDI가 잘 설정되었는지는 맨 처음 JBoss 를 시작할때에 로그에 나온다.

이것은 JNDI 설정 파일을 읽었을 뿐 실제로 접속이 잘되는지를 나오지 않는다. 이는 JBoss Admin Console 를 통해서 가능하다.

JBoss Admin Console JNDI 확인

위 그림과 같이 Test Connection 을 클릭하면 접속 테스트를 해준다.

JBoss Admin Console JNDI 접속 실패

위 그림을 보면 Status 가 성공으로 나와서 접속 성공한으로 착각하는데, 이것은 Test Connection 명령이 성공했다는 것이고 그에 대한 결과는 그 아래에 위와같이 나온다. 위 경우에 접속 실패.

이것저것 문제를 해결한 후에 다시 Test Connection 을 하고 성공하면 설정이 정상적으로 된것이다.

 

Ubuntu 14.04 의 JBoss EAP 5.2 init 스크립트

JBoss EAP 5.2 를  Ubuntu 14.04 에서 운영할 경우에 서비스 시작을 init 에 등록하기 위한 스크립트. Wildfly 에 내용을 가지고 와서 마이그레이션 했다.

아래는 jboss-env.sh 의 내용.

 

TCP 기반 JBoss 5 Clustering 하기

Jboss EAPAWS EC2 에서 JBoss EAP 5.2 를 설치하고 운영할때에 보통 클러스터링을 설정하게 된다. 문제는 JBoss EAP 5.2 에서 클러스터링은 JGroup 을 기반으로 작성되어 있다. 중요한 것은 클러스터링을 할때에 Multicast UDP 를 사용한다는 것인데, AWS EC2 에서는 Multicast 자체를 지원하지 않는다. 따라서 JBoss EAP 5.2 를 AWS EC2 에서 운영하면서 클러스터링을 기본 설정값으로 설정하고 실행시키면 클러스터링이 되지 않는다.

이럴때 TCP 를 이용하면 가능해진다. 이 포스트는 AWS EC2 에서 TCP 기반 JBoss Clustering 에 관련된 내용이다.

MPING을 TCPPING으로 바꾸기

Cluster 의 프로토콜 설정은 다음의 파일에 정의되어 있다.

  • deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml

여기에 TCP 스택 부분에 보면 MPING 설정부분을 코멘트처리하고 TCPPING부분을 언코멘트해준다.

여기서 핵심이 jboss.jgroups.tcp.tcpping.initial_hosts:localhost[7600],localhost[7600] 부분이다. 이부분은 도메인을 입력해줘야 하는데, 대부분 /etc/hosts 파일에 아이피와 짧은 도메인명으로 정의를 해준다.

이렇게 주석을 해제해준 상태에서 JBOSS 옵션으로 -Djboss.jgroups.tcp.tcpping.initial_hosts=node1[7600],node2[7600] 을 주게 되면 두개의 node 가 TCPPING 으로 묶이게 된다.

Cache 매니저에서 jgroup 스택 프로토콜 바꾸기

이것은 다음의 파일에 정의 되어 있다.

  • deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml

이 파일에서 jboss.default.jgroups.stack:udp 를 jboss.default.jgroups.stack:tcp 로 모두 교체해준다.

하지만 이 방법외에도 JBOSS 옵션으로 -Djboss.default.jgroups.stack=tcp 를 정의해주고 인스턴스를 시작해주면 적용된다.

JBoss Messaging 을 TCP 로 바꾸기

JBoss Messaging 을 TCP 로 바꾸기 위해서 다음 파일을 열어서 다음과 같이 변경해 준다.

이 옵션 변경은 커맨드라인으로 제공하지 않기 때문에 반드시 수동으로 이 파일을 편집해 줘야 한다.

JBOSS 시작 옵션으로 설정하기

위 파일들을 바꾸는 대신에 다음과 같이 시작과 같은 옵션만으로 TCPPING 으로 바꿀 수 있다.

이 옵션 설정은 매우 중요하다.

먼저, jboss.messaging.ServerPeerID 는 반드시 Cluster 내에서 유일해야 한다. 중복되면 서버 시작시에 오류갈 발생된다.

jboss.service.binding.set 은 default 포트를 기준으로 상대적으로 포트를 할당한다. default 는 각종 서비스 포트에 기본 값으로 Cluster 의 경우에는 7600 포트, HTTP 는 8080 이다. ports-01 은 default 보다 100 을 더해서 Cluster 는 7700, HTTP 는 8180 이된다.

위 jboss.service.binding.set 은 jboss.jgroups.tcp.tcp_port 와 혼동이 될 수 있다. 예를들어 ports-01 인상태에서 tcp_port=7600 으로 했다면 100을 더해서 7700 이 된다. 하지만 ports-01 인 상태에서 tcp_port=7700 이면 실제 Cluster TCP 포트는 100을 더한 7800 이 된다. 결론적으로 tcp_port 의 실제 값은 지정한 값에 binding.set 값을 더한 값으로 된다.

jboss.jgroups.tcp.tcpping.initial_hosts 는 binding.set 과 tcp_port 값을 더한 포트 값을 적어주면 된다. 왜냐하면 이게 실제로 사용되어지는 포트가 되니까 결국에는 이곳의 포트값은 실제로 서버에서 사용되어지는 Cluster Port 값을 적으면 된다.

주의사항

이 설정을 테스트 하기위해서는 서로 다른 머신이 있어야 한다. 같은 서버상에 인스턴스를 두개를 실행시켜서하면 안된다. 반드시 서로 다른 서버에 인스턴스와 테스트를 해야지 성공한다. 이유는 아직 나도 잘 모르겠다.

Apache Tomcat 연동하기 – mod_jk

Tomcat 을 단독으로 운영하지는 않는다. 여러 서버에서 설치한 후에 이것을 부하분산하는 방법으로 운영하는데, 자주 쓰이는 방법이 Tomcat 앞단에 Apache 웹 서버를 두고 이 둘을 연결해주는 방법으로 사용을 한다.

이때 연결방법이 여러가지가 있는데, Tomcat 과 Apache 를 위한 전용의 모듈이 있는데 그것이 바로 mod_jk 이다. mod_jk 는 AJP 프로토콜을 사용해서 이 둘을 연결해주는데, 다른 연결들보다 성능이 우수하다.

환경

이번 테스트한 환경은 다음과 같다.

  • OS: CentOS7 x86_64
  • Java Version: jdk-1.8.0_u65
  • WAS: Tomcat 8.0.30

그리고 서버는 한대이고 Tomcat 을 여러개 설치했다. 이때에 하나의 Tomcat 을가지고 멀티인스턴스 생성방법을 사용했다. 각각의 WAS 서버의 정보는 다음과 같다.

  • instance1, 8109 AJP Port
  • instance2, 8209 AJP Port
  • instance3, 8309 AJP Port

Apache 웹 서버는 CentOS 7 에 Yum 을 이용해서 설치했다. 이때 설치할때에 “httpd-devel.x86_64” 도 함께 설치해줘야 한다.

mod_jk 설치

mod_jk 는 Apache 홈페이지에서 다운로드 가능하다.

설치는 apxs 를 이용해서 Apache 모듈로 설치를 해주면 끝나게 된다.

위와같이 오류없이 libtool 로 설치가 완료되면 정상이다.

mod_jk 설정

mod_jk 에 대한 설정은 기본적으로 두가지 측면에서 이루어진다. 첫째는 Apache 웹서버에서 mod_jk 를 핸들링을 어떻게 할건지에 대한 설정이고 두번째는 mod_jk 가 Apache로부터 받은 요청을 어떻게 Tomcat 에 전달할 것인지에 대한 것이다.

Apache 웹서버에서 mod_jk 설정

mod_jk 를 정상적으로 컴파일 설치했다면 Apache 웹서버에서 이를 인식시켜주고 설정을 해줘야 한다.

여기서 한가지 주의해야할 것이 있는데, CentOS7 에서 Yum 으로 설치한 Apache 의 경우에는 설정하는데 카테고리별로 디렉토리를 분리를 해놨다.

  • 모듈 로딩 설정 디렉토리: /etc/httpd/conf.modules.d
  • 모듈별 설정 디렉토리:  /etc/httpd/conf.d

모듈을 로딩하기 위해서 다음과 같이 conf.modules.d 디렉토리에서 파일을 작성한다.

이렇게 하고나서 다음과 같이 문법 테스트를 해준다. 이 문법 테스트는 설정을 변경할때마다 해주는 것이 좋다.

 

이제 Apache 에서 mod_jk 에 대한 설정을 다음과 같이 해준다.

기본적인 설정은 위와 같다. 저장한 다음에 “workers.properties”, “uriworkermap.properties” 빈 파일을 만들어 줍니다.  Apache 문법 테스트를 해보고 오류가 없다면 정상이다.

mod_jk worker 설정

이 설정은 Apache 와 Tomcat 간에 어떻게 연결을 해야하는지에 대해 정의한다. 이 파일은 위에 “httpd-jk.conf” 파일에서 “conf.d/workers.properties” 로 정의되어 있다.

여기서 고려해야할 사항은 다음과 같다.

  • worker 이름: worker 이름은 정하기 나름이지만 각각 뒷단의 Tomcat 서버를 구분할 수 있는 이름이여야 한다. 이 worker 이름은 나중에 로드밸런싱을 할때에 Tomcat 에도 적용되어지는 이름이기에 잘 설정해야 한다.
  • worker port: 여기서 말하는 port 는 뒷단 Tomcat 서버의 AJP 포트를 말한다.
  • worker type: 이건 ajp13  으로 설정하면 된다.
  • worker lbfactor: 부하분산을 위한 설정으로 뒷단 Tomcat  서버들에 연결 무게를 설정해준다.

 

mod_jk uriworkermap 설정

이 설정은 특정 URI 에 대해서 mod_jk 의 woker 가 동작하도록 해서 요청을 Tomcat 에 넘길 수 있도록 해준다. Apache – Tomcat 구조에서 최초의 요청은 Apache 가 받아 URI 를 해석하는데, 이 설정을 해주면 특정 URI 에 대해서 Apache 가 Tomcat 에게 넘기게 된다.

여기서 간단한 시나리오를 생각해보자. 현재까지 설정은 부하분산(Loadbalance) 가 없는 것이다. 각 3대의 Tomcat 인스턴스에 대해서 동일한 무게를 주었을 뿐이다. 이렇게되면 특정 URI 요청이 있을때에 어느 Tomcat 인스턴스로 보낼것인지도 문제가 된다.

테스트를 위해서 Tomcat 설치시 나오는 메인페이지를 기준으로 하기로 했다. 이 페이지를 들여다보면 jsp, png, css 파일들로 이루어져 있다. 그러면 jsp 는 instance1 서버가 서빙을 하게하고 png 는 instance2 이 css 는 instance3 이 하게 하면 어떨까하는 시나리오를 만들고 이를 설정에 적용해 보자.

 

테스트

테스트는 간단하다. 브라우저를 실행시키고 http://apache-server-ip/index.jsp 주소로 이동해보는 것이다. 이때 Tomcat 초기 메인화면이 나온다면 정상이다.

그런데, 설정에서 jsp 는 instance1이 png 파일은 instance2 이 css 파일은 instance3 이 처리하도록 설정했었다. 그렇다면 실제로 그렇게 되고 있는지 확인을 해야하는데 확인방법은 각각 Tomcat 인스턴스에 접속 로그를 확인하면 된다.

내가 확인해본 바로는 원하는대로 로그가 찍혔다.

로드밸런스 설정

앞에 예제들은 로드밸런스 설정과는 관계가 없다. 로드밸런스라고 하면 instance1 인스턴스가 응답하지 않을 경우에 다른 서버들이 그 역활을 대신하는 것을 말한다. 이를 위해서는 woker 설정과 urlworkermap 설정을 변경해주어야 한다.

일단, 테스트를 위한 시나리오는 앞에서 서빙했던 jsp, png, css 파일들은 각각의 인스턴스들이 모두 제공하는 것으로 한다. 이렇게되면 urlworkermap 설정은 다음과 같이 바꿔주면 된다.

worker 이름을 balancer 라고 했는데, 이는 worker 설정파일에서 사용할 것이다.

로드밸런스는 특정 인스턴스가 죽었을 경우에 다른 서버가 그 역활을 대신하는 것이다. 이를 위해서 로드밸런스 역활을 위한 worker 이름을 정의하고 그 worker 에 로드밸런스를 위한 worker 이름을 정의해주면 된다. 기존의 worker 파일에 다음과 같이 로드밸런스 내용을 추가하면 된다.

강조한 라인을 주의깊게 보기 바란다.

한가지 더, Tomcat 인스턴스들에게 설정을 해줘야 한다. JvmRoute 설정이라고 하는데, 이 설정을 위한 방법은 두가지가 있다. 첫째는 System.property 를 이용한 방법이고 두번째는 server.xml 을 편집하는 방법이다.

첫번째 방법은 Tomcat 인스턴스 구동시에 커맨드라인으로 값을 넣어주는 것으로 다음과 같이 해주면 된다.

보통 Tomcat 의 시작 스크립트는 JVM_OPTS 옵션을 인식한다. 위와같이 Tomcat 인스턴스의 시작 스크립트에 커맨드 라인 옵션으로 jvmRoute 이름을 주면 인식하게 된다.

두번째는 server.xml 파일을 다음과 같이 편집하는 것이다.

위와같이 설정해주면 된다.

만일 두가지 설정을 모두 했을 경우에는 server.xml 파일 설정이 우선되어 적용된다.

테스트

편한 방법으로 설정하고 Apache와 Tomcat 인스턴스를 재시작해주고 index.jsp 를 호출해보면 된다.

HTTP 접속 포트 끄기

이렇게 Apache – Tomcat 연동을 하고나면 반드시 Tomcat 인스턴스의 HTTP 접속 포트를 Disable 해주는걸 잊지 말아야 한다.

 

 

Tomcat Manager 접속 제한.

톰캣은 웹에서 톰캣을 관리할 수 있도록 Manager 페이지를 제공합니다. Tomcat 에 대한 관리를 어느정도 할 수 있기 때문에 보안상 Tomcat Manager 접속 제한 을 해서 아무나 접속을 못하게 하는것이 좋습니다.

방법은 VirtualHost 설정디렉토리에 manager.xml 파일을 작성하는 겁니다.

Allow 에는 IP 주소나 도메인을 넣을 수 있으며 IP의 경우에 Subnet 으로도 표시가능하고 도메인의 경우에는 *로도 표시가 가능합니다.

 

Tomcat manager 암호화 패스워드 설정

Tomcat 에는 Tomcat 서버를 관리를 쉽게 하기위한 GUI,Script 페이지를 제공합니다. 그런데, 여기에 접근하기 위해서는 인증을 설정해야 하는데 이는 $CATALINA_BASE/conf/tomcat-users.xml 파일에 설정하도록 되어 있습니다.

그런데, 여기에는 패스워드를 입력하도록 되어 있는데 텍스트로 되어 있습니다. 보안상 좋지 않습니다. 그래서 Tomcat manager 암호화 패스워드 설정 을 하는게 좋습니다.

이 문서는 Tomcat 7.x 버전에서 테스트 되었습니다.

Digest 암호화 생성

다음과 같이 패스워드를 생성 합니다.

SHA 암호화된 패스워드가 나왔습니다. 이것을 다음과 같이 $CATALINA_BASE/conf/tomcat-users.xml 에 넣어줍니다.

이제 이러한 암호화 패스워드를 Tomcat 서버가 알아먹도록 설정을 해줍니다. 설정은 $CATALINA_BASE/conf/server.xml 에 다음과 같이 해줍니다.

이제 Tomcat 을 재시작 해줍니다.

Tomcat 에러 정보 숨기기

Java 애플리케이션을 작성할때에 에러 발생시 보여줄 에러 페이지를 설정할 수 있습니다. 웹 애플리케이션 설정 파일인 web.xml 파일에 다음과 같이 해줍니다.

단순하게 HTTP 응답코드 뿐만 아니라 Java Exception 객체에 따른 에러도 설정할 수 있습니다.

하지만 이러한 것은 웹 애플리케이션 개발단계에서 설정을 하는 것인데, 이것 말고 서버단계에서 Tomcat 에러 정보 숨기기 를 할 수 있습니다.

Java Application 에러

Tomcat Server 정보 숨기기

에러가 발생했을때보면 Tomcat 서버의 정보가 함께 표시됩니다. 불필요한 정보 입니다. 이를 숨기거나 다른 것으로 서버단에서 바꿀 수 있습니다. $CATALINA_HOME/lib 디렉토리로 이동하고 다음과 같이 디렉토리를 만들어 줍니다.

그리고 다음과 같이 파일을 작성합니다.

그 다음 Tomcat 을 재시동 시켜 주면 적용이 됩니다.

HTTP Header 에 서버 배너 삭제

잘 모르는 이야기인데, 위에처럼 서버정보를 숨긴다 하더라도 다음과 같이 HTTP Header 에는 배너가 추가됩니다.

톰캣 HTTP Header 배너

Server 에 보면 “Apache-Coyote/1.1″ 가 나옵니다. 이는 다음과 같이 설정함으로써 안나오게 할 수 있습니다.

위에 보는 것처럼 Server=” ” 를 추가해주고 톰캣을 재시작하면 됩니다.

자세한 오류 정보 숨기기

오류가 발생하면 Tomcat 은 아주 자세한 정보를 보여줍니다. 여기에는 파일의 위치, Java 애플리케이션의 Stack trace 까지 다 나옵니다. 이를 막는 방법은 아주 간단합니다.

단, 이 방법은 Tomcat 7.0.55 이상 버전이여야 합니다.

Tomcat 은 여러가지 서버단에서 필터를 넣을 수 있습니다. Tomcat 의 동작에 여러가지 옵션을 넣거나 바꾸거나 하는 겁니다. 이를 필터라고 하지 않고 밸브(Valve)라고 하고 밸브를 통해서 여러가지 설정을 할 수 있는데, 자세한 오류 정보 숨기기도 밸브를 이용해서 가능합니다.

위에 보면 Host 설정안에 ErrorReportValve 를 설정하고 있습니다. 이렇게 설정을 한 후에 톰캣을 재시작 시켜주면 적용됩니다.