war 파일이름에 TimeStamp 찍기

Maven 을 이용하면 자동으로 컴파일을 해주고 war 파일로 만들어 준다. 그런데, 이때에 war 파일에 TimeStamp 를 찍을 수 있다. war  파일명이 project.name-timestamp.war 형식으로 파일을 작성하도록 할수 있다. 방법도 대략 두가지 방법이 있다.

maven 자체 기능

maven 3.0 이상이라면 자체 기능을 이용할 수 있다. properties 에 timestamp 와 maven.build.timestamp.format 을 지정하고 build 영역에서 파일명을 지정해주면 된다. 예를들면 다음과 같다.

maven 3.0 자체 timestamp 이용.
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
...
<properties>
 
        ....
 
        <!-- Timestamp of build  -->
        <timestamp>${maven.build.timestamp}</timestamp>
        <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
 
</properties>
 
...
 
<build>
        <finalName>${project.artifactId}_${project.version}_${timestamp}</finalName>
 
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                ....
            </plugin>
        </plugins>
</build>

위와같이 설정하고 maven build 를 하면 다음과 같이 출력되는 것을 볼수가 있다.

maven 3.0 timestamp 출력
1
2
3
4
5
6
7
8
9
[INFO] --- maven-war-plugin:2.2:war (default-war) @ mybatis_example1_trans ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mybatis_example1_trans] in [/Users/systemv/Documents/workspace_java/mybatis_example1_trans/target/mybatis_example1_trans-2016070613147]
[INFO] Processing war project
[INFO] Copying webapp resources [/Users/systemv/Documents/workspace_java/mybatis_example1_trans/src/main/webapp]
[INFO] Webapp assembled in [148 msecs]
[INFO] Building war: /Users/systemv/Documents/workspace_java/mybatis_example1_trans/target/mybatis_example1_trans-2016070613147.war
[INFO] WEB-INF/web.xml already added, skipping
[INFO]

maven-war-plugin 으로 war 파일명 지정

이것은 사실 위 방법을 쓴다면 사용할 일이 별로 없다. 하지만 war 파일을 생성할때에 많은 옵션을 주고 싶다면 이 플러그인을 사용하는게 좋다. 이를 사용하면 build 영역에서 finalName 을 지정하지 않고 이 플러그인에서 지정해주면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
...
<properties>
 
        ....
 
        <!-- Timestamp of build  -->
        <timestamp>${maven.build.timestamp}</timestamp>
        <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
 
</properties>
 
...
 
<build>
        <plugins>
            <plugin>
<groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-war-plugin</artifactId>
               <version>2.6</version>
               <configuration>
                   <warName>${project.artifactId}-${timestamp}</warName>
               </configuration>
           </plugin>
        </plugins>
</build>

결과는 처음과 같다.

책임회피를 위해서 상용소프트웨어를 쓴다

시스템을 다루는 사람으로써 SI를 하면서 느끼점을 적어보고자 한다. 사실 지금도 SI 를 하고 있고 나는 시스템을 설계하는 일을 하고 있다.

처음에 프로젝트를 시작할때에 개발자들 위한 개발환경을 구축해줘야 한다. 여기서 대략적인 운영서버에서 사용할 소프트웨어에 대해서 정하게 된다. 나 같은 경우엔 오픈소스를 주로 다루었고 상용서버는 거의 다루지 않았었다. 그러다보니 상용서버에 대해서 그렇게 안전성이 좋다거나 성능이 좋다고 생각하지 않는 경향이 있다. 오히려 오픈소스들이 상용서버에 비해서 다루기가 더 쉬운 편이다.

각설하고 WAS 서버를 무엇으로 할지에 대해서 대기업PM들과 이야기를 하게되었다. JAVA 프로젝트였기 때문에 WAS 서버를 써야할 상황이였는데, 대기업PM 들이 다짜고짜…

JBOSS EAP 를 쓰기로 했습니다.

그래서 내가 궁금해서 물었다.

JEE 프로그램을 돌릴 건가요?

여기서부터 문제였다. JEE 프로그램 스팩을 몰랐다. 대기업 PM들이…

여기서 진행되는 프로젝트는 스프링 프레임워크(Spring Framework)를 기반으로 하고 있다.  일반적인 애플리케이션을 제작하는 것도 아니고 HTTP 프로토콜을 기반을 서비스를 할 예정이다. 그런데 왠 JBOSS EAP 라는 말인가? 그것도 상용으로다가…

나는 Tomcat 을 주장했다. 그정도 프로젝트면 Tomcat 만으로도 충분하기 때문이다. 고작 Web Container 스펙만 구현하고 앉았는데 무거은 JBOSS 를 그것도 돈주고 사야하는 EAP 를 쓸 이유가 없었다.

그런데 그들이 내게한 말은 충격에 가까웠다.

장애가 발생하면 누가 책임집니까? Tomcat 을 쓰다가 문제가 생기면 누구에게 물어봐요?

JBOSS EAP 를 사용하면 문제가 발생하면 업체에 문의도 할 수 있고 그쪽으로 넘기면 되는 겁니다.

이게 우리나라에서 제일 크다고 하는 대기업에서 하고 있는 프로젝트를 이끈다는 PM이 한 소리다.

이뿐만이 아니다. 요즘 클라우드가 대세이다 보니 많은 시스템 구축을 AWS 를 사용한다. AWS 는 알다시피 단순한 가상서버 뿐만 아니라 Database, 통계등도 제공한다. 그중에 AWS RDS 는 데이터베이스를 제공하는 것으로 가상서버를 없애고 마치 원격 데이터베이스를 이용하도록 되어 있다. OS 는 없고 AWS콘솔에서 RDS 의 파라메터를 수정하고 적용하는 방식이다.

그런데, 때로는 AWS 의  EC2 인스턴스에 데이터베이스를 컴파일 설치해서 운영하는 경우도 가끔 있다. 이번 프로젝트가 바로 그러했다. AWS RDS 를 이용하면 자동장애 복구와 백업등 아주 편리한 기능이 있어서 시스템을 다루는 사람에게는 그야말로 훌륭한 선택지다. 하지만 EC2 를 이용해서 직접 데이터베이스를 구축할 경우에는 시스템 엔지니어나 혹은 DBA가 이 데이터베이스에 대해 직접적인 제어가 가능하고 미세조정도 가능한 장점이 있다.

위와같은 장점들을 놓고 선택을 했다면 좋아겠지만 우리나라에서 제일 크다는 대기업이 선택하는 방법은…

운영을 책임지는 입장에서 EC2 위에서 데이터베이스를 설치하고 운영하다 장애나면 그걸 누가 책임집니까? 책임을 우리보고 지라할거고 또 장애나면 조사도 다해야하고 하는데 그럴바에는 AWS RDS 를 쓰는게 나아요..

RDS 에서 장애나면 AWS 로 넘길수 있기 때문이지요.

대기업에서 승진을 위해서는 내가 책임을 지는 일은 결단코 없어야 한다는 것쯤으로 읽힌다.

처음에 나는 왜 이렇게 오픈소스에 대해서 불신이 많은지, 그 이유가 오픈소스를 사용한 경험이 적기 때문이라고 생각했다. 하지만 그건 아주 순진한 생각이였다.

오픈소스를 사용하고 운영중에 장애 발생하면 그것을 책임을 져야 한다는 것이다. 그런데 상용을 사용하면 적어도 그 책임을 타인에게 돌릴 수 있다는 것이다. 그래서 상용소프트웨어를 사용하는 것이다. 그게 전부다. 전문성이 있다거나 그런게 아니다.

국회의원들을 욕할때가 아니다. 사회를 구성하는 사람들의 사고방식 자체가 ‘책임을 지기 싫다’ 라는 생각밖에 없다. 각자 역활분담을 할때에도 되도록이면 책임을 적게 지는 것을 가지고 가기위해서 로비, 뇌물, 친분등을 모두 동원한다. 사회전체가 이런데 국회의원을 욕할 자격이 있나…

나이를 먹어감에 따라 한가지 분명해지는게 있다. 대한민국 국민들이 단체로 정신병에 걸렸다라는 거…. 책임문제와 더블어서 소시오패스적인 성향을 보이는 인간들이 너무나 많다. 자신이 하는 말에 대해서 절대로 책임을 질려고하지 않으면서 나는 세상을 비판할수 있어도 타인이 나를 비판하면 안된다는 사고방식으로 무장한 정신병자들…

안타까운 일이다. 안타까운 일…..

 

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 계정 생성
ZSH
1
2
3
4
5
]# useradd jboss
]# su -
]$ pwd
/home/jboss
]$ mkdir nodes

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

standalone 디렉토리 복사
ZSH
1
2
]# cp -a /opt/EAP-6.4.0/standalone /home/jboss/nodes/node1
]# chown jboss: -R /home/jboss/nodes

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-env.conf 파일 내용
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
JBOSS_NODE_NAME=node01
JBOSS_PORT_OFFSET=100
 
JBOSS_USER=jboss
JBOSS_HOME=/opt/EAP-6.4.0
JBOSS_NODE_BASE_DIR=/home/jboss/nodes
 
JBOSS_PIDFILE=${JBOSS_NODE_BASE_DIR}/${JBOSS_NODE_NAME}/run/jboss-eap-${JBOSS_NODE_NAME}.pid
JBOSS_CONFIG=standalone.xml
JBOSS_BASE_LOG_DIR=${JBOSS_NODE_BASE_DIR}/${JBOSS_NODE_NAME}/log
JBOSS_CONSOLE_LOG=${JBOSS_BASE_LOG_DIR}/${JBOSS_NODE_NAME}-console.log
JBOSS_GC_LOG=${JBOSS_BASE_LOG_DIR}/${JBOSS_NODE_NAME}-gc.log
FILE_ENCODING='UTF-8'
SUN_JNU_ENCODING='UTF-8'
 
JBOSS_BIND_ADDR=0.0.0.0
JBOSS_MANAGEMENT_ADDR=127.0.0.1
JBOSS_CONTROLLER_IP=${JBOSS_MANAGEMENT_ADDR}
JBOSS_MULTICAST_ADDR=230.0.0.4
JBOSS_JMS_MULTICAST_ADDR=231.7.0.1
JBOSS_MODCLUSTER_MULTICAST_ADDR=224.0.1.105
 
LAUNCH_JBOSS_IN_BACKGROUND=true
 
STARTUP_WAIT=30
SHUTDOWN_WAIT=30

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

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

jboss-env.sh

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

jboss-env.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#!/bin/sh
 
DATE=`date +%Y%m%d%H%M%S`
BASE_DIR=$(dirname $0)
 
export JBOSS_CONF=$BASE_DIR/jboss-env.conf
[ -r "$JBOSS_CONF" ] && . "${JBOSS_CONF}"
 
let JBOSS_CONTROLLER_PORT=9999+${JBOSS_PORT_OFFSET}
export JBOSS_CONTROLLER_PORT
 
########## JBoss System module and User module directory ##########
export JBOSS_MODULEPATH=$JBOSS_HOME/modules:$JBOSS_HOME/modules/ext
 
# JVM Options : Server
export JAVA_OPTS="-server $JAVA_OPTS"
 
