📌CodeDeploy란?
CodeDeploy는 EC2, Lambda, On-Premise 등 다양한 컴퓨팅 서비스에 대한 배포를 자동화하는 완전 관리형 배포 서비스이다. AWS에서 완전히 관리해주는 서비스이기 때문에 신속하고 안전하게 배포가 가능하다. 또한 배포 방식도 다양하게 구성할 수 있는데 배포중인 애플리케이션이 완전히 다운되는 것을 막기 위해 최소한의 구동되고 있어야 할 인스턴스 퍼센트를 정의한다거나 Blue/Green Deployment를 수행하는 등의 과정으로 가동 중지 시간을 최소화할 수 있다.
CodeDeploy를 사용하기 위해서는 먼저 인프라를 프로비저닝해야 한다. Deployment에서 인프라를 자동으로 생성해주지는 않기 때문에 내가 어디에 이 애플리케이션을 배포할 것인지, 어떤 환경에 배포할 것인지 등을 정하여 미리 생성해두어야 한다. 그 후 배포하고자 하는 환경에 CodeDeploy Agent를 설치해야 한다. 설치된 agent가 지속적으로 CodeDeploy를 polling 하면서 새로 배포해야 할 정보들을 받아온다. 그 후 배포할 애플리케이션의 코드와 appspec.yml을 github 혹은 S3에 업로드한다. 여기까지 Deployment를 생성하기 위한 사전 설정이 끝났다면 CodeDeploy application을 생성한다. 그리고 배포를 수행할 배포 그룹을 설정하고 앞에서 프로비저닝한 인프라를 지정해준다. 배포 생성 후 Deploy를 생성하여 수행하면 정의한 appspec.yml에 따라 동작하며 배포한다.
배포 그룹을 설정하는 과정에서 생성한 인스턴스를 태그 등으로 구분할 수 있다. 여기서 CodeDeploy의 큰 장점이 등장한다. 인스턴스마다 Test, Prod, Dev 등 다양한 태그를 설정해놓은 후 각 태그별로 배포 그룹을 생성하면 각 용도에 맞는 배포 환경을 설정할 수 있다. 즉 인스턴스를 태그로 구분하여 그룹을 생성하고 각 그룹에 맞는 배포 환경을 따로 설정할 수 있다. 예를 들어 개발 환경의 경우 빠르게 결과를 확인하거나 동작 확인을 하기 위해 구성하였으므로 실제 애플리케이션 사용자에게 영향을 미치지 않기 때문에 인스턴스가 잠시 모두 다운되어도 괜찮다. 따라서 여러 인스턴스를 한번에 배포하는 'AllatOnce'로 선택하여 한번에 수행하도록 설정한다. 반면 Prod의 경우 실제 사용자에게 제공되는 배포 환경으로, 끊김없이 지속되어야 한다. 따라서 인스턴스 하나씩 배포하여 안정적인 상태를 유지하는 'OneatOnce'로 선택한다. 물론 이 외에도 원하는 만큼 인스턴스를 유지하도록 설정하는 등 다른 형태로도 배포가 가능하다.
CodeDeploy 역시 CloudWatch와 함께 사용할 수 있다. event의 경우 deploy가 실패했을 때 slack 알람을 가도록 설정한다던지, state가 변경될 때마다 스트림 분석을 위해 kinesis로 전송한다는 등의 설정을 할 수 있다. Logs의 경우 인스턴스에 CloudWatch log agent를 추가로 설치해야 하며 로그 정보를 확인할 수 있다.
배포가 실패하거나 설정한 알람이 울리는 경우 rollback 기능도 지원한다. 새로 배포한 인스턴스가 아얘 시작 자체가 안되거나 급격히 리소스 사용량이 많아지는 등 문제 상황이 발생했을 시 안정적인 버전의 애플리케이션을 다시 배포하기 위해 롤백한다.
CodeDeploy 동작 구조
1️⃣ 소스코드와 appspec.yml을 리포지토리에 push한다.
2️⃣ deployment를 트리거한다.
3️⃣ CodeDeploy를 polling하고있던 EC2 인스턴스는 트리거를 확인한다.
4️⃣ 리포지토리에서 소스코드와 appspec.yml 파일을 받아와 deployment 명령을 수행한다.
appspec.yml
Deployment 명령어에 해당하는 appspec.yml 파일 형태는 위와 같다. 배포할 소스코드의 위치와 새로 저장 할 위치를 지정한 후 hooks을 지정한다. hooks은 배포 과정 단계에서 각각 수행해야 할 명령어들을 정의한 것이다. 보통 쉘 스크립트로 정의하며 당연히 해당 스크립트 파일도 함께 S3 혹은 Github에 존재해야한다. 각각의 hooks 단계에서 정의해야 할 동작은 아래와 같다.
- BeforeInstall 대체 작업 세트가 생성되기 전에 작업을 실행하려면 이 항목을 사용한다. 대상 그룹 하나가 원래 작업 세트와 연결된다. 테스트 리스너가 지정된 경우 원래 작업 세트와 연결된다. 이 시점에서는 롤백이 불가능하다.
- AfterInstall 대체 작업 세트가 생성되고 대상 그룹 중 하나가 연결된 후 작업을 실행하면 이 항목을 사용한다. 테스트 리스너가 지정된 경우 원래 작업 세트와 연결된다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있다.
- AfterAllowTestTraffic 테스트 리스너가 대체 작업 세트에 트래픽을 제공한 후 작업을 실행하려면 이 항목을 사용한다. 이 시점에서 후크 함수의 결과는 롤백을 트리거할 수 있다.
- BeforeAllowTraffic 두 번째 대상 그룹이 대체 작업 세트와 연결된 후 트래픽이 대체 작업 세트로 전환되기 전에 작업을 실행하려면 이 항목을 사용한다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있다.
- AfterAllowTraffic 두 번째 대상 그룹이 대체 작업 세트에 트래픽을 제공한 후 작업을 실행하려면 이 항목을 사용한다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있다.
배포하는 환경에 따라 설정하는 hooks이 다르므로 공식 사이트를 참조하여 설정하도록 하자.
'Cloud + System > AWS' 카테고리의 다른 글
AWS람다 (서버리스) (0) | 2021.10.23 |
---|---|
[AWS] S3란? 무제한으로 저장할 수 있는 스토리지! (0) | 2021.10.19 |
[AWS] RDS란 무엇인가 (0) | 2021.10.19 |
[AWS] EC2(Elastic Compute Cloud) 란? (설치 포함) (0) | 2021.10.19 |
[AWS] 1.AWS란? (0) | 2021.10.16 |