Category: WAS

WAS 에 대한 카테고리

mod_jk, SEVERE: Invalid message received with signature 해결

Apache 2.4 에 mod_jk 를 설치하고 Tomcat 9 와 AJP 연결 설정을 했다. 그런데, 어찌된 영문인지 AJP 연결이 되지 않으면서 다음과 같은 에러 메시지만 나왔다.

mod_jk 설정과 Tomcat 9 의 연결 설정은 아무런 문제가 없음에도 이런 오류가 발생하는 이유를 몰랐는데, 문제는 아주 단순했다.

address=”::1″

Tomcat 9 의 서버 설정인 server.xml 에 ajp 설정은 다음과 같다.

기본 설정값으로, address 에 할당된 값이 문제가 된다. address 에 값을 “0.0.0.0” 으로 바꾸던지 아니면 서버 IP 주소로 변경해 주면 된다.

secret=””

Tomat 9 에서 AJP 연결에서 주의해야 할 것이 secret 이다. 변경사항이기도 한데, ‘secretRequired=true’ 가 기본값으로 설정되어 있어 secret 값을 줘야 한다. 이것은 AJP 연결을 하기 위한 일종의 키값으로 mod_jk 설정에서도 해줘야 한다.

위와같이 secret 값이 일치해야지만 연결이 된다.

jboss-cli 를 통한 로깅 설정

자바 웹 애플리케이션에 대한 로깅은 중요한 일이다. 웹 애플리케이션이 어떻게 동자하는지를 잘 알아야 하는데, 그 방법이 로깅이기 때문이다. 하지만 웹 애플리케이션의 로깅을 변경할 경우에 대부분 웹 애플리케이션을 배포한다. 물론 배포를 하지 않고도 가능하지만, 대부분 배포를 다시 하게 된다.

JBoss 에서는 배포를 하지 않고 jboss-cli 를 통해서 런타임으로 설정이 가능하다.

만일, 인증을 설정했다면 ID/Password 를 입력해야 한다.

logging Subsystem

Jboss 는 JEE 스펙을 구현한 서버이다. JEE 스펙을 각각 Subsystem 으로 구현해놨다. Subsystem 으로 모듈화를 해놨기 때문에 각각의 설정을 Subsystem 에 귀속되고 서로 간섭되지 않는다. 독립적인 모듈이다 보니 만일 득정 기능을 쓰지 않는다면 Subsystem 을 끄면 되고 그렇게 껐다고 해서 전체 서버가 문제가 되지 않는다. 아주 잘 만들어졌다.

jboss-cli 는 마치 파일시스템의 디렉토리를 접근하듯이 사용한다. 실제 명령어도 cd, ls 명령어를 그대로 사용할 수 있다.

subsystem 이 보인다. 저곳으로 들어가야 한다. cd 명령어를 사용해 들어간다.

jboss 내에 컴포넌트들이 보이는데, logging 이 보인다.

logging 관련된 많은 정보들을 볼 수 있다. 여기서는 logger 를 봐야 한다.

위와같이 보일 것이다.

logger 추가하기

이제 여기서 로거(logger) 를 추가해 보자.

위와같이 로거를 추가할 수 있다. 하지면 내용을 보면 핸들러(handler) 가 정의되어 있지 않다.

속성 추가

속성을 추가하기 위해서는 write-attribute 를 이용하면 된다. 레벨(level) 속성을 다음과 같이 변경할 수 있다.

레빌이 DEBUG 로 변경되었다.

핸들러 추가

핸들러 추가는 다음과 같이 한다.

한줄 명령어

지금까지 작업을 한줄 명령어 가능하다. 디렉토리 접근법을 사용하기 때문에 루트(root) 부터 따라들어가서 속성을 설정하면 되는식이다.

위와 같이 한줄 명령어로 충분히 가능하다.

WebLogic 12c: 노드 매니저(NodeManager) 설정하기

