WebLogic 구동 시 /dev/random 블로킹 이슈 해결

WebLogic 10.3.6 을 설치할때에 관리 서버 1개와 매니지드 서버 1개를 생성하게 됩니다. 그런데, 서버 시작 스크립트에서 난수 관련된 것을 고치지 않으면 시작이 굉장히 오래 걸립니다.

이는 Unix 시스템의 경우에 /dev/random 을 사용하지 않고 /dev/./urandom 을 사용하기 때문입니다.

이를 해결하는 방법은 두가지 인데, 첫번째로는 Java 의 Security 부분을 바꿔 주는 겁니다. 그러면 Java 를 사용하는 모든 자바 프로그램에 다 적용 됩니다. 다음과 같이 해줍니다.

이렇게 해주고 서버를 재시작 하면 적용 됩니다.

두번째는 Java 애플리케이션을 실행할 때에 JVM Command Line 파라메터를 주는 겁니다. 다음과 같이 해줍니다.

위와같이 서버 시작 스크립트에 JAVA_OPTIONS 환경변수에 난수 장치를 지정해 줍니다.

WebLogic 10.3.6 설치하기 – GUI

이 문서는 WebLogic 10.3.6 설치하기 중에 GUI 를 이용한 방법에 관한 것 입니다. 지난번 글에서 “Server Only” 설치 실패후에 jar 파일을 이용한 설치를 기반으로 합니다.

환경

설치 환경에 대해서 먼저 설명을 해야할 필요가 있습니다. 설치 환경은 다음과 같습니다.

  • JDK 1.7 Lastest Release
  • Ubuntu 14.04 64bit
  • WebLogic 10.3.6 – wls1036_generic.jar
  • 설치 계정은 일반계정 입니다.
  • 설치 방법은 GUI 입니다.

위와 같은 환경 입니다.

설치 파일

WebLogic 은 설치 방법이 어떤 패키지를 가지고 설치를 하느냐에 따라 다릅니다. 이 문서에서의 설치는 다음과 같은 것을 이용 한 것입니다.

WebLogic 10.3.6 Generic 설치
WebLogic 10.3.6 Generic 설치

이는 Generic 파일을 이용해서 설치하는 방법이라고도 합니다. Generic 파일은 jar 패키징 된것으로 이 파일을 다운로드 받아 실행해 설치하는 것을 말합니다.

설치 진행

다음과 같이 터미널에서 실행해 GUI 설치 프로그램을 실행 합니다. 문제는 GUI 없이 서버만 설치하는 경우가 많은데 이렇게 되면 GUI 설치를 못할 수도 있습니다. 이를 위해서 서버에 X-Window 서버만을 최소로 설치해주면 됩니다.

그리고 일반 계정으로 로그인을 한 후에 다음과 같이 .Xauthority 파일을 생성해 줍니다.

그리고 다음과 같이 ssh 의 X11 Forwarding 을 이용해서 접속을 하고 설치 프로그램을 실행 합니다.

WebLogic 10.3.6 GUI 설치 시작
WebLogic 10.3.6 GUI 설치 시작

정상적이라면 위 화면과 같이 설치 시작 화면이 나옵니다. Next 를 버튼을 눌러 진행을 합니다.

WebLogic 10.3.6 Home 디렉토리 설정
WebLogic 10.3.6 Home 디렉토리 설정

WebLogic 홈 디렉토리를 설정해 줍니다. 이는 MW_HOME 시스템 환경 변수에 세팅되는 값임과 동시에 WebLogic 의 본체가 설치되는 디렉토리 입니다. 일반계정으로 생성한 디렉토리를 지정해주고 다음으로 넘어간다.

WebLogic 10.3.6 보안 업데이트 등록
WebLogic 10.3.6 보안 업데이트 등록

보안 업데이트 등록은 하지 않아도 됩니다. 체크를 해제하고 Next 를 눌러 진행합니다.

설치 타칩 결정
WebLogic 10.3.6 설치 타칩 결정

Typical 를 선택해도 되지만 저는 Custom 을 선택해 필요한 것만 설치했습니다. 잘 모른다면 Typical 를 선택하시고 Next 를 하셔도 됩니다.

WebLogic 10.3.6 컴포넌트 선택
WebLogic 10.3.6 컴포넌트 선택