# Linux Large Page Setting
#export JAVA_OPTS=" $JAVA_OPTS -XX:+UseLargePages "
export JAVA_OPTS=" $JAVA_OPTS -verbose:gc"
export JAVA_OPTS=" $JAVA_OPTS -Djava.net.preferIPv4Stack=true"
export JAVA_OPTS=" $JAVA_OPTS -Dorg.jboss.resolver.warning=true"
export JAVA_OPTS=" $JAVA_OPTS -Dsun.rmi.dgc.client.gcInterval=3600000 "
export JAVA_OPTS=" $JAVA_OPTS -Dsun.rmi.dgc.server.gcInterval=3600000"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.modules.system.pkgs=org.jboss.byteman"
export JAVA_OPTS=" $JAVA_OPTS -Djava.awt.headless=true"
export JAVA_OPTS=" $JAVA_OPTS -Dfile.encoding=${FILE_ENCODING}"
export JAVA_OPTS=" $JAVA_OPTS -Dsun.jnu.encoding=${SUN_JNU_ENCODING}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.home.dir=${JBOSS_HOME}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.base.dir=${JBOSS_NODE_BASE_DIR}/${JBOSS_NODE_NAME}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.log.dir=${JBOSS_BASE_LOG_DIR}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.socket.binding.port-offset=${JBOSS_PORT_OFFSET}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.node.name=${JBOSS_NODE_NAME}"
 
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address.management=${JBOSS_MANAGEMENT_ADDR}"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address=${JBOSS_BIND_ADDR}"
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind_addr=$JBOSS_MULTICAST_ADDR"
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.jgroups.stack=tcp"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.multicast.address=$JBOSS_MULTICAST_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.messaging.group.address=$JBOSS_JMS_MULTICAST_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.modcluster.multicast.address=$JBOSS_MODCLUSTER_MULTICAST_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Dorg.jboss.as.logging.per-deployment=true"
export JAVA_OPTS=" $JAVA_OPTS -Dserver.mode=local"
#JBOSS_OPTS="$JBOSS_OPTS -Djboss.jvmRoute=jvm1"
#JBOSS_OPTS="$JBOSS_OPTS -Djboss.mod_cluster.jvmRoute=node1"
#JBOSS_OPTS=" $JBOSS_OPTS -Dexternal.deployment.dir=$DOMAIN_BASE/$SERVER_NAME/biz"
 
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.config.dir=${JBOSS_NODE_BASE_DIR}/${JBOSS_NODE_NAME}/configuration"
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.domain.config.user.dir=${JBOSS_NODE_BASE_DIR}/${JBOSS_NODE_NAME}/configuration"
 
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
 
echo "=================================================================="
echo "JAVA_HOME=$JAVA_HOME"
echo "JBOSS_HOME=$JBOSS_HOME"
echo "JBOSS_NODE_NAME=$JBOSS_NODE_NAME"
echo "JBOSS_NODE_BASE_DIR=$JBOSS_NODE_BASE_DIR"
echo "JBOSS_CONFIG=$JBOSS_CONFIG"
 
echo "JBOSS_BIND_ADDR=$JBOSS_BIND_ADDR"
echo "JBOSS_PORT_OFFSET=$JBOSS_PORT_OFFSET"
 
echo "JBOSS_PIDFILE=$JBOSS_PIDFILE"
echo "JBOSS_CONSOLE_LOG=$JBOSS_CONSOLE_LOG"
echo "JBOSS_GC_LOG=$JBOSS_GC_LOG"
echo "=================================================================="

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

jvm-env.conf

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

jvm-env.conf
Shell
1
2
3
4
5
6
7
8
9
10
11
#!/bin/sh
 
# JVM Options : Memory
export JVM_OPTS=" $JVM_OPTS -Xms1024m -Xmx1024m -XX:MaxPermSize=256m"
export JVM_OPTS=" $JVM_OPTS -XX:+PrintGCTimeStamps "
export JVM_OPTS=" $JVM_OPTS -XX:+PrintGCDetails "
export JVM_OPTS=" $JVM_OPTS -Xloggc:${JBOSS_GC_LOG}"
#export JVM_OPTS=" $JVM_OPTS -XX:+UseParallelGC "
export JVM_OPTS=" $JVM_OPTS -XX:+UseConcMarkSweepGC "
export JVM_OPTS=" $JVM_OPTS -XX:+ExplicitGCInvokesConcurrent "
export JVM_OPTS=" $JVM_OPTS -XX:-HeapDumpOnOutOfMemoryError "

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-run.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/sh
 
BASE_DIR=$(dirname $0)
 
# jvm setting
export JBOSS_JVM=$BASE_DIR/jvm-env.conf
[ -r "$JBOSS_JVM" ] && . "${JBOSS_JVM}"
 
. ${BASE_DIR}/jboss-env.sh
 
export JAVA_OPTS=" $JAVA_OPTS $JVM_OPTS"
 
if [ "x$1" == "xstart" ]; then
  if [ -e $JBOSS_CONSOLE_LOG ]; then
    mv $JBOSS_CONSOLE_LOG ${JBOSS_CONSOLE_LOG}.${DATE}
  fi
 
  if [ -e $JBOSS_GC_LOG ]; then
    mv $JBOSS_GC_LOG ${JBOSS_GC_LOG}.${DATE}
  fi
fi
 
${JBOSS_HOME}/bin/init.d/jboss-as-standalone.sh $1

맨 마지막이 바로 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.properties
INI
1
2
3
4
5
org.apache.catalina.connector.URI_ENCODING=UTF-8
org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING=true
org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE=8192
org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT=60000
org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT=60000

jboss-cli.sh

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

jboss-cli.sh
Shell
1
2
3
4
5
6
7
8
9
#!/bin/sh
 
BASE_DIR=$(dirname $0)
 
. $BASE_DIR/jboss-env.sh
 
export JAVA_OPTS=" -Djava.awt.headless=false $JAVA_OPTS"
 
$JBOSS_HOME/bin/jboss-cli.sh --controller=$JBOSS_CONTROLLER_IP:$JBOSS_CONTROLLER_PORT --connect $@

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

정리

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

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

시작, 중지

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

node1 시작
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]# ./jboss-run.sh start
==================================================================
JAVA_HOME=/opt/java
JBOSS_HOME=/opt/EAP-6.4.0
JBOSS_NODE_NAME=node01
JBOSS_NODE_BASE_DIR=/home/jboss/nodes
JBOSS_CONFIG=standalone.xml
JBOSS_BIND_ADDR=0.0.0.0
JBOSS_PORT_OFFSET=100
JBOSS_PIDFILE=/home/jboss/nodes/node01/run/jboss-eap-node01.pid
JBOSS_CONSOLE_LOG=/home/jboss/nodes/node01/log/node01-console.log
JBOSS_GC_LOG=/home/jboss/nodes/node01/log/node01-gc.log
==================================================================
Starting jboss-as:                                         [  OK  ]

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

중지는 다음과 같이 한다.