WebLogic 에서 노드매니저(NodeManger)는 웹로직을 운영할 머신(Machine) 에 설치되는 것으로 웹로직의 Admin 서버에 요청을 받아 처리해주는 역할을 한다. 노드매니저가 하는 일은 대략 다음과 같다.

  • 매니지드 서버 생성/삭제
  • 매니지드 서버 시작, 중지, 종료

웹로직을 설치하면 노드 매니저도 함께 설치가 된다. 기본적으로 터미널 상에서 노드매니저를 설정을 한 후에 Admin 콘솔에서 Admin 서버가 인식할 수 있도록 등록을 해줘야 한다.

여기서는 터미널 상에서 노드매니저 설정에 대해서 간단하게 다루어 본다.

노드매니저 설정

웹로직을 설치하고 난 후에 도메인(Domain) 을 생성하면 노드매니저 관련 내용도 함께 설치가 된다. 기본적으로 도메인 디렉토리에 nodemanager 디렉토리가 함께 존재하게 되고 여기에 파일들이 존재하게 되는데, 각 파일의 역할은 다음과 같다.

  • nodemanager/nodemanager.domains – 웹로직의 도메인. 파일 시스템상의 도메인의 풀 경로를 입력해준다.
  • nodemanager/nodemanager.properties – 노드 관리자 설정에 핵심 파일이다.
  • config/nodemanager/nm_password.properties – 노드매니저 사용자ID, 패스워드 정보를 담고 있는 파일. 암호화 되어 있지만 초기화가 가능하다.

핵심은 nodemanager.properties 인데 다음과 같은 3가지가 핵심적이 설정으로 보면 된다.

여기서 중요한 설정으로 SecureListener 를 들수 있다. 만일 웹로직 자체를 TLS 설정을 했다면 true 로 놔야 하겠지만 대부분 TLS 설정을 하지 않는다. TLS 설정이 없는 상태에서 이 설정을 변경하지 않고, 왜 안되는지 헤메는 경우가 많다.

이렇게 한 후에 Admin 콘솔에서 노드매니저 등록을 해줘야 한다. 이것은 환경 > 시스템 에서 할 수 있다.

WebLogic 12c Silent 설치

WebLogic 12c 사일런트(Silent) 설치에 대해서 다룹니다. 현재 WebLogic 은 12.2.1.4 버전이다.

WebLogic 12.2.1.4

WebLogic 은 자바 엔터프라이즈 서버(Java Enterprise Server) 이다. 자바를 필요로 하는데, 특징은 Oracle 자바 jdk8 이 반드시 필요하다. JEE 7 스펙을 만족한다. 최근에 Oracle Linux 8.x 에서 인증이 되어서 설치할 수 있게 되었다.

시스템 계정 생성

WebLogic 을 운영하기 위한 시스템 계정을 생성 한다.

디렉토리 생성

WebLogic 설치를 위한 디렉토리를 다음과 같이 생성해 준다.

oracle 계정의 Bash 환경변수 세팅

oracle 계정으로 운영할 WebLogic 을 위해서 환경변수를 다음과 같이 세팅해 준다.

Oracle Java 설치

oracle 계정으로 다음과 같이 Oracle 자바를 설치해 준다. Oracle 자바 1.8 버전을 다운받아서 설치 했다.

WebLogic Response File 작성

WebLogic 사일런스 설치를 하기 위해서 Response File 가 필요한데, 다음과 같이 작성해 준다.

Inventory 파일 작성

인벤토리를 위한 파일을 작성해 준다.

다운로드 WebLogic

다운로드를 할때에 주의해야할게 있다. WebLogic 이 발전하면서 Fusion Middleware Infrastructure 패키지화가 되었다. 다운로드 홈페이지에 가보면 두가지 타입으로 제공하고 있는데, “Generic Installer for Oracle WebLogic Server and Oracle Coherence:” 이것을 다운받아야 한다.

설치 확인

설치가 성공적으로 되었는지 다음과 같이 확인할 수 있다.

도메인 생성하기

WebLogic 은 도메인이라는 개념이 존재한다. 도메인은 하나의 WebLogic 서버처럼 여겨지는데, Admin 과 Managed 도메인 두가지 타입으로 나뉜다.