Coherence 를 사용하지 않을 예정이라서 뺏고, WebLogic SCA 또한 사용할 일이 없어서 뺐습니다. (사실 나머지도 잘 몰라요…) Next 를 해줍니다.

WebLogic 10.3.6 JDK 선택
WebLogic 10.3.6 JDK 선택

JDK 버전을 선택해 줍니다. 저는 1.7 버전을 미리 선택해 놨기 때문에 이것을 선택하고 Next합니다.

webLogic 10.3.6 프로덕트 디렉토리 지정
webLogic 10.3.6 프로덕트 디렉토리 지정

실제 WebLogic 본체를 설치할 디렉토리를 지정해 주고 Next.

WebLogic 10.3.6 설치 요약본
WebLogic 10.3.6 설치 요약본

위와같이 설치할 컴포넌트들을 보여주고 맞는지 확인해줍니다. 맞다면 Next.

WebLogic 10.3.6 설치 마침
WebLogic 10.3.6 설치 마침

설치를 마치는데, “Run Quickstart” 를 체크해 이어서 Domain 을 생성하도록 하겠습니다.

WebLogic 10.3.6 QuickStart
WebLogic 10.3.6 QuickStart

“Getting started with WebLogic Server 10.3.6” 을 클릭 합니다.

WebLogic 10.3.6 Create a new WebLogic Domain
WebLogic 10.3.6 Create a new WebLogic Domain

WebLogic 의 도메인을 생성합니다. WebLogic 에서 Domain 은 하나의 서비스 그룹으로 생각하시면 됩니다. 여기에 Admin 서버, Managed 서버들이 포함 됩니다.

WebLogic 10.3.6 도메인 설정
WebLogic 10.3.6 도메인 설정

도메인 설정은 도메인에 어떤 서버들을 넣을 건지, 어떤 기능들을 활성화 할것인지를 선택하는 것으로 그냥 WAS 기능만 필요해서 WebLogic Server 만 선택된 상태 그대로 Next 합니다.

WebLogic 10.3.6 도메인 이름과 위치
WebLogic 10.3.6 도메인 이름과 위치

도메인 이름과 위치를 지정해 주고 Next.

WebLogic 10.3.6 도메인 관리를 위한 계정 설정
WebLogic 10.3.6 도메인 관리를 위한 계정 설정

도메인 관리를 위한 계정을 입력하고 Next.

WebLogic 10.3.6 서버 시작 모드 설정
WebLogic 10.3.6 서버 시작 모드 설정

서버 시작모드를 선택해주는 건데, 명확한 차이가 뭔지는 잘 모르겠네요 기본값으로 하고 Next.

WebLogic 10.3.6 서버 선택
WebLogic 10.3.6 서버 선택

Domain 내에 어떤 서버들을 설정할 것인지를 선택합니다. 우선 관리 서버만 먼저하고 나머지는 추후에 진행 합니다. Admin 서버를 선택하고 나오는 다음 화면에서 기본값으로 두고 다음으로 넘어갑니다.

WebLogic 10.3.6 도메인 생성 완료
WebLogic 10.3.6 도메인 생성 완료

위와같이 도메인 생성이 완료 됐습니다.

Trouble Shooting

도메인 생성시 모든 옵션을 다  설정하고 난후에 위 화면에서 프로그레스바가 70%에서 멈추고 “Creating Domain Security Information” 부분에서 멈추게 됩니다.

이는 난수 발생하는 부분이 문제가 있기 때문입니다. Java 의 에서 난수를 생성할때에 /dev/random 을 사용하는데, Unix 시스템의 경우에 /dev/./urandom 을 사용해야지만 정상적으로 동작 합니다.

도메인 생성 실행이 멈췄다면 취소하고 도메인 생성을 위한 디렉토리내에 모든 파일을 삭제 처리 합니다. 그리고 다음과 같이 “Configuration Wizard” 시작 스크립트를 다음과 같이 수정해 줍니다.

위와같이 수정한 후에 config.sh 를 실행하면 “Configuration Wizard” 가 다시 실행되고 정상적으로 완료 됩니다.

WebLogic 10.3.6 설치하기

이 문서는 WebLogic 10.3.6 설치에 관한 문서 입니다.

이 시점에서 WebLogic 10.3.6 는 아주 오래된 버전이다. JDK 1.6 을 기반으로 하고 JEE 도 오래된 버전을 지원한다. 그런데도 간혹 프로젝트를 하다보면 이 버전을 사용하는 곳도 심심치 않아 경악할 때가 있다.

WebLogic 을 버전 업그레이드를 한다고 하려면 어짜피 오래된 버전에 관해서 조금 알아 둘 필요가 있고 WebLogic 의 기본 구성의 경우에는 버전에 크게 상관이 없는 경우도 있어 나름대로 의미가 있다.

설치

WebLogic 10.3.6 버전은 Oracle 홈페이지에서 다운로드 받을 수 있다.정확하게 말하면 WebLogic 10.3.6 버전중에 “Zip distribution with Oracle WebLogic Server only and intended for WebLogic Server” 에 대한 것이다.

Oracle WebLogic Server only
Oracle WebLogic Server only

위와 같이 파일을 다운로드 받습니다. 그리고 다음과 같이 압축을 해제해 줍니다.

그리고 다음과 같이 MW_HOME 환경변수를 세팅해줍니다.

그리고 다음과 같이 configure.sh 파일을 Bash 쉘에 문법에 맞게 고쳐줍니다.

그리고 이제 configure.sh 를 실행해 줍니다.

여기서 한가지 중요한 것이 있는데, commEnv.sh 를 살짝 수정해줘야 합니다. 이걸 수정하지 않으면 64bit 시스템의 라이브러리를 환경변수로 세팅하지 못합니다.

 

도메인 생성

도메인은 WebLogic 에서 서버를 묶어주는 하나의 단위라고 볼 수 있습니다. 서버의 묶이라고 할수도 있고 서비스를 위한 하나의 큰 아키텍쳐라고 볼 수도 있습니다.

이 도메인은 별도의 다른 일반계정에서 디렉토리를 생성해서 생성할 수 있습니다. 여기서는 다음과 같은 위치에 도메인을 생성할 것입니다.

그리고 앞에서 configure.sh 를 실행해 생성된 환경설정을 세팅하기위해서 다음과 같이 실행해 줍니다.

그리고 다음과 같이 도메인 생성을 위한 명령어를 다음과 같이 실행해 줍니다.

 

실패

이렇게 설치를 시도했지만 안됨. 되다가도 아무런 반응이 없고 config.xml 파일이 생성되지 않고 시작/중지 스크립트도 만들어지지 않음.

이 방법으로는 안될듯.. 최소 용량으로 어떻게 돌려보나 했는데 문제가 있어보임.

 

Java 설치

이 글은 Java 를 리눅스에 설치하는 법을 다룹니다.  Java 는 JDK, JRE가 존재하는데 WAS 서버 운영을 위해서는 JDK를 설치하는게 여러모로 좋습니다.

다운로드

다운로드는 Oracle 홈페이지의 Java 페이지에서 받을 수 있습니다. 보시면 다양한 패키지를 제공하는데, 저는 64bit 리눅스 tar.gz 파일을 다운로드 받았습니다.

설치

tar.gz 파일을 다운로드 받았다면 설치는 압축을 해제하는 것으로 사실상 끝이 납니다.

설정하기

자바 설치가 끝났다면 이를 시스템이 인식할 수 있도록 설정해줍니다. 설정은 자바 홈 디렉토리, 패스, 클래스패스등을 입니다.

이를 매번 입력하기 보다는 /etc/profile 맨 아래에 적어주면 부팅할때마다 자동적으로 시스템 전체에 적용 됩니다.

Ubuntu 16.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu16.04 를 사용하고 있다면 콘솔 접속을 위해서는 Grub2 설정을 다음과 같이 해주면 된다.

위와같이 해주고 다음과 같이 grub 을 갱신해준다.

 

Apache Tomcat JNDI 설정

Apache Tomcat 도 JNDI 설정을 할 수 있다. 특히나 데이터베이스 연결을 위해서 JNDI 설정을 사용할 수 있다. JNDI 를 사용하면 Web Application 내에서 데이터베이스 연결을 할 필요가 없이 네이밍(Naming) 을 호출함으로써 간단히 해결된다.

이 문서에서는 MySQL 을 위한 Apache Tomcat JNDI 설정 에 대한 것이다.

MySQL Connector/J 설치

