이전 프로젝트에서는 application.yml을 통째로 깃허브 secret에 저장시켜 jar 빌드할 때 사용하게 개발했었다. 이 문제점은 application.yml의 내용을 notion에서 관리중이었는데 변경 이력을 볼 수 없다는 점과 너무 많은 내용이 적혀있어 확인하기 어렵다는 점이었다. 특히 카카오,구글,애플 oauth 관련 시크릿 키들을 넣으면서 yml이 복잡해졌었다.
신규 springboot 프로젝트에서 이전과는 다르게 환경변수를 도입해서 application.yml을 관리하기로 했다.

위 사진처럼 예를 들면 이런식으로 yml이 적히게 된다.
CICD 스크립트 순서를 먼저 작성해보았다.
실행순서
1. 깃허브에 DEFAULT 브랜치에 PUSH가 일어나면 EC2에서 동작 중인 runner가 checkout 결과로 가져온 gradle을 통해 JAR를 빌드한다.
2. 도커 이미지를 빌드해서 ECR 레지스트리 레포에 업로드를 진행한다.
3. 레지스트리에서 이미지를 PULL받아 도커 컴포즈로 컨테이너를 실행시킨다.
고려해야할 점으로 어느 시점에 해당 환경변수들을 주입해야하는지이다. 도커이미지를 생성할때 혹은 ECR 레포지토리에서 이미지를 PULL받아 컨테이너를 실행할 때? 처음시도에선 JAR로 도커 이미지를 빌드할 때 환경변수를 ARG로 지정해주었다.

도커 베이스 이미지에 해당 변수들을 환경변수로 지정하면 이후에 사용할 때에도 환경변수들을 활용할 수 있을 줄 알았다.
그래서 도커컴포즈로 해당 springboot 애플리케이션 이미지를 컨테이너 실행시킬 때 특별히 환경변수를 지정해주지 않았다. 그 결과, 컨테이너가 자꾸 종료되는 문제에 직면했다.

도커 로그를 확인해보았다.

결국엔 jdbc url이 적용되지 않아서 애플리케이션이 기동되지 않았다는 점이 핵심이다.
그러면 두 번째 방안으로 이미지 빌드단계가 아닌 도커 컴포즈 단계에서 환경변수를 뚫어주는것이다. 다만 이렇게 되면 추후 환경변수가 많아지면 옵션 파라미터로는 관리하기가 너무 어려워진다는 단점이 떠올랐다. 아직은 개발 초기단계이고, 개선할 여지가 있다면 변경할 수 있을 거라고 판단했다.
.env 파일을 통해서 컴포즈 단계에서 환경변수들을 주입하는 것으로 방향을 정했다.

추가로 docker-compose.yml에서도 환경변수들을 뚫어주었다.


컨테이너환경에서 jar가 정상동작시킬 수 있었다.
이미지 빌드 단계에서 환경변수를 적용하더라도 jar를 실행시킬 땐 사용이 안된다는 점을 알게 되었다.
한가지 고민거리로는 .env 파일에 환경변수들을 스크립트로 주입하고, compose파일에서도 변수를 작성해주어야하는데, 추후 프로젝트가 고도화된다면 다른 방안을 모색해야할 것 같다. 깃허브 private 레포에서 yml을 통째로 관리하게 하거나, 다른 효율적인 방법을 찾아보려고 한다.
'Backend' 카테고리의 다른 글
| DDD 레이어드 아키텍처에 대한 고민 (0) | 2024.12.31 |
|---|---|
| Logback Rolling file appender 적용 (Docker volume mapping, Springboot ) (0) | 2024.12.30 |
| EC2 불필요한 버퍼/캐시 용량 줄이기 (0) | 2024.12.28 |
| [CI/CD] github self-hosted runner로 ec2 배포하기 (2) | 2024.12.26 |
| Sentry Slack 연동 ( 에러 메세지 모니터링 통합 ) (1) | 2024.09.22 |