node1 중지
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]# ./jboss-run.sh stop
==================================================================
JAVA_HOME=/opt/java
JBOSS_HOME=/opt/EAP-6.4.0
JBOSS_NODE_NAME=node01
JBOSS_NODE_BASE_DIR=/home/jboss/nodes
JBOSS_CONFIG=standalone.xml
JBOSS_BIND_ADDR=0.0.0.0
JBOSS_PORT_OFFSET=100
JBOSS_PIDFILE=/home/jboss/nodes/node01/run/jboss-eap-node01.pid
JBOSS_CONSOLE_LOG=/home/jboss/nodes/node01/log/node01-console.log
JBOSS_GC_LOG=/home/jboss/nodes/node01/log/node01-gc.log
==================================================================
Stopping jboss-as:                                         [  OK  ]

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

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 기반으로 설치를 위해서는 다음과 같이 명령어를 쳐주면 시작된다.

Text 기반 JBoss EAP 6.4 설치.
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
~]$ java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
~]$ java -jar jboss-eap-6.4.0-installer.jar -console
Select language :
0: eng
1: chn
2: deu
3: fra
4: jpn
5: por
6: spa
Please choose [-1] : 0
Copyright (c) 2013 Red Hat, Inc. All rights reserved. Red Hat, JBoss and the JBoss logo are registered trademarks of Red Hat, Inc. All other trademarks are the property of their respective owners.
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Select the installation path:  [/opt/EAP-6.4.0]
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
 
Select the packs you want to install:
1    [x] [Required]      [Red Hat JBoss Enterprise Application Platform] (542.89 KB)
2    [x]                 [AppClient] (34.24 KB)
3    [x] [Required]      [Bin] (10.99 MB)
4    [x] [Required]      [Bundles] (1.01 MB)
5    [x]                 [Docs] (4.75 MB)
6    [x] [Required]      [Domain] (125.56 KB)
7    [x] [Required]      [Domain Shell Scripts] (17.35 KB)
8    [x] [Required]      [Modules] (147.01 MB)
9    [x] [Required]      [Standalone] (152.77 KB)
10   [x] [Required]      [Standalone Shell Scripts] (14.16 KB)
11   [x] [Required]      [Welcome Content] (2.11 MB)
12   [x]                 [Red Hat JBoss Enterprise Application Platform Natives] (8 KB)
13   [x]                 [Native RHEL7 x86_64] (76 KB)
14   [x]                 [Native Utils RHEL7 x86_64] (53.04 KB)
15   [x]                 [Native Webserver RHEL7 x86_64] (254.97 KB)
Total Size Required: 167.11 MB
Press 0 to confirm your selections
Please select which packs you want to install
0
Pack Selection Done
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Create an administrative user
This user will be added to the host container's management realm for administrative purposes. It can be used to access the management console, the management CLI or other applications secured in this realm.
 
The password must be at least eight characters long, with one alphabetic character, one digit, and one non-alphanumeric character not including &.
 
Admin username: [admin]
admin
Admin password: []
**********
Confirm admin password: [**********]
**********
press 1 to continue, 2 to quit, 3 to redisplay.
1
Quickstarts
Red Hat JBoss Enterprise Application Platform comes with a series of quickstart examples designed to help users begin writing applications using the Java EE 6 technologies. Would you like to install quickstarts?
0  [x] No
1  [ ] Yes
Input Selection:
0
 
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Socket Bindings
Configure the socket bindings for Red Hat JBoss Enterprise Application Platform.
 
Select Port Configuration:
0  [x] Use the default port bindings for standalone and domain modes.
1  [ ] Configure an offset for all default port bindings.
2  [ ] Configure custom port bindings.
Input Selection:
0
 
 
 
If this computer is using a pure IPv6 configuration, please check the box below.
  [ ] Enable pure IPv6 configuration
Input 1 to select, 0 to deselect:
0
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Server Launch
Choose server startup mode:
0  [x] Don't start the server
1  [ ] Standalone Mode
2  [ ] Domain Mode
Input Selection:
0
 
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Logging Options
 
Configure the logging levels for Red Hat JBoss Enterprise Application Platform?
0  [x] No
1  [ ] Yes
Input Selection:
0
 
 
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
Configure runtime environment
There are several additional options for configuring Red Hat JBoss Enterprise Application Platform now that the server has been installed. Each option can be individually chosen, and will be configured in the order displayed upon pressing next. Would you like to do this now?
0  [x] Perform default configuration
1  [ ] Perform advanced configuration
Input Selection:
0
 
press 1 to continue, 2 to quit, 3 to redisplay.
1
 
[ Starting to unpack ]
[ Processing package: Red Hat JBoss Enterprise Application Platform (1/15) ]
[ Processing package: AppClient (2/15) ]
[ Processing package: Bin (3/15) ]
[ Processing package: Bundles (4/15) ]
[ Processing package: Docs (5/15) ]
[ Processing package: Domain (6/15) ]
[ Processing package: Domain Shell Scripts (7/15) ]
[ Processing package: Modules (8/15) ]
[ Processing package: Standalone (9/15) ]
[ Processing package: Standalone Shell Scripts (10/15) ]
[ Processing package: Welcome Content (11/15) ]
[ Processing package: Red Hat JBoss Enterprise Application Platform Natives (12/15) ]
[ Processing package: Native RHEL7 x86_64 (13/15) ]
[ Processing package: Native Utils RHEL7 x86_64 (14/15) ]
[ Processing package: Native Webserver RHEL7 x86_64 (15/15) ]
[ Unpacking finished ]
[ Starting processing ]
Starting process Logging installation information (1/4)
IzPack variable state written to /opt/EAP-6.4.0/installation/InstallationLog.txt
Starting process Adding temporary admin user (2/4)
Exit code: 0
Command completed successfully.
Starting process Adding admin user (3/4)
Exit code: 0
Command completed successfully.
Starting process Unpacking natives (4/4)
Command success: cp -rP /opt/EAP-6.4.0/jboss-eap-6.4/modules /opt/EAP-6.4.0
Command success: cp /opt/EAP-6.4.0/jboss-eap-6.4/SHA256SUM /opt/EAP-6.4.0
Unpacking complete.
Create shortcuts in the Start-Menu (y/n) [y]:n
Installation has completed successfully.
Application installed on /opt/EAP-6.4.0
Would you like to generate an automatic installation script and properties file? (y/n) [n]:n
[ Console installation done ]

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