JNDI 를 이용해서 MySQL 연결을 설정하기 위해서는 MySQL Connector/J 를 먼저 설치해줘야 한다. 이것은 MySQL 홈페이지에서 다운로드 가능한데 파일이 jar 확장자를 가진 하나의 파일이 필요하다. 이 파일을 Apache Tomcat 라이브러리 디렉토리에 복사해주면 끝난다.

Apache Tomcat JNDI 설정

MySQL Connector/J 를 설치했다면, 이제 Apache Tomcat JDNDI 설정을 해야 한다. 이는 Apache Tomcat 의 conf 디렉토리에 context.xml 파일을 다음과 같이 설정 한다. 이 설정을 위해서는 MySQL 연결 정보를 알고 있어야 한다.

이렇게 해주고 Web Application 에 web.xml 파일을 설정이 필요하다.

web.xml 설정

Java Web Application 에서는 web.xml 파일이 존재한다. 여기에 JNDI 을 인식시키기 위해서 다음과 같이 설정 해줘야 한다.

Spring Context 설정

Spring 을 사용한다면 다음과 같이 JNDI 를 호출 할 수 있다.

여기서 주의해야할 것은 jndiName 이 ‘comp/env/’ 를 덧붙인다는데 있다. 앞에 설정을 보면 ‘jdbc/MySQLDS’ 로만 설정 된되지만 Spring 에선 ‘comp/env/’ 를 앞에서 붙여주는 것이 다르다.

 

Postgresql 9.x Replication – Streaming Log

Streaming log replication 은 Postgresql 9.0 부터 도입된 기능이다.  이 기능은 Primary 에서 Standby 서버로 직접 전송함으로서 replication delay 를 줄여준다. 따라서 pg_xlog 파일전송이 필요가 없다. 또 xlog 를 Streaming 으로 받기 위해서 Primary 서버에 REPLICATION 권한의 접속 계정이 필요하다.

Replication 권한 사용자 생성.

Primary 서버에서 REPLICATION 권한의 사용자를 다음과 같이 생성해준다.

그리고 Standby 서버에서 Primary 접속을 위해서 pg_hba.conf 파일을 Standby 서버 접속을 허용해 줍니다.

중요한 것은 DATABASE 에 반드시 ‘replication’ 이여야 한다.

Streaming Replication 을 위한 postgresql.conf 를 다음과 같이 설정한다.

데이터백업/복구.

PostgreSQL 9.3 이후부터 pg_basebackup 명령어를 지원한다. 이 명령어는 REPLICATION 권한을 가진 사용자로 접속을해 Primary 의 데이터 디렉토리를 원격에서 로컬로 복제를 해준다.

Standby 서버를 추가할때에 Primary 서버의 데이터 디렉토리를 복제해야 한다. 앞에서 생성한 계정을 이용하면 된다.

정상적으로 실행이 되면 위와같이 나온다.

Streaming logging replication

pg_basebackup 을 실행해 Primary 데이터 디렉토리가 복제했고 이로 인해서 postgresql.conf 파일도 Primary 것일 것이다. 이것을 최초의 파일로 교체해 준다.

그리고 recovery.conf 파일을 다음과 같이 작성해 준다.

그리고 Standby 서버를 시작해 준다.

로그파일을 보면 다음과 같이 나온다.

그리고 프로세스를 살펴보면 다음과 같다.

Primary 서버에서 Streaming Replication 상태를 다음과 같이 조회해 볼수 있다.

혹은 pg_stat_replication 을 조회해도 된다.

하지만 위 방법은 Standby 서버에는 접속할 수 없다. 접속을 시도하면 다음과 같은 에러를 낸다.

Hot Standby 세팅.

Hot Standby 는 Standby 서버에 접속해 읽기전용의 SQL 연산을 수행할 수 있도록 해준다. 이를 위해서는 먼저 Primary 서버에서 다음과 같이 postgresql.conf 파일에 Hot Standby 설정을 해줘야 한다.

Standby 서버도 다음과 같이 설정을 변경해 준다.

이제 서버들을 재시작해줘야 하는데 순서가 중요하다. 다음과 같은 순서로 재시작을 해준다.

  1. Standby 서버 Shutdown
  2. Primary 서버 재시작.
  3. Standby 서버 시작.

Standby 서버의 log 파일을 살펴보면 다음과 같다.

프로세스는 다음과 같이 나온다.

테스트.

