🌋 CI/CD pipeline 배포 실패 – env variable 설정으로 해결하기

이 글은 저의 무지함으로 인해 발생한 문제를 해결하는 과정에 대해 다루지만, github actions workflow에서의 env variable 설정 및 적용에 대한 내용을 주로 다룹니다.

문제가 생겼다

분명히 처음 CI/CD pipeline을 Github actions로 구축한 후 제대로 동작하는 것을 확인했다. 그런데 언젠가부터 dev branch에 merge할 때 간헐적으로 failure 메세지가 뜨는 것을 보았다. 모종의 이유로 프론트 개발이 이루어지고 있지 않은 상황이었기 때문에 당장 필요하지 않다고 판단해 방치했는데, 3번에 1번은 뜨던 success 메세지마저 사라져 해결해야겠다는 생각이 들었다. 뭔가 설정하는 과정에서 잘못된 것 같다.

참고로 이전에 뜨던 failure는 다른 백엔드 개발자와 협업하면서 발생한 build 문제였기 때문에 설마 CI/CD 파이프라인이 잘못되어있을 거라는 생각을 못했다.

문제 발생 원인을 파악하자

어디서부터 잘못된 건지를 알기 위해 Github actions workflow를 따라가며 에러 메세지를 읽었다. 내가 파악한 원인은 다음의 2가지였다.

1. RDS datasource connection url이 설정되지 않은 것
2. Github secret variable 값이 제대로 적용되지 않은 것

첫 번째 문제는 내 실수로 인해 발생한 것이라 쉽게 해결할 수 있었으나, 두 번째 문제는 왜 적용되지 않은 것인지 몰랐기에 쉽게 해결할 수 없었다. 여러 방법을 시도해보고 나의 멍청함을 깨달았는데 같은 실수를 하지 않기를 바라며 해결 과정을 기록해둔다. 사실 같은 실수는 다시 안할 것 같다 이번에 너무 삽질을 해서

문제를 해결해보자

RDS datasource url 설정

앞서 말했듯 이 문제는 RDS datasource를 배포용 application.yml에 설정해두지 않은 것이 원인이었기 때문에 이를 추가해 쉽게 해결할 수 있었다.

...
spring:
  config:
    activate:
      on-profile: dev
  datasource:
    url: jdbc:mysql://{RDS datasource url}:3306/{schema}?useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=Asia/Seoul
    username: admin
    password: {password}
    driver-class-name: com.mysql.cj.jdbc.Driver
...

datasource를 설정하는 부분 외에는 생략했다. application.yml 수정 후 local 환경에서 dev profile 적용 후 정상적으로 RDS에 연결되는 것을 확인했다.

Github secret variable을 build workflow에 적용

사실 이건 비밀인데...

개발자라면 누구나 알겠지만, AWS IAM 사용자의 access key와 secret key는 외부에 노출하면 안된다. 그런데 어라? 이걸 레포지토리에 올려버린 사람이 있네? 그게 나다.
로컬 테스트 용도로 사용하던 환경 파일(application.yml)을 실수로 커밋해버렸다. 아무 생각 없이 커밋을 하는데, 갑자기 커밋이 안된다고 막길래 기분이 안 좋았는지 "누가 내 커밋을 막아!" 하면서 경고 메세지를 끄고 그냥 커밋해버렸다.. 물론 이러면 절대 안된다
별 생각 없었는데 갑자기 AWS에서 메일이 오고, 뭔가 잘못되었다는 것을 인지해 이를 secret 환경 변수로 설정해 해결했었다. 그 과정은 🛠️ CI/CD pipeline 구축, 근데 secret 환경 변수를 곁들인..에서 확인할 수 있다. 물론 저 글은 이 문제를 해결한 버전으로 업데이트 되어있다.

Error message

secrete variable을 분명 환경 변수로 설정해줬는데, 에러 메세지로 미루어 보아 제대로 적용되지 않은 것 같다.

  ...
  Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'AWS_ACCESS_KEY_ID' in value "${AWS_ACCESS_KEY_ID}"
          at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:180) ~[spring-core-6.1.5.jar!/:6.1.5]
          at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126) ~[spring-core-6.1.5.jar!/:6.1.5]
  ...

failure🤔 : EC2에서 환경 변수를 설정해보자

환경 변수가 제대로 설정되지 않은 것 같아 EC2 서버에서 환경 변수를 별도로 설정했고, 테스트했으나 실패했다. EC2 내부에서는 환경 변수가 잘 설정된 것을 확인할 수 있었기에 EC2의 문제가 아니라는 것을 알 수 있었다. local에서 docker image를 받아 실행시켰으나 같은 에러 메세지가 떠서 여전히 env variable이 제대로 적용되어 있지 않다는 것을 확인했다.

solution : secret varable을 build workflow에 직접 적용하자

결론적으로 env variable은 build 과정에서 이미 설정되어 있어야 하고, 이를 포함해 build가 이루어져야 한다. 솔직히 너무 당연한 말이라서 어이가 없을 수도 있지만, 그 당연한 걸 잊고 있었다.
Github actions workflow에서 사용하는 빌드 환경은 할당 받은 vm이었기 때문에 환경 변수가 자동으로 설정되지 못했다. 따라서 secret.{env variable}을 직접 application.yml에 적용하는 과정을 거쳐야 했다.
아래 코드를 Gradle build 과정 전에 넣어 직접 yml 파일에 있는 변수를 secret으로부터 가져와 적용해줬다.

# yml 파일에 있는 변수들을 secrets로부터 가져와서 yml 파일에 적용
  - name: Set yml file
    uses: microsoft/variable-substitution@v1
    with:
    	files: 'src/main/resources/application.yml'
    env:
    	cloud.aws.credentials.access-key: ${{ secrets.AWS_ACCESS_KEY }}
    	cloud.aws.credentials.secret-key: ${{ secrets.AWS_SECRET_KEY }}

해당 코드를 적용해 다시 빌드하니 정상적으로 동작하는 것을 확인했다. 해결하고나니 놀랍도록 허무한데 내 멍청함이 어디까지 갈 수 있는 지 나도 좀 기대가 될 정도였다.

local 환경에서 테스트하기 위해서는 intellij에서 환경 변수를 설정하고 적용하는 방법을 사용했다. 자세한 방법은 여기를 참고하면 된다.

그래서 뭘 느꼈는데

처음 CI/CD 파이프라인을 구축할 때에는 그렇게 많은 자료를 찾아보지 않아도 쉽게 구축할 수 있었다. 사실 Github actions를 써보는게 처음이지, 이전에 다른 툴을 활용해서 CI/CD 파이프라인을 구축해본 경험이 있었기 때문이다. 그래서 아무 생각 없이 코드만 짰는데, 이게 문제가 되었다. 다른 사람의 코드를 참고해 구현할 때는 이해를 하고 가져와 사용하는 습관을 들이자👻 무작정 가져와 쓰면 넌 GPT와 다를 바가 없다. 사실 그보다 못할 가능성이 높다. 그래도 이 과정을 통해서 CI/CD 파이프라인과 환경 변수, 빌드 과정에 대해 더 잘 이해하고 코드를 짤 수 있게 되어 좋았다. 앞으로는 같은 실수 반복하지 말자.