[MSA] Spring Cloud Config Server

Spring Cloud Config Server

- http://start.spring.io 에 접근한다. 

- artifact 에 config-service 와 같은 그럴듯한 이름을 넣어준다. 

- Dependencies 에서 Config Server 를 찾아 추가한다. 

- Generate Project 를 눌러 Zip 파일을 다운로드하고, 이를 IDE 를 사용해서 연다. 

- config-service/src/main/java/com/example/ConfigServiceApplication.java 에 @EnableConfigServer 어노테이션을 추가한다. 

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;


@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {

   public static void main(String[] args) {
      SpringApplication.run(ConfigServiceApplication.class, args);
   }
}

- application.properties 파일에 아래의 설정을 추가한다. 설정 파일이 위치한 코드 저장소는 github 를 사용했는데, 별도의 git 또는 파일 저장소를 사용할 수 있다. 자세한 내용은 위의 Config Server 설정 부분을 참조 

spring.application.name=config-server
spring.cloud.config.server.git.uri=https://github.com/younjinjeong/spring-cloud-event-sourcing-config
server.port=8888

- 애플리케이션을 빌드하고 실행한다. 

mvn clean package
java -jar target/config-server-0.0.1-SNAPSHOT.jar

따로 설명하지는 않았지만, 스프링 부트 애플리케이션을 구동하기 위해 별도의 WAS 를 사용하지 않았음에 주목한다. 최근 이런 Fat JAR 를 어떻게 서비스에 구동해야 하는지 여쭈어 보는 분들이 종종 계신데, 많이 목격되는 것은 다커(Docker) 를 사용하거나 Cloud Foundry 와 같은 런타임 플랫폼을 사용할 수 있다. 자세한 설명은 따로. 어쨌든 서비스가 정상동작 하는지 확인하기 위해서, 위의 github 를 사용하는 경우 다음의 링크를 통해 확인이 가능하다. http://localhost:8888/user-service/cloud

 

어쨌든 위와 같은 작업을 통해 이제 웹 요청을 통해 코드 저장소에 저장된 설정을 전달할 수 있는 서버가 준비되었다. 서버가 준비되었다면, 클라이언트를 연결해 본다. 

Config Server client 

- http://start.spring.io 로 접근 

- artifact 에 config-client 를 넣는다. 

- Dependencies 에 Config client 를 선택한다. 이외에 원하는 부트 애플리케이션을 만들기 위해 Web, Rest repo, H2 등 원하는 도구를 선택한다. 

- Generate project 를 눌러 프로젝트 파일을 다운로드 받고 압축을 해제하여 IDE 로 개봉한다. ㅎ 

- 별도의 어노테이션 추가는 필요 없지만, 설정 파일에 Config server 의 위치를 명시해야 한다. config-client/src/main/resources/bootstrap.properties 파일을 생성하고 (application.properties 가 아님에 주의) 아래와 같이 Config server 의 위치를 명시해 준다. 

spring.cloud.config.uri=http://localhost:8888
spring.application.name=config-client

- 만약 Github 나 별도의 코드 저장소를 사용한다면, config-client.properties 를 생성하고 아래와 같이 간단한 설정을 넣고 Config 서버에 연결된 코드 저장소에 push 한다. 

server.port=${PORT:9999}

- 이전에 만들어 둔 Config 서버를 시작한다. 

- 지금 생성한 config-client 애플리케이션을 시작한다. 

.   ____          _            __ _ _
/\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
'  |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot ::        (v1.4.0.RELEASE)