Primary 서버에 테이블을 하나 만들고 데이터를 입력해보고 이것이 Standby 서버로 잘 가는지를 살펴본다.

그리고 Standby 서버에서 guestbook 테이블이 존재하고 데이터가 존재하는지 살펴본다.

잘 보이면 정상이다.

M-HA MySQL 설정

MySQL 은 인기있는 오픈소스 데이터베이스 시스템이다. 언제나 데이터베이스 시스템이라면 항상 따라오는 것이 Master-Slave 리플리케이션 환경이고 거기에 덧붙여 자동 페일오버(Auto FailOver) 를 어떻게 할 것이라는 골머리 앓는 주제가 따라서 나온다.

MySQL 의 경우에 자체 적인 FailOver 솔루션이 있다. Fabric 이 그것인데, 아직은 많이 쓰이지는 않는 모양이다. 대신에 AutoFailOver 를 지원하는 제3의 툴들이 존재하는데 M-HA 가 바로 이러한 솔루션이다.

M-HA 는 일본인이 Perl 을 이용해서 작성한 솔루션이다. github 저장소에 소스코드는 공개되어 있으며 저장소이름은 mha4mysql-manager 이다.

구조

M-HA 는 Manager 와 Node  로 이루어진다. Node 는 MySQL 이 설치된 서버에 모두 설치해줘야 한다. Mater/Slave 구조라면 Node 를 모두 설치해줘야 한다.

Manager 는 이들 Node 를 감시하고 이들 전체를 컨트롤하는 역활을 한다.

M-HA 특징

M-HA 를 AutoFailover 로 사용할만한 이유는 다음과 같다.

  • Short downtime
  • MySQL-Replication consistency
  • Easy Installation
  • No chagne to existing deployments

M-HA  를 고려할때에 중요한 부분이 짧은 다운타임이다.  Master/Slave 구조에서 장애시에  Slave 를 Master 로 빠르게 승격을 시켜주어야 한다. 그래야만 두 서버간에 데이터가 달라지는 데이터 무결성이 깨지지 않게 된다. M-HA 는 비교적 이러한 데이터 무결성을 보장하기 위해서 많은 노력을 기울인 솔루션이라고 보면 된다.

M-HA 구성도

최소한의 환경에서 M-HA 를 구성도는 대략 다음과 같다.

M-HA Architecture
M-HA Architecture

M-HA Node 는  MySQL 이 설치된 서버라면 전부 설치해주어야 한다. M-HA Manager 는 외부서버에 설치해된다.

Node 설치

설치는 M-HA 구글 저장소에 가면 각 배포판별로 바이너리로 배포하고 있어 쉽게 설치가능하다. 여기서는 소스를 가지고 컴파일 설치하도록 하겠다.

git 저장소에 소스를 다운받거나 Clone 해서 가지고 와도 된다.

의존성 패키지를 다음과 같이 설치해준다.

Perl 을 이용해서 소스를 코드를 컴파일 하고 설치해주면 된다.

위와 같은 설치를 Master/Slave 모든 MySQL 서버에 설치해 준다.

그리고 각 서버에 M-HA 가 접속하기 위한 MySQL 계정을 생성해 준다.

MySQL 각 서버에 /var/log/masterha 디렉토리를 만들어 준다.

Manager 설치

한가지 주의해야 할 것은 Manager 를 설치하기 전에 Node 도 같이 설치해줘야 한다는 것이다. Manager 설치도 소스코드를 다운받아 설치한다. 그 전에 다음과 같이 의존성 패키지를 설치해준다.

소스코드를 다운받는다.

컴파일 설치해 준다.

Manager 에 mha.cnf 파일 작성

Manager 의 mha.cnf 파일을 다음과 같이 작성한다.

SSH 접속 설정

M-HA 는 내부적으로 SSH를 이용해서  M-HA Node 의 릴레이 로그들을 전송하도록 한다. 그런데 자동으로 이게 되게 할라면 M-HA Manager 와 Node 들간 모두 SSH 를 무인증으로 접속이 가능해야 한다.

SSH RSA 를 생성하는데, 패스워드를 입력하지 않는다. 그러면 무인증 접속이 가능해진다.

각각에 생성한 키들은 ~/.ssh/authorized_keys  파일에 추가해준다. 중요한 것은 각각 서버들은 서로서로 모두 무인증 SSH 접속이 가능해야 한다는 것이다.