먼저 Admin 도메인 서버는 Managed 도메인 서버를 총괄한다. Managed 도메인 서버가 자바 애플리케이션을 실행하는 실제 서버라고 보면 되며 이 Managed 도메인 서버는 Admin 도메인 서버에 등록되어야만 동작할 수 있다.

도메인 생성에는 python 스크립트를 이용한다. 정확하게는 WebLogic 의 스크립트를 이용한다고 보면 된다. 이것은 스크립트뿐만 아니라 WLS 쉘을 이용해서도 할 수 있다.

다음과 같이 스크립트를 작성해 준다.

‘krbank_pay’ 가 도메인이 된다. selectTemplate 에 버전을 표시하고 있는데, 이는 $MW_HOME/wlserver/common/templates/wls/wls.jar 파일을 압축 해제하고 나온 파일중에 template-info.xml 을 보면 버전 정보가 나온다.

ServerStartMode 를 prod 로 하고 있으며, 아이디와 패스워드를 입력해주고 있다. writeDomain 으로 Admin 도메인을 어디에 생성할 것인지 디렉토리 정보를 넘겨주고 있다. 이렇게 작성을 다 했다면 다음의 명령어로 실행해 준다.

정상적으로 실행이 되었다면 /home/oracle/wls_domain/admin 디렉토리에 관련 파일들이 존재하게 된다. 디렉토리를 잘 보면 startWebLogic.sh 파일이 존하고 이것을 실행하면 Admin 도메인 서버가 실행 되게 되는데, 중간에 Username 과 password 를 입력받도록 되어 있다.

매번 서버를 시작할때마다 입력해주면 불편하니까, 이것을 다음과 같이 파일을 작성해 준다.

Admin 도메인 서버를 실행하면 입력한 내용은 암호화 된다. startWebLogic.sh 를 실행하고 브라우져에서 http://weblogic 서버 IP:7001/console 을 입력하면 관리자 화면이 나오게 된다.

Tomcat 서버 로케일 설정

Windows 에서 Tomcat 9 서버를 CMD 에서 시작하면 화면에 뿌려지는 로그들이 한글이 깨진채 표시가 된다. 이것은 한글 로케일로 되어 있어서 Tomcat 서버가 한글로 뿌려주지만 CMD 가 한글을 표시할 수 없어 생기는 문제다.

이 문제를 해결하는 방법은 간단하다. CMD 의 로케일을 다음과 같이 변경해 주면 된다.

65001 은 UTF-8 을 의미한다. 이렇게 변경한 후에 Tomcat 을 재 실행하면 한글이 제대로 표시 된다.

하지만 Tomcat stdout 로그를 영문으로 바꾸고자 한다면 위 방법으로 되지 않는다. 이것은 Tomcat 서버가 Windows 10 의 기본 로케일을 자동으로 인식해 적용하기 때문이다. 만일 이것을 영문으로 바꾸고자 한다면 다음과 같이 해야 한다.

JAVA_OPTS 환경 변수에 user.language, region 을 정의해 주면 된다. 그러면 Tomcat 서버가 구동될때에 JAVA 파라메터로 추가해 로케일을 적용해 주면 UTF-8 에 Windows 10 에 로케일을 버리고 English 언어와 US 로케일이 적용되어 영문으로 로그가 출력된다.

Tomat 8.5 Manager 패스워드 암호화 하기

Tomcat 8 로 넘어오면서 manager 페이지 접근을 위한 패스워드 암호화 방법에 조금 변화가 있었다. 이에 대해서 기술한다.

Manager 페이지 접근 권한 – context.xml

기본값으로 /manager 페이지에 대한 접근은 localhost 로 제한이 걸려 있다. 이것은 manager 앱에 대한 context.xml 파일에 설정되어 있는 내용인데, 파일 경로는 $CATALINA_HOME/webpps/manager/META-INF/context.xml 이다. 다음과 같이 접근 제한된 부분에서 외부접속을 위한 설정을 해준다.

