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

구성 관리

Spring Microservices in Action

Chapter 3

박영준

핵심 내용

  • 서비스 구성과 서비스 코드 분리

  • 스프링 클라우드 컨피그 서버를 구성하는 방법

  • 스프링 부트 마이크로서비스의 통합

  • 중요한 프로퍼티의 암호화

기존의 구성 방식

  • 상수 클래스 파일을 사용해 구성을 한곳으로 모은다.

  • 별도의 프로퍼티 파일을 사용한다. (JSON, XML, YAML..)

문제점

  • 운영 코드와 함께 관리되고 배포 되어야 하는 산출물이 추가되어 복잡해진다.

  • 규모가 작은 서비스에는 적용이 쉽지만 수백개의 인스턴스가 실행되는 클라우드 환경에는 적합하지 않다.

클라우드 환경에서의 구성 방식

  • 배포 되는 실제 코드에서 애플리케이션의 구성을 완벽하게 분리한다.

  • 서버 및 애플리케이션을 빌드하고 배포 환경에 따라 절대 바뀌지 않는 불변 이미지를 빌드한다.

  • 서버를 시작할 때 읽어올 수 있는 중앙 저장소를 이용해 애플리케이션 구성 정보를 주입한다.

구성 (그리고 복잡성) 관리를 위한 4가지 원칙

1. 분리

  • 구성 정보를 서비스 인스턴스와 함께 배포하면 안됨

  • 환경변수나 중앙 저장소에서 읽어와 구성 정보를 전달해야 한다.

2. 추상화

  • REST 기반의 JSON 서비스를 사용해 구성 데이터를 조회해야 한다.

3. 중앙 집중화

  • 애플리케이션의 구성 정보를 가능한 소수 저장소에 집중화 한다.

4. 견고성

  • 고가용성과 다중성을 구현할 수 있어야 한다.

구성 관리 아키텍처

1. 마이크로서비스가 시작될 때 환경별 구성 정보를 읽어온다.

2. 실제 구성 정보는 저장소에 상주한다. 버전관리 되는 파일이나 RDB, KVS 저장소 같은 구현 방식을 선택할 수 있다.

3. 애플리케이션의 배포와 독립적으로 구성 데이터를 관리한다.

4. 구성 관리가 변경되면 이를 사용하는 서비스는 변경 통보를 받고 보유하고 있는 구성 데이터의 사본을 갱신한다.

왜 스프링 클라우드 컨피그 서버인가?

1. 쉽게 설치하고 사용 가능

2. 스프링 부트와 긴밀한 통합

3. 구성 데이터를 저장할 수 있는 여러 백엔드 지원

4. 깃(git)과 직접 통합 가능

스프링 클라우드 컨피그 서버 구축

스프링 클라우드 의존성 추가

<dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Finchley.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
</dependencyManagement>
  • 사용할 스프링 클라우드 컨피그의 상위 BOM
  • 사용할 스프링 클라우드의 모든 라이브러리 버전을 통일할 수 있다.

스프링 클라우드 의존성 추가 2

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-config-server</artifactId>
</dependency>


<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
  • spring-cloud-starter-config : 모든 스프링 클라우드 프로젝트에 사용됨
  • spring-cloud-config-server : 스프링 클라우드 컨피그 서버를 위한 핵심 라이브러리
  • 앞서 BOM에서 전체 버전을 명시했기 때문에 각각의 버전을 명시하지 않아도 된다.
Made with Slides.com