[CI/CD] 배포 시 env는 언제 넣어주지?

코인스코프 version 2를 만들면서 CI/CD 작업을 새로 시작했다.

이때, 우리가 새롭게 개선하고자 했던 것은 기존 Github Secrets에 저장했던 보안 정보 값 저장에 관련된 것이었다.

 

🎯 개선이 필요한 상황

우리는 application-secret.yml 파일 전체를 Secrets에 저장해두고, yml 파일이 바뀔 때마다 전체 yml를 Github Secrets에 새로 업데이트 해줘야 했다.

해당 방식은 매번 yml 전체를 오타없이 업데이트 해야하는 일종의 긴장감(?)이 필요했고, 최신 yml의 버전을 맞추고 관리해야하는 측면에서 유지보수가 힘들다고 판단했다.

 

따라서 리뉴얼 버전에서는 환경 변수만 저장하는 env를 이용하기로 했다!

 

JAR : 스프링 부트 애플리케이션을 단순한 하나의 파일로 묶어 쉽게 배포하고 실행할 수 있도록 해주는 표준 포맷

 

[기존] application-secret.yml을 secrets에 저장하는 방식

---

application-secret.yml 전체를 Secrets에 등록하는 방식은 jar 빌드 시점에 해당 yml을 파일에 넣어준다.

 

- name: Build Project with Gradle
  run: |
    echo ${{ secrets.APPLICATION_SECRET }} | base64 --decode > ./src/main/resources/application-secret.yml
    ./gradlew bootJar

 

해당 jar 파일을 그대로 CD(배포) 단계에서 사용하면 된다.

 

하지만 해당 방식은 jar 자체가 하나의 기밀 정보를 담고 있는 파일이 되기 때문에 application-secret.yml 파일 내용이 그대로 노출될 수 있어 보안 측면에서 좋지 않다고 한다.

 

반면, env를 이용하여 보안 정보(토큰값, DB 정보 등)만 Secrets에 저장해 둔 방식을 이용한다면 어떻게 해야 할까?

 

 

[리뉴얼] .env를 secrets에 저장하는 방식

---

1. 빌드 시점

- name: ⚙️ Gradle 프로젝트 빌드 시작
  run: |
    ./gradlew bootJar

 

환경 변수 값 없이 jar을 빌드한다.

 

yml 내부에 환경 변수 값 없이 ${DATABASE_URL} 같은 placeholder만 있는데 이 경우 에러가 나지 않을까?

 

빌드(bootJar) 시에는 환경 변수가 필요하지 않다고 한다.

이미 application.yml 파일 자체가 존재하고, bootJar의 경우 resources 파일을 jar에 묶거나 소스 파일 컴파일, 의존성 패키징의 역할만 진행하지 따로 환경 변수 값을 찾거나 확인하지 않는다.

 

따라서 실제로 환경 변수 값이 없어도 jar 빌드는 오류가 나지 않는다!

 

2. 컨테이너 실행 시점

따라서 우리는 컨테이너 실행 전 Docker Compose가 환경 변수를 주입하도록 했다.

 

cd /home/ec2-user

sudo touch .env
echo "${{ secrets.PROD_ENV }}" | sudo tee .env > /dev/null
sudo chmod 600 .env

sudo docker compose -f docker-compose-${{env.TARGET_UPSTREAM}}.yml --env-file .env up -d

 

GitHub Secrets에 저장된 env 내용을 EC2 내부의 .env 파일로 저장한다(덮어쓴다).

이때, > /dev/null 을 이용하여 로그에 env 내용이 노출되지 않도록 출력 메시지를 숨긴다.

 

매번 action이 돌때마다 env를 새로 갱신해주므로 따로 EC2 내에서 우리가 env를 수정해줄 일은 없다.

 

chmod 600을 통해 다른 사용자가 접근하지 못하도록 하여 민감 정보가 담긴 env 파일을 외부 접근으로부터 보호해주었다.

이후 --env-file .env 명령어를 통해 .env 파일 값을 Compose가 읽고 컨테이너에 환경 변수로 주입해준다.