제1장 Spring Cloud Config - 개요

0. 시작하기에 앞서

회사에서 어쩌다 보니 클라우드 개발환경의 간단한 프로젝트를 맡게 되어,

Spring Boot + Pivotal Cloud foundry 조합으로 진행하게 됐습니다. ㅎㅎ

Spring Boot 는 Spring 환경설정에 어려움을 겪는 이들을 위한 프로젝트라는 선입견이 있었는데

프로젝트를 시작하기에 앞서 Pivotal 의 한 개발자분의 설명을 듣고 생각을 바꾸게 됐습니다.

이왕 하는거 매일매일 얻게 되는 새로운 걸 동료들에게 공유할 목적으로 포스팅을 합니다.

그 첫번째는, Cloud Config 입니다.

1. Spring cloud config 의 필요성

지금은 spring.profiles 덕분에 그런 곳이 많지 않겠지만 이전에는 로컬, 개발, 스테이징, 운영마다 

DB, 파일 업로드 경로, 특정 url 같은 properties 값이 다르므로

배포할 때마다 주석처리 혹은 파일 바꿔치기 등으로 각 서버마다 별도로 packaging 하여 배포를 해본 

아픈 기억이 있을 거라 굳게 믿습니다. 놀랍게도 일부는 Spring 을 사용함에도 불구하고 아직도 그렇게

하고 있죠. 혹시나 뜨끔하다면 spring.profiles 를 구글링하여 신세계를 맛보시기 바랍니다.

어쨌든, Spring.profiles 도 완벽하진 않습니다. 해결하기 힘든 문제가 하나 있거든요.

바로 환경설정 값을 변경하려면 반드시 Application 이 구동중인 서버를 재시작해야 한다는 겁니다.

아무리 이중화가 되어 있다고 한들, 서버 재시작은 부담스러운 작업이 아닐 수 없습니다.

간혹가다 재시작없이 Properties 값이 반영되길 고객이 요구할 때도 있구요.

그걸 해결해 주는 것이 Spring cloud config 입니다.

2. 동작 방식

이미지 하나로 설명이 충분합니다.

이미지 출처: https://docs.pivotal.io/spring-cloud-services/config-server/

보이는 것처럼 Config properties 가 git repository 에 있고,(svn 도 가능)

Config Server 는 git repository 를 바라보고 있으며, 각 Application 들은 Config Server 에서부터

자신들이 가져야할 Config 정보를 가져옵니다.

관리자에 의해 Git Repository 의 config 가 수정되었을 경우 Config Server 는 이를 감지하여 갱신하며,

각 Application 은 재시작없이 refresh 만으로 Config 정보를 갱신합니다.

3. 다음은

아래와 같이 프로젝트를 구성할 계획인데요.

우선 Git Repository 에 account-service, product-service 가 사용할 config 파일을 생성하고,

Config Server 가 이를 서비스할 수 있게끔 구성하는 것 까지 해보겠습니다.

참고로 이미 알고 있는걸 포스팅하는게 아니고 프로젝트를 진행하면서 알게되는 것들을 

정리하며 포스팅 하는거라 잘못된 이해로부터 잘못된 정보가 나올 수 있다는걸 감안해주시기 바랍니다.

끗 'ㅅ'