엘라스틱빈톡 & DB & CI/CD 배포하기 1 (CI/CD, Webhock - GitAction)

드디어 이번 프로젝트의 목표인 무중단 배포를 할것입니다.
엘라스틱빈톡 & DB & CI/CD 배포를 해보겠습니다.
이전에는 jar 파일을직접 업로드 하였지만 이제는 jar파일마저 CI/CD를 통해 자동으로 배포하겠습니다.

 

기존 배포방식의 위험한점

테스트 환경과 실행 환경이 다르다

앞서 엘라스틱빈스톡으로 배포를 했습니다.
하지만 배포를 했다고 무조건 배포에 성공한다고 보장할 수 없습니다.

프로젝트는 로컬 컴퓨터에서 테스트했지만,
실제 배포는 리눅스 환경이기 때문입니다.

즉, 테스트와 실행환경이 다릅니다.

 

CI/CD

CI : 지속적 통합

CI를 성공적으로 구현할경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합 되므로 여러명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.  

 

CD : 지속적 배포

파이프라인의 추가 단계에 대한 자동화를뜻합니다.

얼마나 많은 자동화가이루어지고 있는지를설명하기 위해 별도로 사용되기도 합니다.   

 

배포 구성

1. build gradlew을 로컬에서 하여 jar파일을 만들지 않고 프로젝트를 Github에 배포합니다.
2. Github가 코드의 변경을 감지하여 CI (continuous Integration 지속적 통합) 서버를만든 뒤 프로젝트 전달.
3. CI서버에서 테스트하고 빌드하여 jar파일생성
   • 핵심은 CI서버가 AWS 환경(리눅스)과 동일해야 합니다.
4. CI서버에서 AWS로 배포한 뒤 실행
   • CI서버에서 테스트를 성공 했으면 실제 환경에서 무조건 실행에 성공합니다.
   • CI서버는 AWS에서의 실행 성공을 보장합니다.
      - 환경이 동일하기 때문입니다.
5. CI서버에서 실행파일(jar)생성 후 드래그하여 배포하지 않고, CD(Contunuous Delivery : 지속적 제공, 배포)를 합니다.
   • 즉, 자동배포를하는것입니다.
   • 총 2번 : CD가 실행 되는 시점
     1. 2번과정인 Github가 변경감지하여 CI서버로 배포할때
     1. 4번과정 성공 후 5번과정인 실행파일(jar)을 AWS로 배포할떄

주의할점

IAM

우리는 AWS로 배포할때 웹사이트에서 로그인되어있는 상태로 배포를 하였습니다.
하지만 CI/CD를 도입하면 CI서버에서 AWS에 접근하여 배포할때 CD를하기위해 Access Key가 필요합니다.
접근키를 만들기 위해 AWS의 LAM이라는 개념을 알아야 합니다.

 

Polling vs Webhook

폴링 : 지속적으로 request 요청으로 코드가 변경되었는지 확인합니다.

• while문으로 동작하기 때문에 서버에 많은 부하가 있습니다.
• Travis가 대표적입니다.

훅 : 코드가 변경되면 자동으로 변경되었다고 알려줍니다.

• 변경시에만 동작하기에 서버에부하가 적습니다.
• Jenkins가 대표적입니다.

 

개념은 전체적으로 알아보았으니 다음 블로그에서 배포를 진행해 보겠습니다.