삭제

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

JBoss EAP 삭제
ZSH
1
]$ java -jar uninstaller.jar -console

 

MongoDB 3.x 인증 알고리즘 변경

MongoDB 3.x 부터는 인증 알고리즘이 MONGODB-CR 에서 SCRAM-SHA-1 으로 변경되었다. 그런데 특정 사용자에 대해서 MONGODB-CR 방식을 적용해야할 필요가 생기기도 한다. 그래서 사용자마다 알고리즘을 달리 적용할 수 있을까?

결론부터 말하면 MongoDB 3.x 는 이를 지원하지만 지원하는 것 같지 않은 상태다. 공식적인 지원을 하지만 이를 구현하기 위해서는 서버를 중단해야하고 인증을 해제해야한 다음에 사용자 알고리즘을 고치고 다시 인증을 걸고 서버를 재시작해야 한다.

또, Replica Set 상태에서 Primary 에서 MONGODB-CR 인증을 설정한다고 하더라도 Secondary  에서는 SCRAM-SHA-1 으로 싱크가 된다. 그래서 프로그램상에서 Replica Set 에서 접속할때에 MONGODB-CR 인증방식으로 접속을 시도하면 Primary 에서는 정상으로 접속되나 Secondary 서버에서는 인증이 실패해 접속이 안된다.

이러한 한계에도 불구하고 MongoDB 3.x 인증 알고리즘 변경 은 다음과 같이하면 된다.

서버 셧다운

제일 번저 서버를 셧다운 해야한다. 이유는 인증모드를 해제하기 위해서다. 관리자로 로그인을 한 후에 다음과 같이 서버를 셧다운 한다.