Valve 를 이용해서 RemoteAddrValve 에 대해서 접근 아이피 주소가 적혀 있다. 여기서는 접근 제한을 해제해주고 있다. 하지만 product 환경에서는 절대로 이렇게 하지말고 접근 가능한 IP 주소를 입력해주도록 하자.

암호화 알고리즘 정의 – server.xml

암호화 알고리즘에는 md5, sha-256, sha-512 등을 지정할 수 있다. 이를 위해서 server.xml 을 수정해 줘야 한다.

CredentialHandler 를 통해서 algorithm을 SHA-256 으로 정의해주고 있다. 중요한 것은 어디다가 해주냐하는 것임으로 위에 예제를 유심히 보고 정확한 위치에 이를 추가해줘야 한다.

암호화된 스트링 얻기 – digest.sh

이제 암호화된 스트링을 얻어야 한다. 이는 $CATALINA_HOME/bin/digest.sh 스크립트를 이용해서 손쉽게 얻을 수 있다. 주의할 것은 암호화 알고리즘에 맞는 암호화된 스트링을 얻기위해서 알고리즘을 옵션으로 알려줘야 한다.

결과에서 콜론(:)을 기준으로 앞은 평문 문자열, 뒤는 암호화된 문자열을 보여준다.

manager 인증 설정 – tomcat-users.xml

이제 manager 인증을 위한 설정을 해준다. 이는 tomcat-users.xml 해주는데, 다음과 같이 해준다.

위와 같이 암호화된 스트링을 password 인자로 주면 된다.

이렇게 Tomcat 8.5 에 대한 /manager 인증 암호 문자열 암호화 하기에 대해 알아 봤다.

Tomcat 설치 디렉토리 구성

과거에 Tomcat Multi Instance 설치에 관해서 쓴 글이 있다. Multi Instance 설치에서 핵심은 CATANINA_HOME과 CATALINA_BASE 를 분리하는데 있다.

오늘은 한발 더 들어가서 배포를 위한 설정과 시작, 종료 스크립트의 변경등에 대해서 이야기해보고자 한다.

Multi Instance 구성

Tomcat 을 다운로드 받아 압축을 풀면 그것이 곧 CATALINA_HOME 이 된다. 그리고 CATALINA_BASE 를 위해서 conf 디렉토리를 복사해주고 bin, lib, logs, temp, webapps, work 디렉토리를 생성해준다. 그리고 더블어서 war 파일을 배포를 위한 디렉토리를 Deployments 를 생성해주고 PID 저장을 위한 run 디렉토리도 생성해준다.

CATALINA_HOME 에서 복사해주는 디렉토리는 conf 밖에 없다는걸 상기해야 한다.

setenv.sh 작성

catalina.sh 스크립트를 보면 Tomcat 를 위한 설정등은 setenv.sh 를 읽어오도록 되어 있다.

CATALINA_BASE/bin/setsenv.sh 를 먼저 확인하고 없으면 CATALINA_HOME/bin/setenv.sh 를 찾도록 되어 있다.

setenv.sh 에는 CATALINA_OPTS, JAVA_OPTS 등의 환경변수등을 설정할 수 있다.  환경변수에 대해서는 catalina.sh 파일을 열어보면 자세히 나온다.

‘-Dport.http’ 와 같은 변수 선언은 server.xml 에 다음과 같이 활용할 수 있다.

그리고 이제 start.sh 와 shutdown.sh 는 다음과 같이 아주 간단하게 작성하면 된다.

CATALINA_HOME, CATALINA_BASE 디렉토리를 함께 정의해 준다.

기본적은 환경 변수를 start.sh, shutdown.sh 에 넣어주거나 하니면 별도로 빼서 소스해줘도 된다.

배포

Tomcat 에는 appBase, docBase 와 같은 지시자가 존재한다. 이것을 별도로 지정하지 않으면 webapps 디렉토리가 appBase, docBase 가 된다. 이를 분리하면 war 파일 배포와 app 실행 디렉토리를 분리할 수 있게 된다.

이를 위해서 먼저 server.xml 에서 다음과 같이 설정을 변경한다.

위와같이 Context 에서 docBase 로 war 파일을 지정하면 된다. 이렇게하면 war 파일을 읽어서 webapps 디렉토리에 압축을 해제하게 된다.

이렇게해야 하는 이유가 있는데, war 파일을 배포하는 디렉토리의 소유권을 배포계정으로 하고 others 에 읽기(read) 퍼미션만 준다. 즉, 운영계정과 배포 계정을 분리해서 운영할 수 있게 된다는 것이다.

배포는 conf/CATALINA/${virtualhost}/ 디렉토리에 context 이름으로 xml 파일을 작성해도 배포가 된다. Multi Instance 를 구성하게 되면 Manager 가 없게 된다. 그런데, 많은 사람들은 이를 CATALINA_HOME/webapps/manager 디렉토리를 CATALINA_BASE/webapps 디렉토리에 복사해 넣는다. 하지만 그렇게 하지 않아도 된다.

이를 ${catalina.base}/conf/Catalina/localhost/manager.xml 파일로 작성한다.

그러면 Tomcat 은 이를 읽어서 manager context 를 실행 준다.

왜 이렇게 하나?

CATALINA_HOME 과 CATALINA_BASE 를 분리하면 좋은 점이 업그레이드를 해야할 경우 나타난다.

몇몇 프로젝트하는 곳에서 Tomcat 설치된 것을 보면 CATALINA_HOME 에 startup.sh 파일이나 catalina.sh 파일을 직접 수정하는 경우를 볼 수 있다. 만일 보안 업데이트가 발생해 이를 Tomcat 업데이트를 해야한 경우라면 startup.sh, catalina.sh 파일을 새롭게 수정해줘야 한다.

하지만 CATALINA_HOME 과 CATALINA_BASE 를 분리하면 CATALINA_HOME 은 건드린게 없기 때문에 그냥 새로운 버전의 Tomcat 으로 바꿔치기하면 그만이다.

이는 휴먼 에러를 줄이는 확실한 방법이며 보안 업데이트 시간을 단축시켜준다.

 

Tomcat 시작 스크립트 옵션들.

Tomcat 시작 스크립트에는 많은 옵션들이 있는데, 이에 대해서 기술합니다.

start.sh 스크립트

Tomcat 을 시작하기 위해서는 CATALINA_HOME/bin/startup.sh 파일을 실행하면 된다. 이 스크립트 내용을 간단히 살펴보면 다음과 같다.

최종적으로 catalina.sh 파일을 호출하고 있는데, 이 파일에는 시작시에 사용할 수 있는 각종 쉘 환경 변수들이 나온다.

Catalina.sh 스크립트

CATALINA_HOME

Catalina 가 빌드된 디렉토리. 여기서 빌드된 디렉토리는 설치한 홈 디렉토리를 말하기도 한다.

CATALINA_BASE

Catalina 설치에 동적 영역을 해결하기 위한 기본 디렉토리. 이는 Multi Instance 설치할때에 에 사용된다. 만일 지정하지 않으면 CATALINA_HOME 을 사용한다.

CATALINA_OUT

stdout, stderr 를 어디로 보낼지에 대한 전체 경로를 지정. 기본 값은 $CATALINA_BASE/logs/catalina.out 이 된다.

CATALINA_TMPDIR

JVM 에서 사용할 (java.io.tmpdir) 의 임시 디렉토리 위치. 기본값은 $CATALINA_BASE/temp 이다.

CATALINA_OPTS

“start”, “run”또는 “debug”명령이 실행될 때 사용되는 Java 런타임 옵션. JAVA_OPTS 에 포함되는 옵션이 아닌것이 여기에 포함된다. Tomcat 자체에서만 사용되는 옵션들만 포함되며 중지 프로세스, 버전 명령 등으로는 사용해서는 안된다.

JAVA_HOME

JDK 설치한 위치. debug 인자와 실행할때 필요하다.

JRE_HOME

