Github Actions를 통해서 꾸준히 지속적인 통합 및 배포를 해왔다. 기술 블로그를 모아 놓고 볼 수 있는 간단한 프로젝트를 이틀 동안 만들면서 무의식 중에 저지른 실수에 대해서 기록하고자 한다.
우선 해당 프로젝트의 지속적인 통합 및 배포의 과정은 아래와 같다.
- IDE에서 프로젝트 코드 작성
- Github Repository Develop 브랜치로 Push
- Github Actions 실행
- JDK 17버전으로 Build
- Docker Hub Login
- 프로젝트 내 DockerFile로 도커 이미지 Build
- Docker Hub로 도커 이미지 Push
- SSH 환경 원격 접속
- EC2 환경의 프로젝트 디렉토리로 이동
- Docker-Compose 빌드 실행
위와 같은 단계를 거치는데, 생긴 문제를 작성해보면 이렇다.
- Spring Injection이 제대로 되지 않았다.
환경 변수를 .env파일로 정의한 다음 @Value를 써서 주입을 받는 코드를 짰는데 어디선가 자꾸 예외가 발생했다. 이 예외는 간헐적으로 발생했는데 이게 포인트다.
첫 번째 에러는 Injection이 제대로 되지 않았다는 예외
두 번째 에러는 Redis Connection이 Refused 됐다는 예외
뭐가 문제였을까? Redis Configuration 볼륨 마운트도 잘했고 포트 설정도 잘 해서 문제가 발생하는 것에 대해 의아했다.
근데 예외를 잘 보면 공통점이 있다. 바로 Application.yml과 관련된 예외라는 것
그리고 내가 했던 행동들에 대해서도 실수가 있었다. 바로 gitignore였는데 Github Repository에 yml파일을 올리지 않기 위해서 gitignore 설정해둔 것을 이제 다시 보니 *.yml로 되어있더라. 그 이후에 작성한 application-prod.yml파일은 미처 생각지도 못하고 계속 Deploy를 수행했던 것이다.
근데 내가 쉽게 인지하지 못 했던 것은 CI/CD가 올바르게 수행되지 않아 로컬에서 실행한 적이 있는데, 이 때는 정말 잘 되길래 Docker의 설정 문제와 같은 것들 때문이라고만 생각을 했었다. 예를 들면, docker-compose.yml의 들여쓰기라던지? 알고 보니 정말 단순한 실수였던 것이다.
결론만 정리하자면, Github Actions에서 Jar를 Build하는 경우 꼭 사용하고자 하는 yml파일을 올려주자. 이것 때문에 정말 애를 먹었다.
누가 알았겠냐,,, Redis Connection Refused가 떠서 Redis 컨테이너나 포트 문제인 줄 알았건만 이게 다 yml이 안 올라가서 생긴 문제였다니^^;;
