[infra] #13 Docker CI/CD

[yeeun0702]

📚 작업 개요

closes #13

main 브랜치 푸시 시 Docker 이미지 빌드 → DockerHub 푸시 → EC2 서버 배포까지 자동화했습니다.

---

🛠️ 작업 내용 요약

1. GitHub Actions 워크플로우 구성

• 소스코드 체크아웃 → Docker 이미지 빌드 및 푸시 → EC2에 docker-compose.yml 복사 → 원격 배포 자동 실행

GitHub Actions에서 EC2 및 DockerHub 접근을 위해 필요한 환경 변수들을 GitHub Secrets에 등록해두었습니다.

2. Dockerfile 작성

• Gradle로 빌드 (테스트 제외) → JAR 파일만 경량화된 OpenJDK 이미지에 복사

3. docker-compose.yml 구성

• EC2에서 spring-plus:latest 이미지로 컨테이너 실행
• 내부 포트 8080 → 외부 80 연결
• application-prod.yml은 EC2에서 직접 마운트

---

🧐 질문 사항

1. 환경 설정 파일은 어떻게 관리하는 게 좋을까요?
   지금은 application-prod.yml을 EC2에 직접 두고 있는데(수동으로 접속해서 설정했습니다), CI/CD 과정에 포함하는 게 좋을까요?

2. 현재는 spring.profiles.active=prod만 사용해서 운영 설정을 분리하고 있는데, 인프라 환경이 달라지면 cloudType 같은 사용자 정의 환경 변수를 추가로 사용하는 게 좋은지 궁금합니다. (강의에서는 cloudType을 사용하는 방식으로 나와 있어서, 필수인지 혼동이 오기도 합니다 ㅎㅎ) 현업에서도 이런 식으로 cloudType 같은 변수를 분기해서 관리하는 경우가 많은가요?

[yeeun0702]

• 환경설정파일에서 민감한 정보를 AWS KMS 나 Vault 를 통해 외부 암호화 저장소에 두고, 스프링 어플리케이션을 실행할 때 import 해서 사용하는게 현업에서 가장 일반적인 방식일 것 같습니다. 작성해주신 부분을 보니 Github Secrets 를 활용해 민감한 정보만 환경변수로 주입해줄 수 있도록 github action 을 만듦으로써 직접 서버에 들어가서 세팅해주는 번거로움을 줄일 수 있을것처럼 보입니다.

• 인프라 환경이 달라지는일이 크지않고, 일반적으로 Docket Image & Container 를 사용하기 때문에 인프라가 크게 중요하지는 않을 것 같습니다! 어떤 환경에서든 동일하게 실행할 수 있는게 Container 기술의 가장 큰 장점이니까요.