지속적 통합, 지속적 배포 ‐ (1) 필요성, 기술 선택, 설계 - ttasjwi/board-system GitHub Wiki

기존 방식의 문제점

  • 코드를 변경(추가, 수정, 삭제)했을 때 기존 코드와 통합하여 잘 동작하는지 확인하기 힘들다.
    • 아예 컴파일 오류가 발생하여 실행되지 않는 코드가 프로덕션 환경에 배포되는 것은 위험하다.
    • 테스트를 통과하지 못 하는, 오류 투성이의 코드가 실제 배포되는 것 역시 위험하다.
  • 애플리케이션 배포가 불편하다.
    • 매번 jar 파일을 구성하고 프로덕션 환경에서 새로 실행해주고, 웹 요청이 새로운 실행환경으로 포워딩될 수 있도록 설정해야한다.

지속적 통합, 지속적 배포의 필요성

  • PR 을 위한 브랜치에 커밋을 올릴 때마다, 자동으로 빌드테스트가 동작하게 한다.
    • 매번 빌드테스트를 진행하고, 가장 최근의 커밋이 빌드 실패할 경우 그 PR은 merge 될 수 없다.
  • 최종적 Push 될 때, 자동으로 인프라 환경에 서비스가 배포되게 한다.
  • 이 모든 과정을 자동화하여, 배포를 매 순간마다 고민하지 않고 애플리케이션 개발에 집중하도록 한다.

여러가지 선택지

  • Jenkins
    • 매우 풍부한 확장플러그인, 유저풀
    • 별도의 서버에 설치하여 구성할 수 있고 여러 서버로 수평적 확장 가능
    • 다만 서버를 구성해야하므로 서버 유지 비용이 소모됨
    • 별도의 서버를 구성해서 사용할 수 있다는 점에서 빌드 결과물 캐싱 가능
  • GitHub Actions
    • GitHub 과 통합 가능
    • 다양한 플러그인
    • 일정 한도까지 무료 (GitHub Actions 서버에서 CI/CD 작업)

기술 선택

  • 우리 서비스에서는 GitHub Actions 를 사용하기로 한다.
  • Jenkins 를 사용하는 것은 성능상 이점이 있지만, Jenkins 서버를 별도로 운영할 비용이 부족하다.

GitHub Actions 프로세스

image

  • PR 브랜치 커밋 추가 -> 빌드테스트
  • PR 브랜치 -> master 브랜치 병합시 자동 배포
    • 빌드된 jar 파일을 기반으로 Docker 이미지 구성
    • DockerHub에 Push
    • EC2 측에서 이미지 풀링
    • 컨테이너 실행 및 헬스체크
    • Nginx 리버스 프록시 서버에서 가리키는 포워딩 방향 변경
    • 기존 컨테이너 중지
    • 불필요한 이미지 일괄 제거