[MSA스터디] 12. 구성 중앙화

스프링 클라우드 컨피그 서버를 사용해 마이크로서비스의 구성을 중앙화해서 관리하는 방법에 관한 챕터

이번 장에도 spring-cloud 폴더 하위에 config-server 프로젝트가 생긴다.

스프링 클라우드 컨피그 서버 소개

구성 서버 == spring cloud config server

이전장까지 시스템 환경의 모습은

이러했고 이번 구성 중앙화 챕터를 거치면서 spring cloud config server가 추가되면

이런 모습이 된다.

❓ 구성 서버 설정에 고려사항
1 구성 저장소의 저장 유형을 선택
2 client가 먼저 접속할 서버를 결정 between 구성 서버(컨피그)와 검색 서버(유레카) 중에서
3 구성 보안을 강화 (== API에 대한 무단 접근을 막고 중요한 정보는 일반 텍스트로 저장X)

1 구성 저장소의 저장 유형을 선택

❓ 저장 유형이라는게 '구성서버는 무엇을 저장하는가 ' 가 아니라 '구성서버는 어떤 저장 유형을 지원하는가' 이다! 그럼 구성서버는 어떤 저장 유형을 지원하는가

• git 저장소
• 로컬 파일 시스템
• 하시코프 볼트(Hashicorp Vault)
• JDBC 데이터베이스

이번 챕터에서는 로컬 파일 시스템을 사용한다.
로컬 파일 시스템을 사용하려면 native 스프링 프로필을 활성화한 후 --> 구성 서버를 시작해야 한다. 구성 저장소의 위치는 spring.cloud.config.server.native.searchLocations 속성으로 지정

2 client가 먼저 접속할 서버를 결정

❓ 어떤 서버에 먼저 클라이언트가 접근해야하는가
basicly)
client가 구성 서버에 먼저 접속 --> 구성을 검색하며 -->구성에 따라 검색
서버(유레카)에 자기 자신을 등록
also)
client가 검색 서버에 먼저 접속 --> 구성 서버 인스턴스를 찾은 다음 --> 구성 서버에서 구성을 가져올 수도 있음

각 접근 방식에는 장단점이 있음
구성 서버에 먼저 접속 하는 방식으로 이번장 진행 --> 검색 서버(유레카)의 구성 정보를 구성 서버(cofig server)에 저장

3 구성 보안을 강화

❓ 보안을 왜 강화해야하는가
b/c 구성 정보는 중요한 정보로 취급해야 하므로 구성 정보를 전송하거나 저장할 때는 보안에 신경써야 함. --> so 런타임 관점에서는 구성 서버가 에지 서버를 통해 외부로 노출될 이유가 없음.
(개발이 진행 중일 때는 구성 서버 API에 접근해 구성을 확인하는 것이 유용하지만, 상용 환경에서는 구성 서버에 대한 외부 접근을 차단해야 함!)

• 구성 전송 보안 by https
  마이크로서비스나 config 서버 API 사용자의 구성 정보 요청 : HTTPS를 사용하는 에지 서
  버에 의해 보호.

• 구성 저장 보안 by 대칭키 (암호화)
  구성 저장소 접근 권한이 있는 사람이 민감 정보 steal 을 막기위해서 : 구성 정보를 암호화해서 디스크 저장 (config server는 대칭 키와 비대칭 키를 모두 지원) (비대칭 키가 더 안전하지만 관리는 어렵)

구성 서버 api

구성 서버는 클라이언트가 구성을 검색할 수 있도록 REST API를 공개
이번장 api 엔드포인트

• /actuator: 모든 마이크로서비스가 노출하는 표준 actuactor endpoint (❗상용 환경에선 잠겨있어야 함.)

• /encrypt & /decrypt: 중요한 정보를 암호화하고 해독하기 위한 엔드포인트 (❗상용 환경에선 잠겨있어야 함.)

• /{microservice}/{profile}: 지정한 마이크로서비스의 스프링 프로필 구성을 반환.

구성 서버 설정

spring-cloud 하위에 'config-server' project 생성

security와 config server 의존성 추가

메인 클래스에 @EnableConfigServer 추가

application.yml 구성 추가

• spring.cloud.config.server.native.searchLocations --> 구성 저장소 위치 지정

gateway에 라우팅 규칙 추가
위의 그림처럼 /config 뭐시기 로 들어오는 요청은 구성서버로 라우팅 된다

dockerfile 추가 하고 compose파일에 추가
구성 서버의 Dockerfile은 8888 포트가 8080 포트를 대신한다는 점 외에는 다른 마이크로서비스와 같음

민감한 구성 매개 변수는 표준 도커 컴포즈 환경 파일인 .env 파일로 외부화

공통 빌드 파일인 settings.gradle에 구성 서버를 추가

구성 서버의 클라이언트 구성

1 클라이언트에 config와 retry 의존성 넣어주기

2 구성 파일(application.yml)을 구성 저장소로 옮기고, 이름을 spring.application.name 속성에 지정된 클라이언트 이름으로 변경

얘만 냅두고 나머지 다 옮기기

