uEngine5 BPMS that totally re-written in Microservices architecture. uEngine5 can act as not only a conventional Workflow or BPMS but also as a REST api orchestrator or a BPaaS (Business process as a service) of members of OCE's MSA components.
그런데, Deployment 가 3개 있기 때문에 파일의 저장소가 각 인스턴스별 달라져서 External Ip 로 GET할때마다 있을때도 있고 없을때도 있다. 이 문제는 Replica 들이 동일한 저장소를 mount하도록 처리함으로서 해결할 수 있다 (continued)
Google Cloud Disk 의 mount
앞서 인스턴스간 파일 시스템 공유를 위한 작업으로 PersistenceVolume 과 PersistenceVolumeClaim 객체를 만든다:
kubectl get pods
kubectl get deployments
kubectl set image deployment/uengine-definition-deployment uengine-definition=uengine-definition-service:v2 #container 명=registry:tag
kubectl rollout status deployment/uengine-definition-deployment
kubectl get deployments
kubectl get pods
kubectl describe pods (podname)
롤백
kubectl get pods
kubectl get deployments -o wide
kubectl rollout undo deployment/uengine-definition-deployment
kubectl get deployments -o wide
Registry 서비스의 주소는 환경변수를 통하여 각 서비스에 전파시켜야 하는데, Kubernetes 에서는 각 서비스들의 주소를 전달하는 체계로 환경변수 혹은 내부 DNS 를 사용한다. 환경 변수는 유레카가 내려갔다 올라올때 전체 서비스의 재기동을 야기할 수 있으므로, 여기서는 내부 DNS를 사용하는게 좋다:
$ nano src/main/resources/application.yml
... dev, stg, prod 에 해당하는 profile 에서 설정 ..
eureka:
client:
serviceUrl:
defaultZone: http://eureka-svc.default.svc.cluster.local:8761/eureka/ #서비스명.네임스페이스명(기본은 default).svc.cluster.local 로 접근가능하다.
설정을 먹히게 하기 위해 1. 메이븐빌드, 2. 도커빌드, 3. 레지스트리 푸시, 4. 쿠버 desired state 변경을 아래와 같이 수행한다:
mvn package -B
docker build -t gcr.io/uengine5-k8s-project/uengine-definition-service:v2 . # 버전업
docker push gcr.io/uengine5-k8s-project/uengine-definition-service:v2
nano deployment.yml
(image 를 gcr.io/uengine5-k8s-project/uengine-definition-service:v2 로 변경 후 저장)
kubectl apply -f deployment.yml
[Tip] 환경 변수로 혹시 전달을 해야 하는 경우라면, 다음과 같이 모든 서비스들의 주소는 아래처럼 container 내부의 환경 변수로 전달됨을 확인할 수 있으므로, "Service명_HOST" 를 통하여 얻어낸 후 애플리케이션에 전달해주면 된다.
Definition Service 의 Deploy
Docker image 업로드
Deployment 만들기
Deploy 시키기
Service 생성하기
웹브라우저를 하나 열어, 확인된 External-IP 인 35.232.6.115 에 8080 으로 접속하면 아래와 같이 서비스가 열린것을 확인 가능:
[Note] 지금은 테스트를 위해 Definition Service 를 곧바로 LoadBalancer 로 바로 노출 시켜 인터넷에서 확인했지만 나중에 Zuul 로 포장하여 우회시키고 ClusterIP (내부 ip) 로만 서비스를 열 예정이다.
프로세스 정의의 deploy
그런데, Deployment 가 3개 있기 때문에 파일의 저장소가 각 인스턴스별 달라져서 External Ip 로 GET할때마다 있을때도 있고 없을때도 있다. 이 문제는 Replica 들이 동일한 저장소를 mount하도록 처리함으로서 해결할 수 있다 (continued)
Google Cloud Disk 의 mount
앞서 인스턴스간 파일 시스템 공유를 위한 작업으로 PersistenceVolume 과 PersistenceVolumeClaim 객체를 만든다:
각 Storage 는 gcloud 에서 미리 생성해두어야 한다. storage 생성방법은 아래와 같으며, project 와 동일한 region 에 생성시켜주야 한다.
그런후, 생성한 PersistenceVolumeClaim 을 Deployment 내의 spec 란에 mount 시켜주면 된다.
위와 같이 수정후, 반영:
무정지 재배포
롤백
오토스케일링
Availability 체크 통한 Self-Healing 관리
Netflix OSS 적용하기
Registry 서비스 올리기
서비스(LoadBalancer) 등록 통한 외부노출
Registry 서비스의 주소는 환경변수를 통하여 각 서비스에 전파시켜야 하는데, Kubernetes 에서는 각 서비스들의 주소를 전달하는 체계로 환경변수 혹은 내부 DNS 를 사용한다. 환경 변수는 유레카가 내려갔다 올라올때 전체 서비스의 재기동을 야기할 수 있으므로, 여기서는 내부 DNS를 사용하는게 좋다:
설정을 먹히게 하기 위해 1. 메이븐빌드, 2. 도커빌드, 3. 레지스트리 푸시, 4. 쿠버 desired state 변경을 아래와 같이 수행한다:
[Tip] 환경 변수로 혹시 전달을 해야 하는 경우라면, 다음과 같이 모든 서비스들의 주소는 아래처럼 container 내부의 환경 변수로 전달됨을 확인할 수 있으므로, "Service명_HOST" 를 통하여 얻어낸 후 애플리케이션에 전달해주면 된다.