[Infra/#11] 무중단 배포 자동화 환경 구축 (Docker)

[yummygyudon]

Related Issue 🚀

• closed [INFRA] Docker 기반 자동 배포 환경 구축 #11

Work Description ✏️

• PR 시, 빌드 통관 여부 확인 자동화 환경을 구축했습니다.
• 배포 자동화 환경을 구축했습니다.
• 무중단 배포 환경을 구축했습니다. (노션 팀워크스페이스를 통해 원리와 흐름을 참고해주세요!)

🚨 (주의) Operation 프로젝트까지 반영한 후, 진행해야 합니다. - (완료 ✅)
🚨 (주의) �클라이언트와 논의하여 기존 방식으로 구동 중인 어플리케이션들을 종료하고 진행하기 때문에 잠깐의 셧다운이 필요합니다. - (완료 ✅)

PR Point 📸

to-do

• Github Secrets 반영 필요
• Spring Actuator - 모니터링 서버 스펙 반영 필요

※ 환경 변수 주입 방식

.env 주입

기존 각 profile 별 application-{profile}.yml 선언 및 import 하는 파일들마다 profile에 맞춰 주입되는 환경변수들을 단일 .properties 파일에 선언해야 하는 구조였습니다.

< as-is >

• profile 별 환경 변수 정의 (ex. PROD_A_VALUE & DEV_A_VALUE 중복 선언)
• Docker Build & Run 시, profile 동적 주입의 어려움
• 특정 profile 마다 필요하지 않은 타 Profile에서의 환경변수까지 포함되어 실행됨

< to-be >

• Docker 실행 환경에서 간편하게 다수의 환경변수 일괄 적용 가능
• Docker 실행 환경에서 간편하게 실행 profile 지정 가능 (.env 파일 내부에 SPRING_PROFILES_ACTIVE 선언을 통해 적용)
• 중복되는 profile 별 환경변수를 정의하는 구조 개선
• 각 profile에 맞춰 필요한 환경변수 값들로만 구성된 .env 파일들로 분리 가능

(여러분들이 개발하면서 직접 프로젝트 폴더 내에 자유롭게 생성하고 활용할 수 있도록 .gitignore에 **/src/main/resources/**/*.env를 추가했습니다. 패키지 만드셔서 env 파일 생성하시구 실행 Configuration에서 env 주입하시는 방식으로 실행시키시면 됩니다!)

※ Build 방식

build profile parameter(-Pprofile) 주입 방식 도입 & CI 시, Docker 환경에서의 Build 방식 변경

< as-is >

• ci 전용 properties를 따로 Github Secrets에 정의해놓아야 함
  • 실질적인 값이 필요한 것이 아닌 "Build 성공 여부"만 확인하는 과정이기 때문에 해당 값들은 불필요합니다.
• 특정 profile 마다 필요하지 않은 타 Profile에서의 환경변수까지 포함되어 실행됨

< to-be >

• 별도 파라미터 전달이 없을 경우, 기본값으로 "test"로 돌아가도록 구축 (참고 : build.gradle.kts)
  • 기본적으로 application-test.yml 및 각 import yml 내 test profile 시 사용될 임시 값은 static 하게 정의되어 있어 CI 과정에서 별도 .env / .properties 파일 주입이 불필요하게 됩니다.
  • dev와 prod 각 환경에서 명시적인 build 환경 주입을 통해 휴먼에러를 방지할 수 있습니다.
• 빌드에 사용되는 Dockerfile 내 ARG 활용
  • 별도 --build-arg 명령이 없을 경우, 기본값으로 "test"로 돌아가도록 구축했습니다. (참고 : Dockerfile)

※ Run 방식

위 내용들을 반영하여 환경 별 동적 profile 적용

# Example
sudo docker run --name ${Container Name} \
  --env-file application.env \ # profile 환경 변수 포함
  -d -p 8080:8080 \
  -t ${Image Name}:${Tag} # profile 적용 Build Image

※ Deploy 방식

• CD Script : Copy Resources from S3
• CodeDeploy : S3 Resource(.pem, .p8, .env, scripts) -> EC2 배포 / EC2 내에서 Docker Pull & Run

CodeDeploy에서 실행하는 배포 단계는 아래와 같습니다. ("무중단 배포 :: Blue-Green")

1. Resource Files(S3 Zip) =(Copy)=> EC2
2. deploy script
   1. 기존 구동 컨테이너 확인
   2. 새로운 이미지 Pull & Run
   3. 새로운 구동 컨테이너 정상 작동 여부 확인(Health Check)
   4. 기존 구동 컨테이너 종료 및 삭제
3. switch script
   1. 새로운 구동 컨테이너 확인
   2. 기존 Nginx 컨테이너 종료 및 삭제
   3. 새로운 구동 컨테이너 전용 Nginx Config 파일로 Volume Mount 경로 변경
   4. 새로운 Nginx 컨테이너 실행
4. logging script
   1. 1번 & 2번 완료 시 실행
   2. 배포 일시 로깅

※ 파일 관리 방식

• Nginx 관련 파일 관리
  단일 서버 내에서 2개의 어플리케이션을 운영하기 때문에 특정 레포지토리에서 관리하는 구조를 피했습니다.
  번거로울순 있지만 "변경이 빈번하지 않다는 점" & "공통 관심사라는 점"을 근거로 해당 관련 파일들(*.conf)들은 EC2 내부에서 직접 관리할 수 있도록 했습니다.
  (이에 대한 내용들은 노션을 통해 공유할 수 있도록 합니다)

• 실 리소스 파일 관리
  Github Secrets 으로만 관리할 경우, 적용된 값이 올바른 값인지 확인하기 어렵다는 단점이 있습니다.
  이에 확인이 필요하거나 직접 관리가 필요한 파일들에 대해서 S3에 저장하여 CD 과정에서 Copy하여 사용될 수 있도록 했습니다.
  (리소스 파일의 변경이 필요하거나 파일 내용 확인이 필요할 때, S3에서 확인 및 교체가 가능합니다.)

🚨 단, s3에서 관리하는 만큼 Bucket 이름 & Key (경로 및 파일 명)가 노출되지 않도록 해당 값들에 대해서는 Github Secrets에서 관리할 수 있도록 합니다.

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[hyunw9]

이 파일은 무엇을 위한 파일인가요..?

[yummygyudon]

Code Deploy를 사용하려면 작성해주어야 하는 파일입니다!
자세한 내용은 공식문서를!

[sung-silver]

어렵고 힘들었던 배포네요 수고 정말 많으셨습니다!