3 src/main/resources 폴더에 이름이 bootstrap.yml인 파일을 추가한다 (구성 서버에 연결하는 데 필요한 구성 정보가 담겨 있음)

4 도커 컴포즈 파일에 구성 서버 접근에 필요한 자격 증명을 추가
(위에서 해씀 )

5 스프링 부트 기반의 자동 테스트를 실행할 때는 구성 서버를 사용하지 않도록 비활성화

spring.cloud.config.enabled=false

이랬던 곳에

이런식으로 다 바꿔주기

연결 정보 설정

src/main/resources/bootstrap.yml 파일 : 구성 서버에 연결할 때 필요한 클라이언트 구성이 담김
애플리케이션 이름이 지정된 spring.application.name 속성 외에는 모든 구성 서버 클라이언트의 구성이 같음 .

파티셔닝 구성을 도커 컴포즈 파일에서 구성 저장소로 이동

• 메시지 브로커(RabbitMQ, 카프카)의 파티션을 처리하기 위한 추가 구성 옮기기 : 도커 컴포즈 파일인 docker-compose-partitions.yml 및 docker-compose-kafka.yml에는 파티션 처리 구성 정보도 중앙 구성 저장소로 옮겨야 함
  
  재사용성을 높이고자 구성을 여러 개의 스프링 프로필로 나누고, 구성 저장소에 있는 해당 구성 파일로 이동시키고

메시지 소비자인 product, resources, recommendation 서비스의 구성 파일에도 구성을 추가해주고

메시지 프로듀서인 product-composite 서비스의 구성 파일에도 추가해주기

구성 서버 접속을 위한 자격 증명과 활성화할 스프링 프로필만 해주면 된다.

스프링 프로필 정보 이런식으로 주면된다

구성 저장소 구조화

구성 저장소 모든 구성파일들을 이동시킨 후에--> 액추에이터 엔드포인트나 유레카, RabbitMQ, 카프카 접속 정보와 같이 각 클라이언트가 공통으로 사용하는 구성 정보를 정리해 모든 클라이언트가 공유하는 application.yml 파일로 옮기기

설정들이 완료됐으니 빌드해볼까나

음.. 기대도안했다..^

지난번이랑 같은 에러

엊그제 민서가 빌드는 되었다고 해서 민서 코드랑 비교하면서 봐밨다

implement 하고 있는 ProductCompositeService 에서 return 값이 잘못되어있었다

저자의책에서는 이내용을 소개를 안해줬다! 내잘못인지 헷갈리지만 어잘수없지 그래도 방법을 찾았다 다시 빌드를 해보자

아까건 넘어갔지만 테스트 관련해서 fail 에러가 난다
음.. test없이 빌드를 하면 성공이 되지만 무슨소용인가..

스프링 클라우드 컨피그 서버 실습

^이론상으로^

• 구성 서버 API로 구성 조회 (/config 로 시작하는 url로)
  URL 접두어 /config를사용+ .env 파일에 저장된 자격 증명으로 HTTP 기본 인증 해줘야함
  curl https://dev-usr:dev-pwd@localhost:8443/config/product/docker -ks
  를 통해 docker 스프링 프로필을 활성화해 도커 컨테이너로 product 서비스를 실행 가능하다

-- 응답에서 여러 개의 프로퍼티 소스와 그 속성들이 포함되어있음 (property source-우선순위에 따라 반환된다)

• 정보를 암호화 및 해독 using 구성 서버에서 공개하는/encrypt 및/decrypt 엔드포인트를 사용
  -- 암호화
  curl -k https://dev-usr:dev-pwd@localhost:8443/config/encrypt --data-urlencode "hello world"
  --해독화
  curl -k https://dev-usr:dev-pwd@localhost:8443/config/decrypt -d 9eca39e823957f37f0f0f4 d8b2c6c46cd49ef461d1cab20c65710823a8b412ce
  -- 구성파일에 암호화된 값 저장하기 위해서는 {cipher}를 접두어로 하고 작은따옴표로 감싸기

정리 및 느낀점

12장에서는 스프링 클라우드 컨피그 서버를 사용해 마이크로서비스의 구성을 중앙화해서관리하는 방법을 배웠음
마이크로서비스 수가 중가 --> 관리하고 업데이트해야 하는 구성 파일 수도 증가가 당연 🤗
so) 스프링 클라우드 컨피그 서버를 사용
for) 모든 마이크로서비스의 구성 파일을 중앙 구성 저장소에 두고 관리

구성 서버 : HTTP 기본 인증을 사용해 구성 정보를 보호하므로 자격 증명을 제공하는 사용자만 API를 사용 可

• 구성서버api : HTTPS를 사용하는 에지 서버를 통해 외부로 노출
• 민감정보 : 구성 서버의 /encrypt 엔드포인트로 암호화해서 디스크에 저장

config 서버는 서비스 개발 중에 configuration 파일이 너무 많아져서 (우리 프로젝트에서도 resources폴더 밑에 프로퍼티나 yml파일들이 db, s3, 등드을 사용하면서 많아진것처럼 ) 관리가 힘들 때 사용하는 방법인 것 같음. 그래서 개발환경에서 편리성을 위해 개발된 서버인 것 같다.
음~ 그렇군~