Category: WAS

WAS 에 대한 카테고리

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 에서 사용되어질 변수들을 정의할 수 있다.

 

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

Jboss EAP 6 기초 보안

Jboss EAP 6 를 설치하고 난후에 해야할 기초 보안에 대해서 알아본다.

기본 페이지 비활성화 하기

Jboss EAP 6 를 설치하고 난후 도메인:포트 만 넣고 접속을 하면 다음과 같이 Jboss EAP 6 에서 제공하는 페이지가 나온다.

Jboss EAP 6 의 기본 페이지

내가 설정하지도 않았는데도 위와같이 Jboss EAP 6 에서 기본적으로 제공을 해준다. 이것을 안나오게 하고 싶다면 standalone-*.xml, domain.xml 파일에서 virtual-server 의 enable-welcome-root 값을 false 로 변경해주면 된다.

위와같이 고친후에 서버를 재시작하고 다시 접속을 하면 404 오류 페이지가 나온다.

jboss-cli 를 이용해서 다음과 같이 설정도 가능하다.

 

HTTP Header 에서 Server 값 변경하기

화면에는 잘 보이지 않지만, HTTP 프로토콜 보기에서 서버에서 응답한 헤더값을 보면 다음과 같이 나온다.

최대한 정보를 은닉하는 것이 보안상 권장하는 것으로 이것을 다른 값으로 바꿔 어떤 서버를 사용하는지 추론하지 못하도록 해야 한다.

역시, standalone-*.xml, domain.xml 혹은 host.xml 에서 다음과 같을 추가해준다.

jboss-cli 를 이용해서 다음과 같이 설정도 가능하다.

아니면 시작시에 -D 옵션으로 다음과 같이 주어도 적용된다.

 

HTTP Header 에서 X-Powered-By 값 변경하기

위 Jboss EAP 6 의 HTTP 응답 헤더를 보면 X-Powered-By 값이 보인다. 이 역시 서버 정보를 알려주는 것으로 보안상 안보이게 하는게 좋다.

역시, standalone-*.xml, domain.xml 혹은 host.xml 에서 다음과 같을 추가해준다.

jboss-cli 를 이용해서 다음과 같이 설정도 가능하다.

 

참고 사이트

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 만 있으면 됩니다.

 

Systemd for WebLogic 11g

Ubuntu 16.04, CentOS 7, RHEL 7 부터는 Systemd 로 Kernel 의 메인프로세스가 바뀌었습니다. 과거에는 Init 이였는데 이 배포판들은 systemd 로 바뀌었습니다.

리눅스가 부팅하면서 SystemV 인 Run Level 에 따라서 자동으로 시작시키기위한 Init Script 가 존재했었는데, Systemd 도 리눅스가 부팅하면서 시작되도록 하는 Systemd Script 가 존재합니다.

Systemd for WebLogic Administrator

WebLogic 을 Systemd 로 동작하는 배포판에 설치했다면 시작/중지 스크립트를 다음과 같이 작성할 수 있습니다.

WebLogic 의 Admin 서버가 구동될때에 각종 옵션들을 주고 싶다면 “USER_MEM_ARGS” 쉘 환경변수로 지정하고 ‘startWebLogic.sh’ 를 실행하면 그것이 적용된다. Systemd 에서 이러한 환경변수들은 ‘/u01/app/weblogic/config/domains/mCloud/servers/AdminServer/etc/default/adminserver’ 파일에 다음과 같이 정의해 줍니다.

 

Systemd for WebLogic Managed Server

Managed Server 를 시작하기 위해서는 ‘startManagedWebLogic.sh’ 스크립트를 사용하는데, 인자로 서버명을 주어야 합니다. 이것도 Admin 서버와 비슷하게 환경파일을 지정하고 그곳에 정의해주면 됩니다.

‘/u01/app/weblogic/config/domains/mCloud/servers/Server-0/etc/default/server-0’ 는 다음과 같습니다.

물론 USER_MEM_ARGS 환경변수를 지정할 수도 있습니다.

Systemd 등록.

Systemd 에 스크립트를 등록하기 위해서는 ‘/etc/systemd/system’ 디렉토리로 파일을 복사하고 다음과 같은 명령어를 입력해줍니다.

심볼릭 링크가 생성되면서 Systemd 스크립트가 등록이 됩니다. 등록이되면 이제부터 시스템이 꺼질때는 자동으로 WebLogic 도 꺼지고 시스템이 부팅되면 자동으로 시작이 됩니다.

 

WebLogic 11g Silent 설치

WebLogic 11g Silent 설치 에대한 글입니다. Oracle 제품군들을 설치하기 위해서는 GUI 환경이라야 한다고 생각하겠지만 GUI 환경이 아니더라도 설치가 가능한데, 이러한 방법을 Slient 설치하록 합니다. WebLogic 11g 도 Silent 설치를 지원 합니다.

Silent 설치에 핵심은 설치를 위한 각종 자료를 XML 파일로 작성하는 것입니다. ‘각종 자료’라고 함은 설치할 디렉토리, 설치할 컨포넌트등을 정의하는 것입니다.