JRE 설치한 위치. 지정하지 않으면 JAVA_HOME 을 사용하고, JRE_HOME 과 JAVA_HOME 지정되면, JRE_HOME 를 사용한다.

JAVA_OPTS

명령이 실행될때 사용되는 Java 런타임 옵션. CATALINA_OPTS 모든 옵션이 아닌것이 여기에 포함된다. Tomcat 에의해서 사용되어질 수 있고 중지 프로세스, 버전 명령에도 사용된다. 대부분의 옵션들은 CATALINA_OPTS 에 있어야 한다.

CATALINA_PID

catalina 시작 java 프로세스의 pid 를 가지고 있는 파일 경로.

LOGGING_CONFIG

Tomcat의 로깅 설정 파일을 재정의. 예를들면 다음과 같이 한다.

LOGGING_MANAGER

Tomcat 의 로깅 메니저를 재정의. 예를들면 다음과 같이 한다.

 

CATALINA_OPTS, JAVA_OPTS 예제

여기서 중요한 CATALINA_OPTS, JAVA_OPTS 이다. 대부분 이를 구분하지 않는다. 하지만 설명에서 나왔듯이 구분해서 사용하는 것이 좋다. 예를들면 다음과 같다.

JAVA_OPTS 는 Tomcat 에서 사용되어질 변수들을 정의할 수 있다.

 

위와같이 구분을 해서 사용하는 것이 좋다.

WebLogic WLST 사용하기.

WebLogic 은 Administrator 를 위한 Web GUI 콘솔을 제공한다. 브라우저를 통해서 관리자로 로그인을 하면 Web 을 통해서 각종 설정들을 할 수 있게 된다.

하지만 Web 을 사용할 수 없는 환경이라면 무용지물이 된다. 이럴때 WebLogic Scripting Tools(WLST)를 사용하면 된다. 자바로 만들어지는 Tools 로서 Web GUI 화면 대신에 터미널상에서 실행되며 대화형식으로 Web GUI 콘솔에 모든 기능을 사용할 수 있다.

실행하기

실행은 먼저 WebLogic 서버의 전역 변수를 소스(Source) 함으로써 WLST 실행환경을 조성해 준다.

 

WLST 실행하기

이제 다음과 같이 WLST 을 실행한다.

이제부터는 대화형으로 명령어를 입력하고 결과를 받아보는 형식으로 진행이 된다. 위와같이 처음 접속을 하면 offline 으로 되는데 먼저 Admin 으로 로그인을 해보자. 이는 Web GUI 콘솔 로그인과 동일한 효과를 가지고 온다.

주의할것은 위 WLST 실행을 Admin 서버에서 했기때문에 URL 에는 127.0.0.1 로 접속한 것이다. URL 은 정확하게 Admin 서버에 주소와 포트를 입력해야 하며 Web GUI 로그인 하기 위한 계정을 입력하면 된다.

로그인을 하고 나면 이제 뭘해야할지 고민이 되는데, ls() 를 먼저 입력하면 Web Admin Console 의 내용이 텍스트로 화면에 뿌려진다.

자세히 보면 Linux 의 파일시스템을 보는듯한 느낌 그대로라는 걸 알게 된다. d 로 시작하는 것들은 마치 디렉토리처럼 생각하면 된다. 그 안에 뭔가 또 있다는 것이다. 그 안으로 들어갈려면 다음과 같이 하면 된다.

위와같이 서버 디렉토리에 들어가서 보면 등록된 서버들 목록을 볼수 있다. 각 서버의 설정값들이나 카테고리를 보고 싶다면? 그 서버로 들어가면 된다.

 

weblogic.Deployer 를 이용한 배포.

WebLogic 은 weblogic.Deployer 라는 Command Line 명령어를 이용해서 배포를 할 수 있습니다. 이를 통해서 GUI 화면인 WebLogic Admin Console 없이도 터미널을 이용해서 쉽고 빠르게 배포를 할 수 있는 것입니다.

setWLSEnv.sh 실행