SSH 무인증 테스트를 다음과 같이 할 수 있다.

Replication 체크

다음과 같에 Replication 체크를 해본다.

여기서 버그가 있다. /usr/local/share/perl5/MHA/DBHelper.pm 파일 198 라인에 $host 변수에 문제가 있다.

위와같이 수정한 후에 다시 한번 해보면 오류를 해결할 수 있다.

이러한 문제는 호스트 이름에 ‘[‘, ‘]’ 를 붙임으로 나타는 현상이다. 이러한 문제는 다음의 파일에도 있다.

Manager 실행 시키기.

반드시 위에 버그를 제거한 후에 다음과 같이 실행을 한다.

위와같이 실행을 한 후 로그를 보면 다음과 같이 나와야 정상이다.

내용을 보면 192.168.96.32 서버가 현재 Master 고 30번 서버가 Slave 로 인식하고 있다.

FailOver 테스트.

간단한 FailOver 테스트를 해보자. 시나리오는 간단하다. 현재 Master 서버를 정지 시켜 보는 것이다. 그러면 다음과 같이 Manager 로그가 올라온다.

위와같이 로그가 온다면 FailOver 가 정상적으로 된 것이다. 또, 로그 디렉토리 /var/log/masterha 디렉토리에 mha.failover.complete 파일이 생성되어 있을 것이다. 또한, manager 가 죽어 있다. 그러니까 FailOver 가 발생되면 다음과 같이 실행이 된다.

  1. Slave 를 Master 로 승격시킨다.
  2. Manager 에 지정한 로그 디렉토리에 mha.failover.complete 파일을 생성한다.
  3. Manager 가 죽는다.

FailOver 가 발생할때마다 Manager 는 정해진 동작을 수행하고 자동으로 죽게 된다.

승격된 Master 서버에서는 다음을 체크해봐야 한다.

  1. show slave status 명령을 입력했을때 아무것도 나오지 말아야 한다.
  2. show variables like ‘%read%’ 명령어를 입력했을때에 read_only 값이 OFF 여야 한다.

위 두가지가 정상적으로 나온다면 M-HA 가 정상적으로 동작한 것이다.

pom.xml Plugin execution not covered by lifecycle configuration 오류

앞에서 mave timestamp 의 TimeZone 변경을 위해서 build-helper-maven-plugin 를 사용했는데 Eclipse 에서 다음과 같이 오류가 난다.

build-helper-maven-plugin Eclipse 오류
build-helper-maven-plugin Eclipse 오류

위 오류내용은 다음과 같다.

Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:build-helper-maven-plugin: 1.11:timestamp-property (execution: timestamp-property, phase: validate)

Eclipse 는 오류를 표시했지만 maven 은 정상적으로 동작한다. 이는 Ecliplse 의 m2e 커넥터의 lifecycle mapping 정보를 명확하게 해야하는데 이것이 없어서 오류로 표시하는 것이다. 다음 URL 에 관련 내용이 있다.

내용을 보면 <pluginManagement> 를 이용해서 lifecycle-mapping 을 설정해주어야 한다. 위 내용을 기반으로  build-helper-maven-plugin 의 execution 에 대해서 mapping 을 지정해주면 해결된다.

위와 같이 설정을하면 Eclipse 의 오류가 사라진다.

 

Maven timestamp 에 timezone 변경하기

maven 은 build timestamp 를 변수로 지원한다. 하지만 자세히 보면 이 timestamp 는 UTC timezone 에 맞춰져 있다. maven 에서 timestamp 는 기본적으로 UTC timezone 을 기반으로 한다. 그런데 이것을 다른 timezone 으로 변경할려면 어떻게 해야할까?

build-helper-maven-plugin

maven 에선 많은 plugin 을 지원한다. build-helper-maven-plugin 은 우리가 필요하는 기능인 timestamp 에 timezone 변경을 지원한다. 변경된 timezone 의 시간을 표시할 변수와 timestamp format, timezone 등을 지정하면 여기서 지정한 변수를 사용할 수 있게 된다.

위와같이 current.time 변수에 한국시간의 timezone 으로 지정한 timestamp 값을 할당해주고 maven-war-plugin 에서 warName 태그에서 current.time 변수를 사용해주면 된다.