설치 환경

설치 환경은 다음과 같습니다.

  • OS: Ubuntu16.04 64bit
  • Hostname: weblogic1.localdomain

 

설치 준비

호스트네임 변경

호스트네임을 변경해줍니다. 과거에는 파일을 조작해야 했지만 다음과 같이 hostnamectl 명령어를 이용합니다.

로그인을 다시하면 변경된 호스트네임이 반영됩니다.

계정생성

계정은 Oracle 제품군 설치를 위해서 oinstall 그룹과 weblogic 계정을 다음과 같이 생성합니다.

디렉토리 생성

Oracle 은 자사의 제품군에 대한 설치를 위해 디렉토리 구조를 정의놨는데 이것을 OFA(Optimal Flexible Architecture) 라고 부릅니다. OFA 는 단순하게 디렉토리만을 정의한것이 아니라 파일시스템, 스토리지 확장등을 모두 고려해 연구해 Oracle 에서 발표한 것입니다.

 

Weblogic 11g 설치를 위해 다음과 같이 디렉토리를 생성 합니다.

쉘 환경 변수 설정

weblogic 계정에 쉘 환경변수를 다음과 같이 만들어 줍니다.

Silent.xml 생성

이제 설치 명세서인 Silent.xml 를 다음과 같이 작성해 줍니다.

대략 위와같이 작성합니다. 각각의 내용은 Oracle 홈페이지 Silent.xml 에 나와 있습니다.

설치 

다음과 같이 설치를 진행 합니다.

설치는 의외로 금방 끝난다.

이제 설치가 정상적으로 되었는지 다음과 같이 테스트를 합니다.

 

도메인 생성

GUI 가 없기 때문에 도메인 생성도 역시 Console 상태에서 해야하는데, WebLogic 은 이것을 지원 합니다.

새로운 도메인 생성을 위해서 1번을 선택합니다.

도메인 생성을 위한 기존의 템플릿이나 필요한 컴포넌트 선택하는 것으로 여기서는 1번을 선택합니다.

필요한 기능을 갖춘 도메인을 선택한다. 기본 WebLogic 서버 기능만 힜으면 됨으로 나머지 선택을 하지 않고 그냥 엔터

사용할 도메인 이름을 입력하고 엔터.

여기가 중요하다. 앞전에 설치를 위한 디렉토리 생성시에 도메인을 위한 디렉토리를 다음과 같이 만들어준적이 있다.

  • /u01/app/weblogic/config/domains

따라서 도메인 디렉토리를 위 디렉토리로 변경해준다.

WebLogic 의 관리자 계정을 생성한다. 2번과 3번을 선택해 패스워드를 지정해준다.

운영모드 선택이다. 자신에게 맞는 환경을 선택한다.

설치된 자바를 선택해주면 된다.

여기서 반드시 Administration Server 는 해주도록 하자. 관리자 서버를 실행해야 웹콘솔 접속이 가능하지고 모든 작업이 웹콘솔을 통해서 가능하게 된다.

Administration 서버 설정으로 필요한 부분, port 나 Listen address 등을 바꿔주면 된다.

이로서 도메인 생성이 완료되었다.

WebLogic 을 비록한 Oracle 제품군을 설치할때에 GUI 모드를 고집하는 경향이 있다. 하지만 GUI 모드 설치를 위해서는 GUI 를 위한 각종 프로그램들을 설치해야하고 느린 네트워크 환경에서는 설치가 수월하게 되지 않는다.

Silent 모드 설치와 Console 모드에서 도메인 생성은 간편하면서도 의존성이 없는 텍스트만으로 이루어짐으로 어떤 환경에서든지 활용이 가능하며 쉽다.

Managed Server 인증 기동

WebLogic Admin 을 세팅하고 웹 콘솔로 접속한 후에 서버를 하나 생성하면 Managed Server 가 생성되는 것입니다. 이를 기동하기 위해서 터미널에서 다음과 같이 해줍니다.

그런데, 위와같이 인증을 위한 프롬프트가 나옵니다. 이는 Admin 서버와 통신을 위한 것으로 Admin 웹 콘솔 로그인을 위한 계정을 입력해주면 됩니다.

하지만 매번 이렇게 할려면 매우 힘든 일이고 기동 스크립트는 자동화가 필요한 부분이라 이부분을 자동인증으로 하기 위한 방법을 설명합니다. 이 방법은 다음 링크에도 잘 기술되어 있습니다.

Managed Server 마다 boot.properties 파일을 생성해 다음과 같이 로그인 정보를 적어 줍니다.

텍스트 파일로 작성해서 저장하는데, Managed Server 를 기동하면 이게 암호화가 되기 때문에 보안에 아무런 문제가 없습니다.

Java 동작모드 바꾸기

아무런 설정 없이 WebLogic 서버들을 시작하면, 다음과 같은 JVM_OPTION 들이 보입니다.

-client 모드로 기동이 되는데 이를 -server 로 바꾸어야 합니다. Java 의 동작 모드는 지속적인 서비스를 위해서는 -server 가 적합 합니다. WebLogic 에서 이를 바꾸기 위해서는 다음과 같이 고쳐줍니다.

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

