[CICD] Terraform을 통한 AWS 3 Tier 구성 및 CI/CD 파이프라인 배포 #1 - 아키텍처 및 CICD 흐름 소개

개요

Terraform을 통하여 AWS의 각종 자원들(VPC, EC2, ALB, NLB, AutoScaling Group, ..)을 생성하고 Application 배포 자동화를 위한 Jenkins + AWS CodeDeploy 구축 이후 WAR 파일 배포를 진행해 볼 예정이다.

 

요즘에는 WAR를 말아서 Tomcat에 직접 배포하는 것이 아닌 JAR 파일에 있는 내장 톰캣을 사용하지만 아직도 많은 회사에서는 Tomcat을 직접 구성하여 사용하고 있기 때문에 3 티어를 구현하여 인프라를 구현해 볼 예정이다.

(SpringBoot는 처음 사용해보기 때문에 hello만 출력하는 페이지를 생성하였음)

 

어떠한 것들을 사용할 것인지 간략하게 소개해보겠다.

 

1. 인프라

  - Terraform

  - Packer

 

2. CI/CD

  - Jenkins

  - CodeDeploy

 

3. Application

  - SpringBoot

  - Maven

 

아키텍처

아키텍처는 아래와 같다.

 

- Jenkins : CI 용도, Public Subnet에 편의상 위치해 두었으며, 실 서비스 환경일 경우 Private Subnet에 위치하여 LB를 경유하여 접근하는 것이 바람직 할 것으로 보인다.

 

- WEB : Nginx를 사용하여 정적인 컨텐츠 처리 및 캐싱, Reverse Proxy 용도로써 활용

 

- WAS : Tomcat 9를 사용하였으며 동적인 컨텐츠를 처리하는 용도로써 활용

 

- RDS : MySQL 5.7 버전 (인프라만 구축하였으며 Demo 애플리케이션에는 사용하지 않음)

 

- S3 : 빌드 한 WAR 파일 및 appspec.yml, 배포 스크립트들을 저장하기 위한 객체 스토리지

 

- Code Deploy : CD 용도, S3로부터 zip 파일을 가져와 WAS EC2에 배포하는 역할을 한다.

 

- 앞 단에 ALB를 활용하여 TLS Termination을 처리하며 뒷 단의 WEB, WAS 사이에는 NLB를 두어 WAS 서버의 헬스 체크 및 부하 분산을 담당해준다.

 

- Route 53, ACM : 도메인 및 인증서 관리

사용자

Clinet는 pingping2.shop 이란 Domain을 통하여 WEB 서버 및 WAS 서버에 접근하게 된다.

관리자

관리자는 Bastion Host를 거쳐 WEB, WAS, RDS에 접근하게 된다.

개발자

개발자는 Git을 통하여 각 서비스에 배포하게 된다.

CI / CD 흐름

1. 개발자가 Git Push를 하게 되면 GitHub에서 Jenkins 서버로 Webhook을 발생

2. GitHub에서 Source Code Push Event가 발생하였음을 Webhook을 통해 Jenkins가 인지

3. Jenkins에 정의된 Job에는 다음의 정보가 있다.
    - GitHub 원격 Repository의 URL
    - GitHub 원격 Repository의 Branch

    - GitHub에 대한 자격 증명 정보 (Secret Token이 될 수도 있고 Username, Password 등이 될 수도 있다.)

4. 3번의 정보로부터 Jenkins는 자신의 서버에 소스 코드를 받아온다.
    ⇒ /var/lib/jenkins/workspace/${JOB_NAME}/ 경로에 받아옴

5. Jenkins가 본인이 가지고 있는 Maven 을 이용하여 WAR 파일 Build를 시작한다.

6. Build가 성공적으로 마무리되면 Scripts/deploy.sh, appspec.yml 파일과 WAR 파일을 zip 파일로 압축하여 S3에 업로드한다.

7. Jenkins는 Code Deploy에게 Build한 WAR 파일을 S3의 특정 위치에 업로드하였으니 배포함을 요청한다.

8. Code Deploy는 appspec.yml에 정의된 정의서대로 배포를 수행하며, Scripts/deploy.sh 에 정의된 내용대로 배포할 서버내에서 쉘 스크립트를 수행한다.

9. deploy.sh는 WAR 파일을 정상적으로 배포할 수 있도록 다음의 과정이 주로 이루어진다.
    1) 기존에 실행중인 tomcat 서비스 중지
    2) 기존에 WAR 파일을 삭제
    3) WAR 파일을 webapps 디렉터리에 배포
    4) tomcat 서비스 재시작

10. CodeDeploy & ASG에서 Blue & Green 배포가 이루어진다.

 

11. 신규 ASG에서의 배포 및 서비스 확인이 완료되면 기존 ASG는 트래픽을 끊고 제거를 시작한다.

 

 

 

간단한 CI/CD 흐름을 알아보았으며 다음에는 SpringBoot 데모 샘플을 만들고 이를 Docker 및 EC2에 간단하게 배포해 볼 예정이다.