터미널의 Command Line 에서 weblogic.Deployer 를 사용하기 위해서는 반드시 환경실행 파일을 먼저 실행해야 합니다. setWLSEnv.sh 라 불리우는 이 파일은 weblogic.Deployer 를 실행하기 위한 각종 라이브러리 클래스와 명령어 PATH를 세팅해 줍니다.

반드시 weblogic.Deployer 를 실행하기 전에 실행해줘야 합니다.

weblogic.Deployer 사용법

이를 사용하기 위해서는 반드시 Admin 서버를 주소와 포트를 알아야 합니다. WebLogic 의 모든 제어는 Admin 을 통해서만 가능하기 때문이며 weblogic.Deployer 실행하는 서버와 Admin 서버간의 통신도 가능해야 합니다.

배포된 애플리케이션 리스트

먼저 배포된 애플리케이션 리스트를 가져와 보겠습니다.

Admin 서버 주소와 포트를 -adminurl 인자로 주고 Admin Web Console 로그인 정보로 인증을 해줍니다. 마지막으로 배포된 애플리케이션 리스트를 출력하도록 -listapps 를 인자로 줍니다.

배포하기

배포를 하기 위해서는 먼저 Admin 서버에 업로드 디렉토리에 배포할 애플리케이션 파일이 존재해야 합니다. (뒤에 업로드도 하면서 배포하는 방법이 있습니다.)

그리고 다음과 같이 해줍니다.

배포가 완료 되었다. 하지만 여기에는 한가지 문제가 있습니다.

애플리케이션은 유지보수가 됩니다. 그래서 많은 변화가 일어나고 변화된 내용을 WebLogic 서버에 배포해야 합니다. 그런데, 배포할 파일 이름이 healthCheck.war 로 모두 동일하다면 WebLogic 서버에 배포하기 위해서는 기존의 배포된 파일을 제거하고 새로운 파일을 배포해야 합니다. 이는 사람이 수동을 다 해줘야 합니다.

버전 배포하기

만일, 배포시에 애플리케이션을 구분하기 위해서 버전정보를 준다면 WebLogic 서버는 자동으로 기존의 배포된 애플리케이션은 회수되고 새로운 버전의 애플리케이션이 활성화해주어 서비스를 지속할 수 있도록 해줍니다.

-appversion 1.0.1 은 배포되는 애플리케이션 버전이 1.0.1 임을 지정해 줍니다.

재배포 하기

재배포는 기존의 버전보다 업데이트된 버전으로 교체하는 것을 말합니다. 지금까지 배포할때 사용했던 -deploy 대신에 -redeploy 를 사용하고 버전은 기존의 것보다 높은 버전을 지정해주면 됩니다.

기존의 1.0.1 버전보다 높아진 1.0.2 를 사용했고 재배포하기 위해서 -redeploy 를 사용했습니다.

지금까지 배포 방법에는 한가지 문제가 있습니다. 전부다 Admin 서버를 대상으로 배포를 진행했다는 것입니다. weblogic.Deployer 는 배포할 서버를 지정해줄 수가 있습니다. 서버뿐만 아니라 Cluster 를 지정함으로써 Cluster 내에 포함된 모든 서버에 배포를 적용할 수도 있습니다.

타켓(Target) 지정 배포하기

배포 대상 서버, Cluster 을 타켓이라고 합니다. -targets 옵션을 주어서 지정할 수 있습니다.

타켓을 지정하면 결과 출력에도 타켓 서버가 함께 출력됩니다.

파일 업로드 배포하기

만일 원격에서 파일을 배포하려고 하는데, 배포 파일을 서버로 옮길 방법이 없을 경우에 파일 업로드와 함께 배포를 실행할 수 있습니다. 이를 사용하기 위해서는 먼저 업로드 디렉토리가 설정되어 있어야 합니다.

-upload 옵션과함께 -remote 옵션을 함께 사용합니다.

UnDeploy 하기

배포를 삭제하기 위해서는 undeploy 를 하면 됩니다. undeploy 할때에는 -source 옵션은 필요 없고 -version 과 -target 그리고 애플리케이션 이름 옵션인 -name 만 있으면 됩니다.