본문 바로가기

Cloud/Docker, Kubernetes

[Docker,Kubernetes] JBoss/WildFly - 컨테이너 간 클러스터링 가이드 (kubeping 사용)

#. 참고 블로그 글

(예제 파일 & 설정 절차)

https://accordions.co.kr/it_trend/kubernetes%EC%97%90%EC%84%9C-wildfly-%EA%B0%80%EC%9A%A9%EC%84%B1high-availability-%EA%B5%AC%EC%84%B1/

https://ellin.com/2021/03/11/highly-available-wildfly-applications-on-kubernetes/

(yaml 파일 작성 시 에러)

https://www.inflearn.com/questions/421278/clusterrolebinding-%EC%83%9D%EC%84%B1%EC%8B%9C-%EC%98%A4%EB%A5%98

(kubernetes namespace 관련)

https://artist-developer.tistory.com/33

 


 

#. Docker 설치

아래 가이드 참고

명령어 - 도커 설치, JBoss 컨테이너 실행.txt
0.00MB

 

 

#. kubernetes 설치 (minikube)

아래 가이드 참고

명령어 - 쿠버네티스 설치.txt
0.01MB

 


 

#. 실습 파일 & 작업 명령어

아래 실습 파일 다운로드하여 참고

(JBoss / WildFly 설치파일은 각각 RedHat / WildFly 홈페이지에서 다운로드)

jboss_kubeping_test.zip
4.00MB

 

실습에 사용한 alias 설정

https://hyuunchul.tistory.com/292

 


 

#. TCP 방식으로 HA 구성 필요

온프레미스 환경에서의 Wildfly HA 구성은 TCP/UDP 프로토콜을 통해서 가능하다.

하지만 Kubernetes 환경에서는 Container Network Interface 에 따라 UDP Multicast를 지원하지 않는다.

따라서 TCP 프로토콜만 사용 가능하다.

 


 

#01. Docker start & Kubernetes start

테스트 환경

Docker 20.10.22

minikube 1.28.0 

 

Docker 서버 기동

(alias 사용 X)
systemctl start docker
systemctl status docker

--------------------------------------------

(alias 사용)
docker_start

 

minikube 서버 기동

(alias 사용 X)
minikube start --driver=docker

--------------------------------------------

(alias 사용)
minikube_start

 

minikube env 세팅

linux 에서 bash profile을 통해 env 세팅을 하는 것과 같이
minikube 관련 env 세팅을 완료해야 정상적으로 minikube 사용이 가능해진다

minikube 서버 기동 후에 아래 명령어를 실행한다
eval $(minikube -p minikube docker-env)

 


 

#02. kubernetes namespace 생성

실제 운영 환경에서는 각 업무마다 namespace를 생성하여 업무 별 deployment를 구분짓는다.

WebLogic의 domain과 비슷한 개념으로 이해하면 될 듯 하다

테스트에 사용할 namespace를 별도로 만들어주도록 한다.

(생성 명령어)
kubectl create namespace {이름}

----------------------------------------------------------

(예시)
"jboss-test" 라는 이름의 namespace 생성
kubectl create namespace jboss-test

----------------------------------------------------------

(생성한 namespace 확인하기)
kubectl get namespace

 


 

#03. Docker image build

config 파일은 standalone-ha.xml 를 사용한다.

full-ha 프로파일을 사용하면 activemq 서브시스템이 추가되는데,

activemq 사용을 위해서는 http 서비스 포트 방화벽이 open 되어야 한다.

방화벽이 막히면 connection refused 경고성 로그가 발생한다.

 

이미 ha 프로파일에서 jgroups로 클러스터링을 구현하므로, activemq 기능은 필수가 아니다.

불필요한 기능을 위해 추가적으로 방화벽 open 작업을 하는 것은 비효율적이며,

기능 추가로 인해 장애 point만 늘어나게 되므로 사용하지 않는 것이 좋아보인다.

ful-ha 프로파일은 꼭 필요한 경우에만 사용하자.

 


 

docker image build 작업에 필요한 파일들은 아래와 같다.

별도의 기동 스크립트를 작성하지 않고, standalone.sh 파일에 각종 옵션 값을 작성하였다.

이에 대한 이유는 다음 항목 참고

#. 필요한 파일 목록 확인

(Dockerfile 파일)
 - Dockerfile

(서버 엔진 파일)
 - jboss-eap-7.4.7.zip

(config파일, 기동스크립트)
 - standalone-ha.xml
 - standalone.sh

(JDBC 관련 파일)
 - ojdbc8.jar
 - module.xml

(테스트용 어플리케이션 파일)
 - ROOT.war

