[Spring Cloud] Actuator를 이용한 Config Server 기동

0. Spring Cloud Config Server

MSA와 같은 분산 시스템에서 각 서버들의 구성에 필요한 설정들을 외부 시스템에서 한번에 관리할 수 있다.

 

Spring Boot 같은 경우는, 설정 파일인 application.yml 또는 properties파일이 그 대상이 되겠다.

 

Spring Cloud의 Config Server를 기동하여 설정 파일들을 한꺼번에 묶어 사용한다면, 한 저장소에서 관리할 수 있고, 

설정 정보를 바꾸더라도 다른 서비스들을 다시 빌드하지 않아도 된다.

 

서비스를 개발하는 경우, DEV서버와 PROD 서버를 분리해서 개발하기도 하는데,

각 서버들 마다 사용하는 설정 정보가 다르기 때문에 서버에 맞춰서 기동할 수 있겠다.

 

1.  Actuator

앞에서 Config Server를 이용하면 설정 정보들이 변경되어도 서버를 다시 빌드하지 않아도 된다는 장점이 있다고 했다.

 

보통은 Spring Boot의 상태를 모니터링 할 수 있는 툴인 Actuator를 Refresh함으로써 정보를 가져올 수 있다.

 

아래 공식 문서에서 여러 앤드포인트들을 확인할 수 있다.

https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html

 

Actuator를 사용하기 위해, client 서버에 dependency를 추가하자.

implementation 'org.springframework.boot:spring-boot-starter-actuator'

 

이제 client 서버의 application.yml에 다음을 추가한다.

 

- application.ym

management:
  endpoints:
    web:
      exposure:
        include: refresh

 

actuator에서 열어둘 앤드포인트를 설정해줄 수 있다. 일단은 refresh만 설정해두고, 나중에 필요할 때 추가하면 되겠다.

 

마이크로 서비스에서 이러한 Actuator를 사용하려면 gradle에 다음과 같이 의존성을 주입하면 된다.

dependencies {

   //Spring Boot Actuator
   implementation 'org.springframework.boot:spring-boot-starter-actuator'

}

 

프로젝트에 Actuator를 추가했다면, 프로젝트에서 Security 정책을 가지고 있다면

actuator와 관련된 uri들은 모두 permitAll 해주어야 한다.

 

- SecurityConfig.java의 일부

//...

http
   .authorizeHttpRequests(auth -> auth
      .requestMatchers("/actuator/**").permitAll()
      .anyRequest().authenticated()
   );
   
//...

 

이로써 actuator에 대한 요청은 모두 로그인을 거치지 않아도 될 수 있도록 허용했다.

 

해당 refresh 기능을 이용하려면 "IP주소/actuator/refresh"로 POST요청을 보내면 된다.

 

 

 

2. profile을 이용한 설정 파일 이름

 

여러 설정 파일들을 사용할 수 있는 장점 중 하나는, 앞에서 언급했던 dev서버와 prod서버를 분리해서 개발할 때, 각 설정 정보들을 여러 파일로 나누기도 한다.

보통은 dev, local, prod, test를 많이 사용한다.

이렇게 나누어진 설정 파일들은 default 설정에서 설정한 profile에 의해서 각 다른 설정 정보들이 들어가게 된다.

 

그렇다면 Spring Cloud Config Server를 사용할 때, 어떤 식으로 네이밍을 하면 좋을까?

 

만약 서비스들 중 user-service를 기동한다고 하면, 아래와 같이 네이밍을 지으면 되겠다.

- user-service-prod.yml

- user-service-dev.yml

- user-service-local.yml

 

이런 설정 파일들의 네이밍들을 적절하게 이용하여 파일들을 쉽게 관리하고 적용시키면 되겠다!

 

3. Config Server

 

새로운 Config Server 역할을 해줄 프로젝트를 생성하고, gradle에 다음 의존성을 추가해준다.

 

- build.gradle

ext {
	set('springCloudVersion', "2023.0.0")
}

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-config-server'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

 