2016-09-19 12:28:37.699  INFO 3977 --- [           main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://localhost:8888
2016-09-19 12:28:42.443  INFO 3977 --- [           main] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=config-client, profiles=[default], label=master, version=afb483b02756c38f5c2ce3a3e0ad149aefe100c3
2016-09-19 12:28:42.443  INFO 3977 --- [           main] b.c.PropertySourceBootstrapConfiguration : Located property source: CompositePropertySource [name='configService', propertySources=[MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/config-client.properties'], MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/config-client.yml'], MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/application.yml']]]
2016-09-19 12:28:42.503  INFO 3977 --- [           main] com.example.ConfigClientApplication      : No active profile set, falling back to default profiles: default

애플리케이션을 시작하면, 위와 같이 아름다운 Spring 아스키 이미지와 함께 메세지를 확인할 수 있는데, 내용인 즉슨 다음과 같다. 

Fetching config from server at: http://localhost:8888 

애플리케이션이 시작되면서 Config server 로 부터 설정 내용을 가져온다. 그리고 애플리케이션이 정상적으로 시작되었다면, 아래의 내용을 확인할 수 있을것이다. 

Tomcat started on port(s): 9999 (http) 

즉, 설정 파일의 내용을 스프링 애플리케이션이 참조하여 해당 애플리케이션의 포트를 9999로 설정한 것이다. 스프링 부트의 특징중 하나는 각종 설정의 오버라이드가 매우 쉽다는 점인데, 이것들은 서로 참조되는 순서가 있다. 첫번째로 참조되는 것이 바로 bootstart.properties 로, 이 파일에 있는 내용은 애플리케이션의 이름, config server 의 위치와 같이 거의 변경되지 않는 내용을 넣는다. 두번째로 참조되는 것이 이 경우에는 Config server 에 있는 설정 파일의 내용인데, 여기에서 역시 참조 순서가 있다. config server 가 참조하는 코드 저장소에 있는 설정 파일의 이름에 application.properties 가 있다면, 여기에 있는 내용은 모든 config server 를 참조하는 config client 들이 참조하는 전역 설정과 같은 것이다. 그리고 이와 함께 [application-name].properties 가 있다면, 이 application.properties 위에 설정을 merge 해서 사용한다. 이때 동일한 설정이 있다면 이기는 쪽은 애플리케이션이름.프로퍼티 파일이 되겠다. 

이러한 우선 순위 규칙에 따라 애플리케이션 설정의 참조 순서를 적용할 수 있으며, 더욱 중요한 것은 이를 통해 설정과 코드를 분리 할 수 있다는 것이다. 스프링 부트 애플리케이션은 시작할때 서버의 설정 내용을 참조하여 스스로를 설정하며, 이는 12 factor 애플리케이션의 config 부분에 취급되는 매우 중요한 내용중 하나가 되겠다. 그리고 이 포스팅에서 구체적으로 언급하지는 않지만, 각 설정 파일을 환경 별로 생성할 필요 없이 사용될 환경을 지정해서 사용하는 것도 가능하다. 이는 프로파일 이라고 불리는데, 위의 애플리케이션의 시작 로그를 살펴 보면 아래와 같은 로그가 남는것을 확인 할 수 있다. 

No active profile set, falling back to default profiles: default

따라서 여러분이 사용하는 환경 별로 test, staging, production, cloud 와 같은 형태로 구성하여 사용할 수 있다는 것이다. 

Config 에는 다소 민감한 내용들이 있을 수 있다. 이를테면 특정 애플리케이션의 패스워드, 데이터베이스 연결정보, 클라우드 서비스 공급자의 API 키와 같은 내용들이다. 이런 내용들을 보호하기 위해 암/복호화를 사용할 수도 있겠다. Config server 의 보안에 대해서는 아래의 링크를 살펴보기를 권고한다. https://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_security 

마지막으로, Config 서버는 애플리케이션의 재시작 없이 설정을 변경할 수 있는 메커니즘을 제공한다. 즉, 이미 온라인 상태에서 동작하고 있는 애플리케이션의 feature flag라던가, a/b 테스트 용도의 기능 변경과 같은 것들을 이 변경 가능한 설정에 적용할 수 있다. 적용하는 방법은 아래의 Josh 코드에서 살펴볼 수 있다. 이는 @RefreshScope 라는 어노테이션을 사용하는 것으로 가능하다. 아래의 간단한 코드는 message 라는 설정이 config repo 에 있고, 이를 즉시 변경할 수 있는 예제이다. 

@RefreshScope
@RestController
class MessageRestController {

    @Value("${message}")
    private String message;

    @RequestMapping("/message")
    String message() {
    return this.message;
    }
}

이렇게 구성된 코드는 설정 파일에서 (또는 config repo에서) message 로 지정된 내용을 가져와 /message 에 요청이 있을때 응답한다. 만약 예전의 방법으로 이를 구성한다면, 메세지를 변경할 때마다 (데이터베이스를 사용하던지) 아니면 설정을 수정/ 또는 코드를 수정하여 새로 빌드 후 배포해야 동작할 것이다. 하지만 Config client 에서는 이를 empty post 요청을 보냄으로서 처리가 가능하다. 이에 대한 설명은 아래의 링크를 참조한다. http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_refresh_scope

유레카와 마찬가지로, config server 역시 '설정 및 적용'을 위한 하나의 마이크로 서비스 애플리케이션으로 생각할 수 있다. 이는 당연하게도 유레카 서비스와 함께 연동해서 사용할 수 있으며, 이 경우 더 좋은 가시성을 확보할 수 있다. 따라서 자바, 그중에서도 스프링을 사용하여 마이크로 서비스를 구현하려는 경우에는 바로 이 유레카와 config 서버 두개를 기본 리소스로 확보하여 마이크로 서비스 구조를 확장할 수 있는 방법을 제시한다. 

다음번에는 이렇게 구성된 서비스들 간 API 게이트웨이 및 마이크로 프락시 역할을 하는 넷플릭스의 Zuul 을 스프링 클라우드에서 사용하는 방법에 대해 소개해 보도록 하겠다. 도움이 되시길 바라며. 

출처: http://kerberosj.tistory.com/227 [System Compleat.]