22. Spring Cloud Bus(broadcast push update)로 Config 적용하기 - #3 (Test)

1. config server에 적용할 내용의 application.yml을 만들고 테스트 할 microservice의 bootstrap.yml에서 읽어 들일수 있게 지정 한다

config sever에 있는 환경파일중 application.yml의 값 참조

2. test할 micro service의 환경 설정

api-gateway의 bootstrap.yml 설정

왼쪽은 테스트할 micro service의 bootstrap 설정, 오른쪽은 token과 gateway값 주석처리(config server의 application.yml 사용목적)

3. api-gateway와 micro service 재기동 후 점검

api-gateway를 재기동하면 적용된 profiles와 적용된 application.yml의 경로확인 가능

No active profile set, falling back to 1 default profile: "default"

BootstrapPropertySource {name='bootstrapProperties-file:///Users/yonghee.kim/Study/spring-cloud/MSA-local-repository/application.yml'}]

micro-service의 재기동 후에도 적용된 profiles와 적용된 application.yml의 경로확인 가능

위의 api-gateway와 동일한 값이 적용되었음을 알수 있다

현재 구동되고 있는 config server의 환경설정

4. 서비스 호출 후 token 확인

api-gateway에서 중단점 설정후 적용된 token.secret 확인

micro service에서도 동일한 token.secret이 적둉되었음을 확인 가능

5. 환경 설정을 변경한다

token.secret 변경(제일 뒤에 _change만 덧붙임)

6. web browser 확인

7. actuator busrefresh 실행

POST 맨으로 busrefresh 엔드포인트 실행

gpi-gateway와 micro service가 거의 동시에 refresh 시행

이렇게 된 사유는 micro service로 호출된 http://127.0.0.1:8000/actuator/busrefresh 내용이 rabbitMQ로 보내져서 api-gateway로도 동일한 환경파일을 적용하고 있는 서비스를 재기동하도록 push 했기 때문이다

busrefresh가 구동된 rabbitMQ의 Que상태

8. busrefresh 값 확인

api-gateway에서의 token.secret

micro service에서의 token.secret

busrefresh에 의하여 갱신된 같은 token.secret을 사용하여 기존과 같이 각기 다른 서버의 재기동 또는 actuator refresh로 개별서버 하나씩 재 기동하는 불편함이 해소된다