mongodb 서버 셧다운
1
2
3
4
5
6
7
8
9
10
> db.shutdownServer({force:true})
server should be down...
2016-06-11T01:35:35.931+0900 I NETWORK  [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2016-06-11T01:35:35.932+0900 W NETWORK  [thread1] Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2016-06-11T01:35:35.932+0900 I NETWORK  [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) failed failed
2016-06-11T01:35:35.934+0900 I NETWORK  [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2016-06-11T01:35:35.934+0900 W NETWORK  [thread1] Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2016-06-11T01:35:35.934+0900 I NETWORK  [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) failed failed
> exit
bye

 

무인증 설정

이제 MongoDB 설정 파일에서 인증 부분을 주석처리해 무인증으로 만들고 서버를 시작한다.

mongod.conf 무인증 설정
YAML
1
2
3
4
security:
  #keyFile: "/home/instance1/mongodb/etc/.keyfile/mongodb_keyfile"
  #clusterAuthMode: "keyFile"
  authorization: "disabled"

이렇게 한 후에 서버를 시작하면 인증없이 모든 것을 할 수 있게 된다.

 

MONGODB-CR 인증 계정 생성

MONGODB-CR  인증을 생성하기 위해서는  MongoDB  자체의 인증 방법을 먼저 변경을 해줘야 한다. 이 변경은 역시 무인증 서버상태에서만 가능하다.

MongoDB 인증 모드 변경
1
2
3
4
5
> use admin
switched to db admin
> db.system.version.save({ "_id" : "authSchema", "currentVersion" : 3 });
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
>

authSchema 버전을 3으로 변경하는데 이게 MONGODB-CR 인증 방법을 말한다. 5번은 SCRAM-SHA-1 이다.

이제 생성하고자하는 계정의 데이터베이스로 가서 계정을 생성한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
> use test
switched to db test
> db.createUser({
... user: "test1",
... pwd: "154321",
... roles: [ { role: "readWrite", db: "test" } ]
... });
Successfully added user: {
"user" : "test1",
"roles" : [
{
"role" : "readWrite",
"db" : "test"
}
]
}

생성된 계정을 확인해보면 다음과 같다.

계정 확인
1
2
3
> db.system.users.find()
{ "_id" : "test.test1", "user" : "test1", "db" : "test", "credentials" : { "MONGODB-CR" : "d742f64096c71b3a2aef03165f428f76" }, "roles" : [ { "role" : "readWrite", "db" : "test" } ] }
>

 

인증방법 복원

MONGODB-CR 을 위한 계정을 생성했다면 SCRAM-SHA-1 로 바꾸고 서버에 인증을 걸어야 한다.

SCRAM-SHA-1 인증으로 변경
1
2
3
> db.system.version.save({ "_id" : "authSchema", "currentVersion" : 5 });
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
>

그리고 설정파일에 인증을 걸어준다.

Mongo 설정파일 변경
YAML
1
2
3
4
security:
  keyFile: "/home/instance1/mongodb/etc/.keyfile/mongodb_keyfile"
  clusterAuthMode: "keyFile"
  authorization: "enabled"

그리고 서버를 재시작해주면 된다.

문제점

문제점은 앞에서 이야기 했듯이 Replica Set 상태에서 Primary 에서 MONGODB-CR 인증으로 계정을 생성했다고 하더라도 Secodary 에서는 SCRAM-SHA-1 으로 싱크가 된다. 그래서 Secondary 서버에 MONGODB-CR로 인증할려면 오류를 낸다.

 

MongoDB Replica Set 구성하기

mongodb logoMongoDB 는 Replication 을 지원한다. 이는 서비스의 지속성과 안전성을 제공하는 데이터베이스 시스템의 설비다. MongoDB 는 단순하게 데이터 복제를 위한 것뿐만 아니라 Master 가 장애시에 이를 Slave 를 Master 로 자동승격시켜준다. 수 많은 Slave 중에 어떤 것을 Master 로 승격할지를 투표를 통해서 결정한다. MongoDB 는 투표에 참여하기만 하는 것으로 Arbiter 를 세팅할 수도 있다.

이글은 다음의 아키텍쳐를 기반으로 한다.

replica set primary with secondary and arbiter
replica set primary with secondary and arbiter

Replica Set 설정

replication 설정을 위해서 서버 두대에 etc/mongod.conf 파일을 다음과 같이 설정을 해준다.

Replica Set 설정
YAML
1
2
3
replication:
  oplogSizeMB: 5120
  replSetName: "rs1"

oplogSizeMB 는 Replication 을 위해사용되는 로그파일의 용량을 지정하는 것이다. 메뉴얼에 따르면 파일시스템의 활용가능한 5% 를 지정하라고 되어 있지만 고용량 스토리지 시대에는 너무 큰 것 같다.

위와같이 하고 Replica Set 을 설정해주면 된다. 보통 Replica Set 은 적어도 3대로 구성하는데 Primary, Secondary, Aribter 가 바로 그것이다.

한가지 주의해야할 사항은 Replica Set 구성을 미리해놓은다고 서버가 한대인데도 mongod.conf 에 위 설정을 하고 서버에서 명령어를 치면 다음과 같은 오류를 만나게 된다.

Replica Set 구성이 없는 상태이기 때문에 나오는 오류
1
2
3
4
5
6
7
> show dbs;
2016-06-04T22:32:51.328+0900 E QUERY    [thread1] Error: listDatabases failed:{ "ok" : 0, "errmsg" : "not master and slaveOk=false", "code" : 13435 } :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
Mongo.prototype.getDBs@src/mongo/shell/mongo.js:62:1
shellHelper.show@src/mongo/shell/utils.js:760:19
shellHelper@src/mongo/shell/utils.js:650:15
@(shellhelp2):1:1

위 설정은 Master/Slave 두 서버에 모두 해줘야 한다. 그리고 두 서버를 모두 재시작 해준다.

Replication 설정

어떤 블로그에는 Replication 설정을 위해서 다음의 명령어를 치라고 나온다.

1
> rs.initiate()

적어도 MongoDB 3.2 버전에서는 절대로 위 명령어를 먼저 쳐서는 안된다. 내 경우에 멋모르고 위 명령어를 먼저 쳤다가 MongoDB 가 Primary 로 지정되지 않아 아무것도 할 수 없었다. 이럴 경우에 강제로 Primary 임을 지정해줘야 하는데 절차는 다음과 같다.

1
2
3
> cfg = rs.conf()
> cfg.members = [cfg.members[0]] <- Primary로 지정할 멤버하나만 넣는다.
> rs.reconfig(cfg, {force : true})

force 옵션을 주어서 강제로 설정을 지정하게 해줘야한다.

아무튼, 맨 처음에 아무런 생각없이 rs.initiate() 을 해서는 안된다. 특히나 Primary 임을 지정해야하는 서버의 경우에는 이렇게 해서는 안된다. 반드시 멤버지정을 수동으로 해줘야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
> rsconf = {_id:"rs1", members:[{_id:0, host:"192.168.96.6:27017"}]}
{
"_id" : "rs1",
"members" : [
{
"_id" : 0,
"host" : "192.168.96.6:27017"
}
]
}
> rs.initiate(rsconf)
{ "ok" : 1 }

이렇게 하면 이 서버는 이제 Primary 로 지정된다. 상태를 살펴보면 다음과 같다.

Primary MongoDB 의 상태확인
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2016-06-05T07:17:39.321Z"),
"myState" : 1,
"term" : NumberLong(1),
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "192.168.96.6:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 785,
"optime" : {
"ts" : Timestamp(1465110577, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2016-06-05T07:09:37Z"),
"electionTime" : Timestamp(1465110576, 2),
"electionDate" : ISODate("2016-06-05T07:09:36Z"),
"configVersion" : 1,
"self" : true
}
],
"ok" : 1
}

“stateStr” 이 PRIMARY 라고 나와야 정상이다.

이제 슬레이브를 붙이면 되는데, MongoDB 는 이를 아주 쉽게 명령어로 할 수 있다. Slave 서버를 구동하고 다음과 같이 Primary 서버에서 명령어를 입력해주면 된다.

Slave MongoDB 추가
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
rs1:PRIMARY> rs.add("192.168.96.30:27017")
{ "ok" : 1 }
rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2016-06-05T07:19:56.103Z"),
"myState" : 1,
"term" : NumberLong(1),
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "192.168.96.6:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 922,
"optime" : {
"ts" : Timestamp(1465111191, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2016-06-05T07:19:51Z"),
"electionTime" : Timestamp(1465110576, 2),
"electionDate" : ISODate("2016-06-05T07:09:36Z"),
"configVersion" : 2,
"self" : true
},
{
"_id" : 1,
"name" : "192.168.96.30:27017",
"health" : 1,
"state" : 5,
"stateStr" : "STARTUP2",
"uptime" : 4,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2016-06-05T07:19:55.545Z"),
"lastHeartbeatRecv" : ISODate("2016-06-05T07:19:51.894Z"),
"pingMs" : NumberLong(1),
"syncingTo" : "192.168.96.6:27017",
"configVersion" : 2
}
],
"ok" : 1
}

Slave 를 붙이자마자 상태를 확인해보면 stateStr 이 STARTUP2 로 나온다. 하지만 시간이 지나서 다시 확인해보면 SECONDARY 가 되어 있는 것을 확인할 수 있다.

PRIMARY 와 SECONDARY 가 동기화가 잘되고 있는지는 optime 의 수치가 모두 동일한지를 보고 판단할 수 있다.

Aribter 추가

Aribter 는 PRIMARY 가 장애가 발생했을시에 이를 감지하고 SECONDARY 중에 하나를 PRIMARY 로 선택할때 투표에 참여하는 역화을 한다. 즉, 오직 투표만을 위한 시스템이라고 보면 된다. 따라서 데이터 복제, 데이터 저장이 없기 때문에 저장소를 위한 설정은 다 필요가 없다. 따라서 mongod.conf 설정은 다음과 같다.

Aribter 의 mongod.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# mongod.conf
 
# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/
 
# where to write logging data.
systemLog:
  verbosity: 0
  destination: file
  logAppend: true
  logRotate: rename
  timeStampFormat: ctime
  path: "/home/instance2/mongodb/log/mongod.log"
  component:
    replication:
      verbosity: 2
 
# Where and how to store data.
storage:
  dbPath: "/home/instance2/mongodb/data"
  directoryPerDB: true
  journal:
    enabled: false
#  engine: "wiredTiger"
#  mmapv1:
#  wiredTiger:
#    engineConfig:
#      cacheSizeGB: 1
 
# how the process runs
processManagement:
  fork: true  # fork and run in background
  pidFilePath: "/home/instance2/mongodb/run/mongod.pid"  # location of pidfile
 
# network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0  # Listen to local interface only, comment to listen on all interfaces.
  maxIncomingConnections: 1024
  http:
    enabled: false
 
security:
  keyFile: "/home/instance2/mongodb/etc/.keyfile/mongodb_keyfile"
  clusterAuthMode: "keyFile"
  authorization: "enabled"
 
operationProfiling:
  slowOpThresholdMs: 100
  mode: off
 
replication:
  oplogSizeMB: 5120
  replSetName: "rs1"
 
#sharding:
 
## Enterprise-Only Options
 
#auditLog:
 
#snmp:

MongoDB 3.2 메뉴얼에 따르면 Aribter 로 동작하는 Node 의 경우에 storage.journal.enabled 를 false 로 설정하도록 권장하고 있다. 그리고 Engine 관련 설정은 모두 주석처리를 한다.

이렇게 설정한 후에 Aribter 서버를 시작시킨다. 그리고 Master 서버에서 다음과 같이 Aribter 를 추가해 준다.

1
rs1:PRIMARY> rs.addArb("192.168.96.31:27017")

위와같이 하면 Arbiter 가 Replica Set 에 추가 된다. 그리고 Master 가 장애가 발생하면 투표에 참여해 SECONDARY 서버중에 하나를 Master 로 지목하게 된다.

MongoDB 설치 및 환경설정

mongodb logo

이 글은 MongoDB 설치 및 환경설정에 관한 글이다. 환경설정은 슈퍼유저의 인증을 설정하는 것까지 한다.

Download and Extract

Mongodb 는 Binary 배포를 하고 있다. 홈페이지에 접속해서 설치할 컴퓨터의 운영체제에 맞는 압축 파일을 다운로드 하면 된다. Downlaod URL 도 제공하기 때문에 서버에서 wget, curl 을 이용해서 바로 다운로드도 할 수 있다.

Binary 파일이기 때문에 압축해제 하기만하면 설치가 완료 된다. 압축을 해제하고 나면 다음과 같은 파일들이 나온다.

ls -lh mongodb
1
2
3
4
5
6
7
mongodb]$ ls -lh
합계 104K
-rw-r--r-- 1 instance1 tomcat  34K  4월 28 05:32 GNU-AGPL-3.0
-rw-r--r-- 1 instance1 tomcat  17K  4월 28 05:32 MPL-2
-rw-r--r-- 1 instance1 tomcat 1.4K  4월 28 05:32 README
-rw-r--r-- 1 instance1 tomcat  36K  4월 28 05:32 THIRD-PARTY-NOTICES
drwxr-xr-x 2 instance1 tomcat 4.0K  6월  4 19:46 bin

보면알겠지만 달랑 실행을 위한 디렉토리와 파일만 존재한다. 이제 하나하나 설정을 해보자.

디렉토리 생성

먼저, 디렉토리를 생성해야 한다. 설정파일을 담을 디렉토리, 로그 파일을 담을 디렉토리, 데이터를 저장할 디렉토리등이다.

디렉토리 생성
1
2
3
4
5
6
7
8
9
10
11
12
]$ mkdir etc log data run
]$ ls -lh
합계 104K
-rw-r--r-- 1 instance1 tomcat  34K  4월 28 05:32 GNU-AGPL-3.0
-rw-r--r-- 1 instance1 tomcat  17K  4월 28 05:32 MPL-2
-rw-r--r-- 1 instance1 tomcat 1.4K  4월 28 05:32 README
-rw-r--r-- 1 instance1 tomcat  36K  4월 28 05:32 THIRD-PARTY-NOTICES
drwxr-xr-x 2 instance1 tomcat 4.0K  6월  4 19:46 bin
drwxr-xr-x 4 instance1 tomcat 4.0K  6월  4 21:05 data
drwxr-xr-x 3 instance1 tomcat   39  6월  4 21:03 etc
drwxr-xr-x 2 instance1 tomcat   23  6월  4 21:03 log
drwxr-xr-x 2 instance1 tomcat   23  6월  4 21:03 run

디렉토리를 생성하고 나면 위와같은 상태가 된다.

mongod.conf 파일 생성

mongodb 를 운영하기 위해서는 설정파일이 필요하다. 이를 위해서 설정파일을 생성해야 한다. 이는 다음의 주소에서 샘플을 구할 수 있다.

기본적인 내용만 되어 있다. 하지만 mongodb 는 Replica set 를 염두해야하기 때문에 이를 위한 설정을 포함하면 다음과 같다.

mongod.conf
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# mongod.conf
 
# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/
 
# where to write logging data.
systemLog:
  verbosity: 0
  destination: file
  logAppend: true
  logRotate: rename
  timeStampFormat: ctime
  path: /home/instance1/mongodb/log/mongod.log
  component:
    replication:
      verbosity: 2
 
# Where and how to store data.
storage:
  dbPath: /home/instance1/mongodb/data
  journal:
    enabled: true
  engine: wiredTiger
#  mmapv1:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1
 
# how the process runs
processManagement:
  fork: true  # fork and run in background
  pidFilePath: /home/instance1/mongodb/run/mongod.pid  # location of pidfile
 
# network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0  # Listen to local interface only, comment to listen on all interfaces.
  maxIncomingConnections: 1024
  http:
    enabled: false
 
#security:
 
operationProfiling:
  slowOpThresholdMs: 100
  mode: off
 
#replication:
 
#sharding:
 
## Enterprise-Only Options
 
#auditLog:
 
#snmp:

위 설정 파일을 실제 서버에서 운영하기에는 문제가 있다. 문제가 될만한 설정들은 다음과 같다.

  • cacheSizeGB – 엔진의 캐쉬 크기이다. 메뉴얼에 따르면 최소 1GB 이상이여야 한다.
  • oplogSizeMB – 리플리케이션을 위한 로그 파일 크기다. 메뉴얼에 따르면 활용가능한 디스크 공간의 5% 다.

실제 서버에서 운영한다면 위 두개의 파라메터를 반드시 운영환경에 맞게 설정을 해야한다. 그리고 운영환경을 위해서 슈퍼유저에 대한 인증을 반드시 설정해야 한다.

슈퍼유저 인증 설정

MongoDB 는 설치를 완료하고 나면 아무런 보안 설정이 없다. 누구나, 아무나 슈퍼유저가 될수 있다. 이를 제안하기 위해서 슈퍼유저에 인증을 설정해야 한다. 이는 서버를 구동하고 나서 해야 한다.

mongodb 서버 구동
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
]$ ./bin/mongod -f etc/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 16080
child process started successfully, parent exiting
]$ ./bin/mongo
MongoDB shell version: 3.2.6
connecting to: test
Server has startup warnings:
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten]
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten]
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
Sat Jun  4 22:24:48.990 I CONTROL  [initandlisten]
> use admin
switched to db admin
> db.createUser(
...   {
...     user: "admin",
...     pwd: "154321",
...     roles: [ { role: "root", db: "admin" } ]
...   }
... );
Successfully added user: {
"user" : "admin",
"roles" : [
{
"role" : "root",
"db" : "admin"
}
]
}
> db.shutdownServer()
server should be down...
2016-06-04T22:28:11.241+0900 I NETWORK  [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2016-06-04T22:28:11.241+0900 W NETWORK  [thread1] Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2016-06-04T22:28:11.241+0900 I NETWORK  [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) failed failed

mongod.conf 의 인증과 Replica set 을 해제한 상태에서 해야지만 가능한다. 만일 최초 설치 후에 securiry, replication 부분이 설정이 되어 있다면 위 명령어는 듣지 않는다.

keyFile 생성

keyFile 은 sharded cluster 나 replica set 을 위해서는 keyFile 을 필요로한다. 각 노드간 자신들의 멤머인지 아닌지를 알기 위한 수단이 된다. 이 파일은 각 노드마다 모두 동일해야 한다.

keyFile 생성
ZSH
1
2
3
4
]$ mdir etc/.keyfile
]$ cd etc/.keyfile
]$ openssl rand -base64 741 > mongodb_keyfile
]$ chmod 600 mongodb_keyfile

shared cluster, replica set 을 구성한다면 구성을 위한 서버에 이 파일을 각각 배포를 해야 한다.

그리고 다음과 같이 mongod.conf 파일에 keyFile 을 인식시켜준다.

etc/mongod.conf
YAML
1
2
3
4
security:
  keyFile: "/home/instance1/mongodb/etc/.keyfile/mongodb_keyfile"
  clusterAuthMode: "keyFile"
  authorization: "enable"

위와 같이 한 후에 서버를 다시 시작한다. (앞에서 서버를 shutdown 시켰놨었다.)

mongod 서버 시작.
1
2
3
4
5
6
7
8
9
10
11
12
]$ ./bin/mongod -f etc/mongod.conf
$ ./bin/mongo
MongoDB shell version: 3.2.6
connecting to: test
> use admin
switched to db admin
> db.auth("admin","154321")
1
> show dbs
admin  0.000GB
local  0.000GB
>

위와같이 서버로 접속하고 정상적으로 인증이 될 경우에 ‘1’ 을 리턴한다. 그리고 명령어를 쳐보면 실행이 되는 것을 알 수 있다.

JBoss 5 MySQL Replication 접속

Jboss EAP

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

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

XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?xml version="1.0" encoding="UTF-8"?>
 
<!-- $Id: mysql-ds.xml 41017 2006-02-07 14:26:14Z acoliver $ -->
<!--  Datasource config for MySQL using 3.0.9 available from:
http://www.mysql.com/downloads/api-jdbc-stable.html
-->
 
<datasources>
<!-- mysql DS -->
  <local-tx-datasource>
    <jndi-name>MySQLDS</jndi-name>
    <connection-url>jdbc:mysql:replication://address=(protocol=tcp)(host=192.168.96.31)(port=3306)(type=master),address=(protocol=tcp)(host=192.168.96.30)(port=3306)(type=slave)/spring?useUnicode=true&amp;characterEncoding=UTF-8&amp;autoReconnect=false&amp;useSSL=false&amp;failOverReadOnly=true&amp;loadBalanceStrategy=random&amp;readFormMasterNoSlaves=true</connection-url>
    <driver-class>com.mysql.jdbc.ReplicationDriver</driver-class>
    <user-name>spring</user-name>
    <password>12345</password>
    <min-pool-size>5</min-pool-size>
    <max-pool-size>50</max-pool-size>
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <!-- should only be used on drivers after 3.22.1 with "ping" support -->
    <!-- <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name> -->
 
    <!-- sql to call when connection is created
    <new-connection-sql>some arbitrary sql</new-connection-sql>
      -->
    <!-- sql to call on an existing pooled connection when it is obtained from pool - MySQLValidConnectionChecker is preferred for newer drivers
    <check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
      -->
 
    <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
  </local-tx-datasource>
</datasources>

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

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

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

MySQL Replication 어노테이션 적용
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
<!-- required to connect Slave Server only for get* method on MySQL Replication  -->
    <tx:advice id="txAdvice" transaction-manager="transactionManager">    
        <tx:attributes>      
            <tx:method name="*" propagation="REQUIRED"/>    
            <tx:method name="get*" read-only="true"/>    
        </tx:attributes>    
    </tx:advice>    
          
    <aop:config>    
        <aop:pointcut expression="execution (* com.sbhyun.service.*.*(..))" id="services"/>      
        <aop:advisor advice-ref="txAdvice" pointcut-ref="services"/>    
    </aop:config>

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