해당 서버는 Config Server로 동작될 수 있게 @EnableConfigServer를 활성화 시켜준다.

 

- ConfigServiceApplication.java

@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {

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

}

 

이제 설정 파일들을 서버에 등록해 보겠다.

server:
  port: 8888

spring:
  profiles:
    active: prod
  application:
    name: config-service
  cloud:
    config:
      server:
        git:
          uri: https://github.com/DDonghyeo/spring-msa-yml

보통은 깃허브에 private repository를 만들어서 사용한다.

 

private repository 정보를 가져오려면 보통 비밀키를 사용해서 ssh로 가져온다.

해당 내용은 다음에 다루기로 하고, 지금은 public repository로 사용하겠다.

 

- uri : 깃허브 링크

- search-paths : 파일 경로

- default-label : 브랜치명

 

기동 중인 Config Server에서 설정 파일이 적용된 파일을 보려면 아래와 같이 접속하면 된다.

http://localhost:8888/{파일 이름}/{profile}

특별한 profile이 없다면 default로 접속하면 되겠다.

 

나는 토큰을 사용하기 위한 설정 정보 파일을 서버에 등록했다.

 

4. Client Server

Config Server 설정을 모두 완료했다면, Client Server 설정을 알아보겠다.

 

먼저 gradle에 다음 의존성들을 추가해준다.

 

- build.gradle

dependencies {

   //...

   implementation 'org.springframework.cloud:spring-cloud-config-client:4.0.3'
   implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap:4.0.3'

}

 

이제 이 client server에 bootstrap.yml 파일을 만드는데,

이 bootstrap.yml은 application.yml 파일보다 더 높은 우선순위를 가져 먼저 적용된다.

앱에서 가장 먼저 설정되는 정보라고 생각하면 되겠다.

 

-bootstrap.yml

server:
  port: 9000

spring:
  cloud:
    config:
      uri: http://localhost:8888
      name: token

  application:
    name: user-service  # micro service unique ID

eureka:
  instance:
    instance-id: ${spring.application.name}:${spring.application.instance_id:${random.value}}
  client:
    register-with-eureka: true # register to eureka server
    fetch-registry: true # Getting instances' information from eureka server
    service-url:
      defaultZone : http://127.0.0.1:8761/eureka #Eureka Server's address

management:
  endpoints:
    web:
      exposure:
        include: refresh

 

User service의 actuator 앤드포인트 refresh를 열어두고, config server로부터 name이 token인 정보를 가져온다.

 

 

서버 로그를 살펴보면, config server로부터 설정 정보를 잘 가져오는 것을 확인할 수 있다.

 

해당 설정에 대한 자세한 내용은 공식 문서를 살펴보면 좋을 것 같다.

https://docs.spring.io/spring-cloud-config/docs/current/reference/html/

Spring Cloud Config

 

나는 이를 확인해보기 위해 다음 컨트롤러를 만들었다.

@RestController
@RequestMapping("/user")
public class UserController {

    @Value("${jwt.secret}")
    private String secret;

    @GetMapping("/test")

    public String test() {

        return "token secret : " + secret ;
    }

}

테스트 결과, 설정 정보를 잘 가져오는 것을 확인할 수 있다.

 

4. Actuator Refresh 테스트

이젠 서버를 기동 중에도 설정 정보들이 잘 반영 되는지 확인해보려고 한다.

 

깃허브에 있는 내용을 바꿔주었다.

 

아직은 서버에 반영되지 않았다.

 

config server에서는 정상적으로 가져온다.

 

POST요청을 보내야하기 때문에, postman을 사용했다.

서버IP/actuator/refresh로 POST요청을 보내면 된다.

 

 

서버 로그에서 config server로부터 설정 정보를 다시 가져오는 것을 볼 수 있고,

바뀐 결과 또한 확인할 수 있다.

 

이런 과정을 자동화 하고 싶다면,

Github Action을 통해서 yml이 모여있는 레포지토리에 push를 감지하면 /actuator/refresh에 POST요청을 보내는 과정을 추가하면 될 것 같다. 🤔