저희 Glue 서비스에서는 application.yml과 같은 설정 파일은 Spring Cloud Config로부터 전달받아 각 마이크로 서비스에 적용하는 방식으로 구현하였습니다.
Spring Cloud Config는 연결된 Github의 Private Repository에서 application.yml을 조회하고 name과 profile을 기준으로 각 spring cloud server에게 전달해줍니다.
저희 팀에서는 MSA 환경에서 application.yml을 Spring Cloud Config 서버를 통해 관리하도록 하였습니다.
이슈
👉 Spring Cloud 프로젝트를 Github Actions로 CI/CD를 구축하는데 @Value 값이 초기화되지 않는 오류를 만났습니다.
@Value로 설정된 부분을 application.yml 파일에 지정한 경로에서 값을 조회한다는 내용과 함께 build가 된다고 생각하였습니다.
하지만 실제로 @Value로 지정한 경로에 값이 없으면, 값을 찾을 수 없다는 에러가 발생하여 build를 할 수 없었습니다.
문제
👉 Spring Boot 프로젝트를 build하기 위해서는 build.gradle에서 설정한 의존성에서 요구하는 설정 값이나, @Value로 조회하는 값은 application.yml에 작성되어 있어야 정상적으로 build가 가능하다는 것을 배웠습니다.
처음에 로컬에서 실행했던 것처럼 각 마이크로 서비스의 yml파일에
spring:
application:
name: blog
profiles:
active: dev
config:
import: optional:configserver:<http://localhost:8888>
이렇게 spring cloud config server의 위치만 지정해주면 된다고 생각하였습니다.
하지만, 오류를 분석하고 다시 생각해보니 프로젝트를 빌드할 때 기본적으로 요구되는 값이 설정되지 않으면 실행되었을 때 오류가 발생하여 실행되지 않겠다고 생각이 들었습니다.
해결
👉 @Value로 값을 불러오는 값이나 데이터베이스 연결 정보와 같이 기본적으로 설정해줘야 하는 부분은 Github Actions로 build 하기 전에 해당 값들을 설정한 application.yml 주입하여 CI/CD를 구축하였습니다.
spring:
application:
name: blog
profiles:
active: prod
config:
import: optional:configserver:<http://glue-config.glue-service.svc.cluster.local:8888>
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: ****
username: root
password: ****
cloud:
aws:
s3:
bucket: ****
credentials:
access-key: ****
secret-key: ****
region:
static: ap-northeast-2
auto: false
stack:
auto: false
application:
config:
auths-url: <http://glue-auth.glue-service.svc.cluster.local:8080/auths>
posts-url: <http://glue-post.glue-service.svc.cluster.local:8082/posts>
jwt:
secret: ****
위 yml은 빌드할 때 필요한 blog-server의 yml 파일입니다. 필수적으로 설정해줘야 하는 값만 넣어주고, 변경이 되는 값들은 Private Repository에 작성하여 Spring Cloud Config를 통해 전달받아 설정하도록 하였습니다.
쿠버네티스와 MSA 환경에 대해 더 알게 되면서, Spring Cloud Config를 사용하는 것보다 더 편리한 방법이 있는 것을 알게 되었다.
1. Kubernetes에 configmap으로 처리하기
2. Github을 private으로 관리하는 경우 application.yaml도 같이 올리기
2번 방법 같은 경우, 실무에서는 private repository로 관리하니까 가장 좋은 방법이라 생각이 들었습니다. 하지만, 해당 프로젝트 같은 경우 추후 public으로 옮길 수도 있어 spring cloud config 서버를 구축하여 처리했습니다.
해당 글을 작성하면서 느낀 점으로, 아는 것이 많아야 가장 효율적인 방법으로 처리할 수 있겠다 생각이 들었습니다.