--------------------------------------------------------------

#. image build
docker build --rm -f Dockerfile --tag=jboss-cluster .

 


 

#04. kubernetes deployment 생성 및 pod 기동

별도의 기동 스크립트 사용이 불가하다.

JAVA_OPTS 등 각종 옵션 값은 standalone.sh 스크립트 내에 작성해야 한다.

 

kubernetes deployment를 생성하는 yaml 파일 내에서

POD_IP 환경변수를 jboss 서버 기동 시에 IP Address 설정 옵션값으로 사용하기 때문.

 

 

container 내부에 별도의 기동 스크립트를 생성하여 POD_IP 환경변수를 사용하는 방법은 불가하다.

해당 POD_IP 환경변수는 container 내부에서 사용하는 환경변수가 아닌

kubernetes deployment 생성 시에 사용되는 환경변수이기 때문이다.

따라서 jvm option 등 각종 옵션값 작성은 standalone.sh 스크립트에 직접 추가해야 한다.

문제 발생 시에 참고할 수 있도록 standalone.sh 원본 파일을 반드시 백업 해 두어야 할 것.

 


 

kubernetes deployment 생성 작업

1. namespace 생성 확인

kubectl get namespace

앞서 추가한 namespace 확인
=> jboss

================================================

2. namespace에 클러스터링 정책 설정

kubectl apply -f 01_cluster_setting.yaml
	=> yaml 파일 내부에 namespace 이름 확인

================================================

3. deployment 생성 및 pod 기동 확인

"jboss-test" namespace에 deployment 를 적용한다
kubectl apply -f 02_jboss_deploy.yaml -n jboss-test

kubectl get deployment -n jboss-test
=> "jboss-test" namespace 에 deployment가 생성되어있다

kubectl get pod -n jboss-test
=> "jboss-test" namespace 에 pod 2개가 실행되어있다

 


 

#05. jboss log 확인

pod 내부로 ssh 접속하여 log 파일 확인

(alias 사용 X)
minikube kubectl -- exec -ti -n ${NAME_SPACE} ${POD_NAME} -- sh

--------------------------------------------

(alias 사용)
minikube_pod_ssh

 

 

pod 간에 정상적으로 클러스터링 맺어졌는지 확인.

${JBOSS_HOME}/standalone/log/server.log 로그 확인

 

아래와 같이 cluster member가 2개 추가되어 있으면 정상

 

jboss pod가 delete 되고, 새로운 pod가 생성되면서 발생하는 로그

jboss pod가 delete 되었을 시의 로그
Node jboss-cluster-5f594587b8-h5wvc left the cluster

--------------------------------------------

새로운 jboss pod가 생성되었을 시의 로그
Node jboss-cluster-5f594587b8-h5wvc joined the cluster

--------------------------------------------

새로운 클러스터 맴버가 추가되면서 load balancing 조절하는 로그
Starting rebalance with members

 


 

#. JBoss Management Console 접속

Management Console 에 접속하고자 한다면 management port를 포트포워딩 한다.

Deploy 한 어플리케이션을 호출하고자 한다면 http port를 포트포워딩 한다.

 

포트포워딩 명령어

(alias 사용 X)
minikube kubectl -- port-forward -n ${NAME_SPACE} ${POD_NAME} --address=${IP_ADDRESS} ${PORT}

--------------------------------------------

(alias 사용)
minikube_port_forwarding

 

alias 사용 예시

 

Management Console 접속 확인

 


 

테스트 진행하면서 새로 알게 된 내용

deployment apply yaml 파일에서
IP address를 0.0.0.0 으로 해야
포트포워딩 정상적으로 작동함......

이렇게 되면 각 jboss 컨테이너의 실제 ip address가 있는건지 없는건지 확인 필요
apache 연동 시에 문제가 될 수도
=> 블로그 글 확인해보니 apache 서버를 동일 컨테이너에 같이 구성해야 하는 듯
=> worker.properties 파일에 ip address를 localhost로 명시함

고객사 쿠버네티스 프로젝트 환경에서도
apache 연동 시에 modjk 사용하지 않고, 다른 프록시 방식 사용하였음


kubectl create namespace jboss-cluster-namespace

docker build --rm -f Dockerfile --tag=jboss-cluster .

kubectl apply -f 01_cluster_setting.yaml

kubectl apply -f 02_jboss_deploy.yaml

kubectl get deployment -A

kubectl get pod -Ao wide

===============================================================================================

minikube kubectl -- port-forward -n default jboss-cluster-64f9ddfdbb-rzm9v --address=192.168.55.169 9100:9100