티스토리 뷰
Config monitor 이해
WHY ?
config git repository의 config파일이 변경되면, 자동으로 MQ에 config 변경정보가 전송되고, MQ 채널을 구독한 각 마이크로서비스에게도 통보가 되어 동적으로 config변경 사항이 각 마이크로서비스에 반영되어야 합니다.
Spring Cloud bus는 이를 위한 방법을 제공하나, config git repository에 업로드 후 수동으로 MQ에 config 변경 정보를 요청해야 합니다.
즉, http://{config server host}/actuator/bus-refresh를 POST로 수행해야 합니다.
우리는 이를 자동화하기 위해 위 처리를 수행하는 application을 만들고, config git repository의 webhook으로 등록하였습니다.
Spring Cloud on kubernetes: 05. Clous bus를 참조하십시오.
Spring cloud config monitor는 별도의 webhook 어플리케이션 개발 없이, config server에 바로 요청할 수 있는 방법을 제공합니다.
Spring cloud config monitor는 git repository의 변경 사항을 통보 받기 위한 webhook end point를 제공하기 위해 필요합니다.
Spring Cloud on kubernetes: 05. Clous bus의 동작원리 그림에서 파란색box가 Spring Cloud Config Monitor입니다.
HOW ?
config monitor 라이브러리를 추가하고, spring.cloud.bus.enabled=true로 지정하면 config server에 '/monitor'라는 end point가 생성됩니다.
git config repository의 webhook주소로 http://{config server host}/monitor를 지정하고, config파일 수정 후 push합니다.
webhook 주소가 호출되고, config server는 변경된 config 정보를 MQ에 전송(Publish)합니다.
그럼 MQ는 채널을 구독하고 있는 각 마이크로서비스에 변경이 있음을 통보하게 되고, 각 마이크로서비스는 config server를 통해 변경 내용을 동적으로 reload하게 됩니다.
Config monitor 적용 및 테스트
config monitor는 config server에만 적용하면 되며, Spring cloud bus를 먼저 적용해야 합니다.
아직, Spring cloud bus를 적용하지 않았으면 Spring Cloud on kubernetes: 05. Clous bus을 참조하여 작업하십시오.
1. config monitor 라이브러리 추가
pom.xml에 config monitor를 추가합니다.
stream-rabbit라이브러리는 bus-amqp라이브러리가 추가되어 있으므로, 불필요합니다. 있어도 동작엔 문제 없습니다.
<!-- config-monitor -->
<!-- <dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency> --> <!-- bus-amqp만 있어도 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-monitor</artifactId>
</dependency>
2. spring.cloud.bus.enabled 활성화
application.yaml에 spring.cloud.bus.enabled=true를 추가합니다.
spring:
cloud:
...
# enable config monitor
bus:
enabled: true
3. config git repository의 webhook설정
http://{config server ingress host}/monitor로 설정하고, Content type은 application/json으로 변경하십시오.
기존에 http://{webhook host}/bus-refresh로 등록한 webhook설정은 삭제하십시오.
4. 테스트
1) 사전준비
브라우저에서 webhook swagger page를 여십시오.
그리고, NFS서버 접근하여 config server의 로그를 실시간으로 열어 놓으십시오. 아래 명령어 이용하세요.
k logs -f config-0
2) config git repository의 webhook-dev.yaml변경 후 push
STS에 config git repository를 추가하고, STS의 git commit&push기능을 이용하면 편합니다.
Spring Tool Suite, Eclipse에서 git commit & push하기를 참조하세요.
3) config 서버 콘솔과 '/greeting' API테스트
webhook:dev와 webhook-dev라는 어플리케이션의 config를 refresh하려고 합니다.
하지만, 이런 이름의 어플리케이션에 대한 config는 없으므로 MQ에 전송할 내용은 없습니다.
따라서, '/greeting' API를 다시 테스트해도 변경한 greeting메시지는 나오지 않습니다.
왜 config monitor는 어플리케이션 이름을 엉뚱하게 찾는걸까요 ?
변경된 파일명을 이용하여 어플리케이션을 찾기 때문입니다.
우리가 수정한 파일명이 webhook-dev.yaml이기 때문에 config monitor는 대상 어플리케이션명을 아래 2개로 판단합니다.
- {변경된 파일명} => webhook-dev
- {변경된 파일명의 dash앞에 값}:{변경된 파일명의 dash뒤의 값} => webhook:dev
따라서, 갱신될 config를 찾지 못하게 되는것입니다.
어떻게 해결해야 할까요 ? 제일 쉬운 방법은 {application명}으로 파일을 하나 만들고, webhook-dev.yaml과 webhook파일을 모두 수정하는 방법입니다.
한번 해 보시면 아래와 같이 config서버 콘솔에 표시되고, greeting값도 제대로 반영될것입니다.
Config monitor 개선
그런데, config파일을 수정한 후 항상 해당 어플리케이션명으로 되어 있는 파일도 수정해야 하는것은 매우 번거롭습니다.
좀 더 아름다운 방법은 없을까요 ?
config monitor의 application명을 판단하는 class를 overriding하면 됩니다.
1. config monitor의 application명 판단 class 소스 복사
spring cloud config의 github페이지로 접근합니다.
github.com/spring-cloud/spring-cloud-config
spring-cloud-config-monitor/src/main/java/org/springframework/cloud/config/monitor로 이동하여, PropertyPathEndPoint.java의 소스를 복사합니다.
2. PropertyPathEndpoint.java 소스 수정
아래와 같이 패키지 'org.springframework.cloud.config.monitor'를 만들고, 그 아래에 PropertyPathEndpoint.java를 만듭니다.
그리고, 복사한 소스를 붙여넣기 합니다.
마지막으로, 네모친 부분을 추가합니다. 수정한 파일명에서 dash앞 부분을 어플리케이션명 리스트에 추가하는 수행입니다.
3. overriding 허용 옵션 추가
spring cloud의 class들은 서버 시작 시 spring bean으로 생성되어 등록됩니다.
spring bean으로 만들어지는 class들은 기본적으로 overriding할 수 없습니다.
application.yaml에 아래 옵션을 추가하여 overrinding을 허용하십시오.
spring:
...
main:
allow-bean-definition-overriding: true
git repository로 push합니다.
4. config server 재배포
NFS서버에서 hklee 유저로 접속하여, git pull하여 새 소스를 다운로드한 후 run-cicd로 배포합니다.
[root@nfs ~]# su - hklee
마지막 로그인: 토 1월 16 03:50:44 CST 2021 일시 pts/0
[hklee@nfs ~]$ cd work/config
[hklee@nfs config]$ git pull
...
[hklee@nfs config]$ run-cicd hklee passw0rd . dev . java
5. 테스트
webhook-dev.yaml파일만 수정하고, push한 후 config서버 콘솔과 '/greeting' API를 테스트합니다.
이렇게 webhook-dev.yaml의 greeting값이 webhook어플리케이션에 바로 반영이 된다면 성공입니다.
configmng의 webhook밑에 있는 webhook파일은 이제 불필요하므로 삭제합니다.
'Micro Service > mSVC개발' 카테고리의 다른 글
[SC08] Spring Cloud Ribbon 이란 ? (0) | 2021.02.14 |
---|---|
[SC07] Spring Cloud Zuul 이란 ? (0) | 2021.02.14 |
[SC05] Spring Cloud Bus 란 ? (0) | 2021.02.14 |
[SC04] Spring Cloud Eureka 란 ? (3) | 2021.02.14 |
[SC03] Spring Cloud Config 란 ? (0) | 2021.02.14 |
- Total
- Today
- Yesterday
- 돌봄경제
- SAGA
- 리퀴드폴리탄
- Event Sourcing
- 버라이어티가격
- CQRS
- 분초사회
- 육각형인간
- 스포티파이
- AXON
- 요즘남편 없던아빠
- 마이크로서비스 패턴
- 호모프롬프트
- 마이크로서비스
- API Composition
- 애자일
- spotify
- 도파밍
- 스핀프로젝트
- agile
- 디토소비
- micro service
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |