TIL - 20251130

1130 Spring Boot 배포 전략: JAR, Docker, CI/CD

---

✅ 1. 전통적인 배포 방식: JAR 파일 직접 배포

• Spring Boot의 "독립 실행 가능성(Standalone)" 특징을 활용하는 가장 간단하고 기본적인 배포 방식입니다.

➕ 배포 절차

1. 빌드: 로컬 개발 환경이나 빌드 서버에서 ./gradlew build 명령어를 실행하여, 모든 의존성이 포함된 실행 가능한 JAR 파일(Fat JAR)을 생성합니다.
2. 전송: 생성된 JAR 파일을 scp나 FileZilla와 같은 도구를 사용하여, 배포할 서버(e.g., AWS EC2)로 전송합니다.
3. 실행: 서버에 접속하여 java -jar 명령어로 애플리케이션을 실행합니다.
   • 환경 변수 주입: -Dspring.profiles.active=prod와 같은 옵션을 사용하여 운영 환경 프로파일을 활성화하고, 데이터베이스 비밀번호 등 민감한 정보는 서버의 환경 변수를 통해 주입합니다.
   • 백그라운드 실행: nohup 명령어와 &를 사용하여, SSH 세션이 종료되어도 애플리케이션이 계속 백그라운드에서 동작하도록 합니다.

     nohup java -jar -Dspring.profiles.active=prod my-app.jar > app.log 2>&1 &

• 장점: 절차가 간단하고 직관적입니다.
• 단점:
  • 배포 서버에 Java(JDK/JRE)가 반드시 설치되어 있어야 합니다.
  • 배포 과정(파일 전송, 기존 프로세스 종료, 새 프로세스 실행)을 수동으로 관리해야 하므로 실수가 발생하기 쉽고 번거롭습니다.
  • 여러 애플리케이션을 한 서버에 배포할 경우, 포트 충돌이나 라이브러리 버전 충돌 문제가 발생할 수 있습니다.

---

✅ 2. 현대적인 배포 방식: Docker를 이용한 컨테이너 배포

• 애플리케이션과 그 실행 환경을 Docker 컨테이너라는 표준화된 단위로 패키징하여 배포하는 방식입니다. 현대적인 클라우드 환경의 표준으로 자리 잡고 있습니다.

➕ 배포 절차

1. Dockerfile 작성: 애플리케이션을 Docker 이미지로 만들기 위한 설계도를 작성합니다. 멀티 스테이지 빌드를 사용하여 최종 이미지의 크기를 최적화하는 것이 좋습니다.
2. 이미지 빌드: docker build 명령어로 Docker 이미지를 생성합니다.
3. 이미지 레지스트리 푸시: 생성된 이미지를 Docker Hub나 AWS ECR과 같은 중앙 이미지 레지스트리에 업로드(docker push)합니다.
4. 서버에서 컨테이너 실행: 배포 서버에 접속하여, 이미지 레지스트리에서 최신 이미지를 내려받고(docker pull), docker run 명령어로 컨테이너를 실행합니다.
   • 환경 변수 주입: -e 또는 --env-file 옵션을 사용하여 컨테이너에 환경 변수를 주입합니다.
   • 포트 매핑: -p 옵션으로 호스트 서버의 포트와 컨테이너의 포트를 연결합니다.

• 장점:
  • 환경 격리: 배포 서버에 Java를 설치할 필요가 없습니다. 오직 Docker만 설치되어 있으면 됩니다.
  • 일관성: 개발, 테스트, 운영 환경 모두 동일한 이미지를 사용하므로 "내 컴퓨터에선 됐는데..." 문제가 사라집니다.
  • 쉬운 확장 및 관리: Docker Compose나 Kubernetes와 같은 오케스트레이션 도구를 통해 여러 컨테이너를 쉽게 관리하고 확장할 수 있습니다.

---

✅ 3. 배포 자동화: CI/CD 파이프라인

• CI/CD (지속적 통합/배포)는 위에서 설명한 배포 과정을 자동화하여, 개발자가 Git에 코드를 푸시하는 것만으로 빌드부터 배포까지의 모든 단계가 자동으로 실행되도록 만드는 것입니다.

➕ GitHub Actions를 이용한 Docker 기반 CI/CD 파이프라인

• CI (Continuous Integration) 단계 - GitHub Actions 서버에서 실행:

  1. 코드 체크아웃: Git 리포지토리의 최신 코드를 가져옵니다.
  2. 빌드: ./gradlew build로 JAR 파일을 생성합니다.
  3. Docker 이미지 빌드: Dockerfile을 사용하여 Docker 이미지를 빌드합니다.
  4. 이미지 푸시: 빌드된 이미지를 Docker Hub나 AWS ECR에 푸시합니다.

• CD (Continuous Deployment) 단계 - 배포 서버(EC2)에서 실행:

  1. 서버 접속: GitHub Actions가 SSH를 통해 배포 서버(EC2)에 원격으로 접속합니다.
  2. 배포 스크립트 실행: EC2 서버에서 미리 작성된 셸 스크립트를 실행합니다. 이 스크립트는 일반적으로 다음 작업을 수행합니다.
     a. 최신 이미지 풀(Pull): 이미지 레지스트리에서 방금 푸시된 최신 이미지를 내려받습니다.
     b. 기존 컨테이너 중지/제거: 실행 중이던 구버전 컨테이너를 중지하고 제거합니다.
     c. 새 컨테이너 실행: 최신 이미지를 기반으로, 운영 환경에 맞는 환경 변수와 포트 매핑 옵션을 적용하여 새로운 컨테이너를 실행합니다.

• 장점:

  • 신속성: 코드 변경 사항을 몇 분 안에 운영 환경에 반영할 수 있습니다.
  • 안정성: 모든 배포 과정이 자동화된 스크립트를 통해 일관되게 실행되므로, 수동 배포 시 발생할 수 있는 사람의 실수를 원천적으로 차단합니다.
  • 개발 생산성 향상: 개발자는 배포의 복잡성에서 벗어나, 오직 코드 개발에만 집중할 수 있습니다.

---

📌 요약

배포 방식	장점	단점	핵심 도구
JAR 직접 배포	• 간단하고 직관적	• 수동 관리, 환경 의존성 높음	java -jar, nohup
Docker 컨테이너 배포	• 환경 격리, 일관성 보장 • 쉬운 확장	• Docker 학습 곡선 • 이미지 관리 필요	Dockerfile, docker run
CI/CD 자동 배포	• 신속성, 안정성 • 개발 생산성 극대화	• 초기 파이프라인 구축 비용	GitHub Actions, Jenkins

• 현대적인 클라우드 네이티브 애플리케이션 개발에서는, Docker를 사용하여 애플리케이션을 컨테이너화하고, CI/CD 파이프라인을 통해 배포를 완전히 자동화하는 것이 표준적인 모범 사례입니다.