EC2 CICD Automation - 1. Intro

EC2에 자동화 배포를 구성할 때, 사용하는 가장 기본적인 구조를 보도록 하겠습니다.

 

Jenkins CICD Automation 기본 구조 흐름

개발자는 CodeCommit Repository에 Git Push를 하면서 소스 업데이트를 하고,

 

젠킨스에서 이 해당 Repository를 보고 있다가 Job Run을 수행하면서 Git clone 후 Build를 합니다.

(만약 Flask와 같이 Jar 빌드등이 필요하지 않은 경우 Build 부분은 생략됩니다.)

 

이후 Build된 Jar 파일과, CodeDeploy가 배포를 하기 위해 어떤 수행을 할 것인지 정의해주는

appspec.yaml, 그리고 appspec.yaml에서 정의되어 실제 서비스를 수행할 deploy.sh 파일을 작성하여

세 파일을 zip으로 묶어 S3에 Job Build Number대로 버킷 구조를 만들어 업로드합니다.

이렇게 버전별로 구성하면 롤백을 하기 위한 세팅도 구성할 수 있습니다.

 

정상적으로 업로드 되었다면, AWS CLI를 통해 Create Deployment를 수행하여 CodeDeploy를 통해 EC2에 배포합니다.

위의 AWS CLI를 통해 만들어진 Deployment ID 값을 가지고,

AWS CLI Get Deployment를 통해 젠킨스에서 CodeDeploy의 배포 성공 여부까지 체크하게 합니다.

 

다른 부분은 큰 어려움이 없는 요소이지만, CodeDeploy의 구성은 한 번 살펴볼 필요가 있습니다.

간단하게 CodeDeploy의 구성을 보면 위와 같습니다.

전체 어플리케이션이라고 하는 코드 디플로이가 배포할 큰 껍데기를 정의하고(이름만),

Deployment Group으로 구체적으로 배포할 서버를 정하고

AutoScaling Group을 바라보고 진행할 것인지 서버의 Tag값을 기준으로 서버를 지정할 것인지

배포 유형을 롤링으로 할 것인지, 블루/그린으로 할 것인지

배포를 전체를 한 번에 다 할 것인지 서버 한 개씩 진행할 것인지에 대한

배포를 어디에 어떻게 할 것인지를 정의합니다.

 

저 같은 경우는 어플리케이션을 API-1

Deployment Group을 DEV / STG / PRD 등 운영 환경에 따라 나누어 구성합니다.

이 부분은 반대로 구성하여도 되기 때문에 아키텍쳐 구성을 어떤식으로 가져가실 지 정하시면 되는 부분입니다.

 

이제 Create Deployment를 수행하여 배포를 만들 때는

위에서 정의한 Deployment Group의 배포 방식을 가지고 어떤 소스(S3 경로)를 가지고 배포할 것인가를 정해주시면 됩니다.

추가적으로 appspec.yaml에서 실제 배포될 서버안에서의 경로를 지정하는데 만약 해당 경로에 같은 파일이 지속적으로

배포해 오던 파일이 아닌 경우 이미 파일이 있다는 에러가 발생하며 배포가 실패할 수 있습니다.

따라서 컨텐츠 옵션에서 컨텐츠 덮어쓰기 옵션을 선택하여 진행하는 것이 좋습니다.

 

좀 더 상세한 부분들은 핸즈온 포스트를 보면서 이해하시면 될 것 같습니다.

다음 포스트 부터 본격적인 배포 자동화 기본을 구성해보겠습니다.