이것을 해주지 않으면 구동시간이 아주 길어 집니다. 방법은 여러가지가 있지만 여기서는 전역환경변수에서 이것을 수정함으로써 해결 합니다.

위와같이 JAVA_OPTIONS 환경변수에 지정해줍니다.

 

WebLogic 11g 기동시 JAVA OPTION 넣기

WebLogic 11g 기동시 JAVA OPTION 넣기위해서 setDomainEnv.sh 나 commonEnv.sh 를 수정하는 경우가 있다. 하지만 이렇게 하면 WebLogic 11g 를 구성하는 Admin, NodeManager, ManagedServer 에 각각 따로따로 적용해주기위해서 앞에서 언급한 쉘 스크립트에 조건식을 줘야 한다.

setDomainEnv.sh 나 commonEnv.sh 는 WebLogic 서버에서 전역적으로 사용하는 것이기 때문에 특정한 부분을 위해서 수정하는 경우는 지양해야 한다.

최신의 WebLogic 11g 에서는 이러한 특정부분만을 위해 적용할 수 있는 JAVA OPTION 변수를 제공하는데 그것이 바로 USER_MEM_ARGS 이다. 쉘 환경변수로서 이것을 활용하면 Admin, NodeManager, ManagedServer 기동시에 JAVA OPTION을 줄 수 있다.

예를들어 Admin 서버를 기동할때에 사용하는 스크립트인 ${DOMAIN_HOME}/startWebLogic.sh 를 보자.

위와 같이 USER_MEM_ARGS 환경변수에 JAVA OPTION 값을 지정하면 WebLogic 이 구동시에 이것을 반영하게 된다.

ManagedServer 기동시에도 마찬가지다. 보통 ManagedServer 기동은 다음과 같이 한다.

하지만 이렇게하면 JAVA OPTION을 제공할 수가 없다. Server-0 로 불리우는 ManagedServer 기동을 위해서 일종의 랩퍼 스크립트를 다음과 같이 작성해보자.

위와같이 USER_MEM_ARGS 쉘 환경변수에 JAVA OPTION 값을 지정하면 이것을 반영하하여 Server-0 는 기동하게 된다.

WebLogic 11g 클러스터 설정.

WebLogic 11g 에서는 ManagedServer 를 클러스터 설정을 제공합니다. 역시나 Admin Web Console 을 통해서 클릭으로만으로 쉽게 간단하게 설정이 가능합니다.

WebLogic 11g 클러스터 설정

Admin Web Console 에서 다음과 같이 설정이 가능 합니다.

웹로직 11g 클러스터 생성
웹로직 11g 클러스터 생성

왼쪽에서 클러스터를 누르고나면 위 화면과 같이 나오고 “새로 만들기” 버튼을 눌러서 생성을 할 수 있습니다.

웹로직 11g 클러스터 생성
웹로직 11g 클러스터 생성

생성할 클러스터 이름을 입력해 줍니다. 적절한 이름을 입력해주면 됩니다. 두번째로 클러스터 멤버간 메시징을 위한 방법을 정의해줍니다. 유니캐스트와 멀티캐스트가 있는데 유니캐스트의 경우에는 클러스터 노드가 많지 않을 경우에 사용하는게 적절해 보이며 반대일 경우에는 멀티캐스트로 하는것이 적절해 보입니다.

생성이 완료되면 이제 생성된 클러스터에 대해서 설정을 해야 합니다. 클러스터 메뉴에서 생성된 클러스터를 클릭하면 다음과 같은 화면을 보실 수가 있습니다.

웹로직 11g 클러스터 로드 설정
웹로직 11g 클러스터 로드 설정

로드 알고리즘은 클러스터간 로드를 어떻게 분배할 것인가에 대한 것으로 서비스 형태에 따라 적절히 선택해주면 됩니다. 클러스터 주소의 서버 수는 클러스터에 나열할 서버 개수를 지정해 줍니다.

웹로직 11g 클러스터 서버 추가
웹로직 11g 클러스터 서버 추가

클러스터 메뉴에서 서버 탭에서 추가 버튼을 클릭해서 서버를 추가 할 수 있습니다. 서버를 추가할때에는 기존의 생성된 서버를 추가할 수 있고 서버를 생성하면서 추가할 수도 있습니다. 서버를 추가하면서 생성할때에는 NodeManager 서버가 실행중이여야 합니다.

Session Replication between Cluserted Node

클러스터내 서버끼리 세션을 복재하고 공유하기위해서는 weblogic.xml 을 다음과 같이 설정 해 주어야 합니다.

이렇게 설정한 후에 WebLogic 클러스터앞에 Proxy 서버를 설정하고 도메인으로 호출을 하면 클러스터간에 세션이 공유 됩니다.

추가

위 설정은 NodeManager 를 이용한  설정이다. 만일 NodeManager 없이 ManagedServer 를 구동한다면 Java CLI 에 다음을 추가 해줘야 한다.