AWS Code Series를 이용한 자동화 구성하기

오늘은 AWS Code Series(AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline)라고도 불리는 AWS CI/CD 서비스에 대해 알아보고 아키텍처를 구성해보려고 한다. 아키텍처를 구성하기 앞서 CI/CD란 무엇이고 AWS Code Series의 특징에 대해 알아보도록 하겠다.

CI/CD 소개
AWS Code Series 소개
데모 아키텍처 소개
자동화 구성 데모
마무리

1. CI/CD 소개

DevOps를 하면 빼놓을 수 없는 얘기가 자동화 파이프라인이라고도 불리는 CI/CD이다. CI/CD를 구축하는 궁극적인 목적은 소프트웨어 개발 라이프사이클을 간소화하고 가속하하여 개발자가 빠르게 변경 사항을 반영할 수 있도록 하기 위해서이다.

먼저 CI의 경우 continuous integration의 약자로 지속적 통합을 얘기하는데 해당 과정은 코드의 변경 사항이 빌드 및 테스트 되어 공유 레포지토리에 통합되는 과정이다. 그림에서는 plan부터 test까지의 과정을 말한다.

이후의 과정인 CD는 continuous delivery or deployment의 약자로 앞서 검증된 코드를 레포지토리로 릴리스하는 것을 자동화하며 프로덕션 레벨까지 배포하는 과정을 말한다.

배포 이후에는 운영 과정이며 이때는 모니터링을 통해 문제점이 있으면 이전 버전으로 롤백을 하거나 모니터링 지표를 보고 성능을 개선해서 다시 처음부터 계속해서 plan부터 operate의 과정이 순환되게 된다. 그래서 보통 CI/CD를 나타낼때는 뫼비우스의 띠 형태로 나타내곤 한다.

Jenkins
GitHub Actions
GoCD
CircleCI
ArgoCD
GitLab CI/CD
기타...

위에 있는 CI/CD 도구 이외에도 더 다양한 도구들이 존재하고 오픈소스인 것도 존재하고 상용 서비스인 것도 존재한다. 회사나 회사 내 팀마다 사용한 CI/CD 도구가 다를 수 있으며 해당 회사와 팀이 어떤 도구를 사용하는지 궁금하다면 채용 공고의 JD를 보는게 좋다.

2. AWS Code Series 소개

보통 우리가 아는 Code Series 같은 경우 크게 AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline 정도가 있다. 그 이외에도 AWS에는 Code가 prefix로 들어간 서비스들이 다양하게 존재하고 있으며 위의 그림 이외에도 CodeWhisper 등 다양하게 존재한다. 그중 오늘은 7가지 서비스에 대해 다뤄보려고 한다.

AWS CodeCommit

프라이빗 Git 리포지토리를 호스팅할 수 있는 완전 관리형 버전 관리 서비스
문서, 소스 코드, 바이너리 파일 등을 저장하여 관리
다른 원격 리포지토리에서 파일을 쉽게 마이그레이션 가능
Git 도구 활용 가능
PR 요청 승인 규측 템플릿 생성

AWS CodeCommit은 프라이빗 git 리포지토리를 호스팅할 수 있는 완전 관리형 버전 관리 서비스로 우리가 알고있는 github와 유사하다. github처럼 문서, 소스 코드, 바이너리 파일 등을 저장하여 관리할 수 있고 다른 원격 리포지토리에서 파일을 쉽게 마이그레이션도 할 수 있다. 즉, 깃헙에 있는걸 CodeCommit으로 가져올 수도 있으며 aws 상에서 리전 간에 복제도 할 수 있다.

github와 마찬가지로 git 도구를 활용해서 푸쉬나 커밋을 할 수 있고 깃크라켄 등의 툴들도 사용할 수 있다. 또한, 승인 규칙 템플릿이라는 것도 존재해서 PR 요청시 몇명이 승인해야 병합될 수 있도록 설정도 할 수 있다. github와 비교하자면 branch에 대해 protection을 걸어서 옵션을 적용하는 기능과 유사하다.

추가적으로 CodeCommit에서는 iam으로 권한 관리를 하기 때문에 특정 유저가 브런치에 접근하는 정책이나 파일을 올리거나 merge할 수 있는 정책 등 유저마다 분리해서 적용할 수 있다. 또한, eventbridge를 활용해서 PR요청이 있을때 lambda 함수를 동작시켜 특정 기능을 수행하도록도 할 수 있고 sns를 통해 알람을 보낼 수도 있다.

AWS CodeBuild

자체 빌드 서버가 필요 없는 완전 관리형 빌드 서비스
소스 코드를 컴파일하고, 단위 테스트를 실행하고, 배포할 아티팩트를 생성
필요에 따라 빌드 요구 사항에 맞게 확장할 수 있는 온디맨드 제공
다양한 프로그래밍 언어를 위한 사전 구성된 빌드 환경 제공

AWS CodeBuild는 자체 빌드 서버가 필요 없는 완전 관리형 빌드 서비스로 소스 코드를 컴파일하고, 단위 테스트를 실행하며, 배포할 아티팩트를 생성하게 된다. 해당 아티팩트는 s3에 저장된다. 추후에 연동할 CodePipeline에서 source나 build 단계에 나오는 아티팩트는 전부 s3에 저장되게 되고 source에서 나온 출력 아티팩트는 build 단계에서, build에서 나온 출력 아티팩트는 deploy 단계에서에서 해당 아티팩트를 참조하게 된다.

빌드의 대상이 되는 source의 경우 github, codecommit, s3, gitlab 등 다양하게 존재하고 있고 필요에 따라 빌드 환경을 구성할 용량을 알맞게 확장할 수 있는 온디맨드 프로비저닝 모델이나 예약형 프로비저닝 모델이 있다. CodeBuild는 자바나 파이썬 등의 다양한 프로그래밍 언어를 위한 사전 구성된 빌드 환경도 제공해주고 있다.

또한, CodeBuild는 vpc를 설정해서 build 시에 RDS나 elasticache 등에 대해 쿼리를 날리는 작업 같은 테스트를 진행할 수도 있으며 기본적으로는 vpc의 리소스에 액세스할 수 없다.

CodeBuild에서는 build 단계에서 어떤 작업을 수행할지에 대한 명세인 스크립트 파일도 필요하다. 스크립트 파일을 build 프로젝트를 구성할 때 커맨드를 하나씩 입력해서 구성할 수도 있고 따로 buildspec.yml을 만들어서 source의 최상단 디렉토리에 위치시켜 build 시에 참조할 수도 있도록 할 수 있다. 추가적으로 build 환경에 대한 환경 변수를 설정할 수도 있는데 build 프로젝트를 구성할 때 환경 변수를 입력하거나 buildspec.yml에 env로 설정할 수도 있다.

buildspec.yml 예시는 위의 그림과 같다. phases는 수행할 명령 단계별로 구성되어 있고 build를 위한 환경 설치 단계, 빌드 전 단계, 빌드 단계, 빌드 후 단계로 이루어져있0다. 또한, 여기에 앞서 언급했던 것처럼 env를 추가하여 환경 변수도 관리할 수 있다.

install 단계의 경우 ubuntu 최신 환경을 사용했기 때문에 별도로 설치할 구성이 없어서 생략을 하였고 build 전 단계에서는 aws ecr에 로그인 할 수 있는 명령어가 들어가 있다. 그 다음 빌드 단계에서는 도커 이미지를 빌드하고 ecr에 올릴 수 있도록 태깅하는 작업을 진행하게 된다. 빌드 후의 단계에서는 도커 이미지를 ecr에 올리는 작업을 수행되는 예시이다. 이렇게 간단하게 build 단계에서 어떤 명령어를 수행할지 간단히 정의할 수 있고 단계별로 잘 수행되는지 확인하기 위해 프로젝트를 구성할때 cloudwatch log를 활성화해서 모니터링 할 수 있다.

추가로 build도 마찬가지로 trigger나 알람을 설정을 할 수 있으며 여기서는 나와있지 않지만 테스트 과정도 buildspec에 정의할 수 있다.

AWS CodeDeploy

Amazon EC2, On-premise, AWS Lambda, Amazon ECS에 배포를 자동화하는 완전 관리형 배포 서비스
블루/그린 배포, In-place 배포와 같은 다양한 배포 전략 (배포 대상에 따라 지원되는 배포 전략 제한 존재)
AWS 콘솔이나 CLI를 통해 손쉽게 애플리케이션 배포를 시작하고 상태 추적
오류가 있는 경우 자동 또는 수동으로 배포를 중지하고 롤백 가능

AWS CodeDeploy 서비스는 Amazon EC2, 온프레미스, AWS Lambda, Amazon ECS 에 배포를 자동화하는 완전관리형 배포 서비스로 배포 전략도 블루/그린, In-place 배포(Amazon ECS는 블루/그린 배포 전략만 지원)와 같은 다양하게 지원하고 있고 트래픽 전환 유형의 경우 선형, 카나리, 한번에 전환 같은 유형들이 있다. (카나리 유형은 카나리아 새에서 유래가 되었고 해당 새는 탄광에서 유독가스의 누출 위험을 알리는 용도로 활용되었다. 그래서 카나리 유형은 일부 트래픽만 허용하여 관리하다 문제가 없으면 전체 트래픽을 전환하는 방법을 의미한다.)

또 다른 특징으로 AWS 콘솔이나 CLI를 통해 손쉽게 애플리케이션 배포를 시작하고 배포 상태를 추적할 수 있으며 오류가 있는 경우 자동이나 수동으로 배포를 중지하고 롤백할 수도 있다. 그리고 EC2나 온프레미스에 배포할 경우 CodeDeploy agent라는 것이 해당 인스턴스에서 동작하고 있어야 하며 ECS나 Lambda의 경우 CodeDeploy agent가 필요 없다. CodeDeploy도 CodeBuild와 마찬가지로 동작에 대한 정의하는 파일이 필요한데 CodeDeploy에서는 appspec.yaml이라고 한다. (파일 세부 내용은 데모 단계에서 소개할 예정)

AWS CodePipeline

소프트웨어 릴리스에 필요한 단계를 시각화 및 자동화하는 데 사용하는 완전 관리형 CI/CD 서비스
AWS 콘솔이나 CLI를 통해 소프트웨어 릴리스 프로세스 단계를 정의
V1과 V2 유형이 존재하며 V2유형의 경우 병렬 실행 모드 지원

AWS CodePipeline 서비스는 소프트웨어 릴리스에 필요한 단계를 시각화 및 자동화하는데 사용하는 완전 관리형 CI/CD 서비스이고 앞서 살펴본 서비스들을 통합해서 하나의 workflow 형태로 만들 수 있다. AWS 콘솔이나 CLI를 통해 소프트웨어 릴리스 프로세스 단계를 source,build 및 test, deploy와 같이 정의할 수 있다.

CodePipeline 유형은 v1과 v2가 있는데 v1은 표준 파이프라인, 단계, 작업 수준 파라미터를 포함하는 json 구조를 가지고 있고 v2는 v1 유형과 구조는 비슷하지만 추가적으로 릴리스 안전 및 트리거 구성을 위한 파라미터를 가지고 있다. 물론 유형에 따라 비용 차이가 있으며 v1은 파이프라인 생성 후 한달간 무료이며 한달동안 변경이 한번 이상 있는 경우에만 비용이 청구되며 v2는 작업실행 분당으로 요금이 청구된다고 한다. 또한, v2의 경우엔 대기 모드와 병렬 모드가 있는데 대기 모드는 우리가 아는 queue 형태처럼 순서대로 동작을 하게 되고 병렬 모드는 동시에 독립적으로 실행되며 대기 모드 방식처럼 다른 실행이 다른 종료를 기다리지 않는다.

Pipeline 단계 사이에는 아티팩트라는 파일이 생성(이는 S3에 저장되게 된다.)이 되는데 아티팩트는 애플리케이션 코드가 있는 파일 또는 폴더, 인덱스 페이지 파일, 스크립트 등과 같이 Pipeline 작업에 의해 작동되는 파일을 말한다.

AWS CodeArtifact

안전하고 확장성이 뛰어난 관리형 아티팩트 리포지토리 서비스
주로 애플리케이션 개발을 위한 소프트웨어 패키지를 저장하고 공유하는 데 사용
npm, yarn, Gradle, Maven 등과 같은 빌드 도구 및 패키지 관리자와 함께 사용 가능

AWS CodeArtifact는 안전하고 확장성이 뛰어난 관리형 아티팩트 리포지토리 서비스이다. 주로 애플리케이션 개발을 위한 소프트웨어 package 같은 dependencies를 저장하고 공유하는데 사용하며 npm, yarn, gradle, maven 등과 같은 빌드 도구 및 패키지 관리자와 함께 사용이 가능하다.

개발자들은 CodeArtifact와 npm 같은 public artifact 리포지토리를 연결해서 패키지를 설치한 경우 dependencies들을 외부 레포지토리가 아니라 CodeArtifact를 통해 가져오고 공유할 수 있다. 즉, 우리는 똑같은 패키지를 다른 환경에서 또 설치할 필요가 없게 된다. 추가로 CodeArtifact 서비스는 AWS IAM을 이용해서 접근 권한 관리를 할 수도 있다.

AWS CodeStar

소프트웨어 개발 프로젝트를 생성, 관리, 작업하기 위한 클라우드 기반 서비스
템플릿 프로젝트를 통해 애플리케이션을 빠르게 개발, 빌드, 배포 가능
프로젝트 대시보드를 통한 활동 내역 모니터링

AWS CodeStar는 소프트웨어 개발 프로젝트를 생성, 관리, 작업하기 위한 클라우드 기반 서비스이다. 템플릿 프로젝트를 통해 애플리케이션을 빠르게 개발, 빌드, 배포 가능하고 프로젝트 대시보드를 통한 활동 내역 모니터링 할 수 있다. 하지만 해당 서비스는 올해 7월 31일부터 지원이 중단되고 이 다음 서비스인 CodeCatalyst를 사용하길 권장하고 있다.

AWS CodeCatalyst

소프트웨어 개발 프로세스에 CI/CD 방식을 도입하는 개발 팀을 위한 완전 관리형 통합 서비스
모범 사례가 적용된 Blueprint를 통한 프로젝트 생성
workflow를 통한 빌드, 테스트, 배포 자동화

AWS CodeCatalyst 서비스는 2022년 리이벤트에서 소개된 서비스로 소프트웨어 개발 프로세스에 CI/CD 방식을 도입하는 개발 팀을 위한 완전관리형 통합 서비스이다. 해당 서비스를 사용하면 모범 사례가 적용된 Blueprint를 통한 프로젝트 생성할 수 있고 workflow를 통한 빌드, 테스트, 배포 자동화 기능도 이용할 수 있다. LG CNS에서 CodeCatalyst에 대한 간단한 사용 과정들을 정리해서 관심이 있다면 한번 봐도 좋을 것 같다. (CodeCatalyst는 AWS 콘솔 대시보드와 다른 사이트로 구분되어 있으며 해당 사이트를 참고하면 좋을 것 같다.)

3. 데모 아키텍처 소개

앞서 살펴봤던 AWS Code Series 중 AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline을 이용해서 Amazon ECS에 새로운 컨테이너를 자동으로 배포하는 CI/CD 워크플로우에 대한 데모 아키텍처를 구성해보았다.

간단한 데모 아키텍처라서 개발자가 코드를 변경해서 main branch에 반영하면 CodePipeline을 동작시켜서 CodeBuild와 CodeDeploy 서비스가 동작해서 build 과정과 deploy 과정을 수행하도록 구성하였다.

git push를 통해 CodeCommit Repository에 변경 사항 반영 (main branch에 변경 사항이 생기면 CodePipeline이 동작되도록 구성)
CodeBuild가 buildspec.yml을 참조해서 build 수행
새로운 코드 변경을 반영해서 새로운 컨테이너 이미지를 생성해 ECR에 업로드
ECS Task Definition에 새로운 이미지 url 반영
appspec.yml의 properties 중 TaskDefnition을 새로운 이미지가 반영된 revision Task Definition으로 수정
CodeDeploy가 appspec.yml을 참조해서 deploy 수행
ECS Cluster Service에 블루/그린 방식으로 새로운 Task가 배포(CodeDeploy에서 ECS 배포 전략은 블루/그린 방식만 지원)
배포 대기 시간이 끝나면 이전 Task 종료 작업 진행
배포 작업이 끝나면 CodePipeline이 success 처리되고 종료

이젠 위의 전체 동작 과정들을 AWS 콘솔 화면을 통해 어떻게 구성하였는지에 대해 소개하려고 한다. 모든 코드는 다 github에 있으니 참고하면 좋을 것 같다.

4. 자동화 구성 데모

먼저 AWS CodeCommit 서비스를 이용해서 하나의 리포지토리를 생성하였다. CodePipeline의 source로 사실 github을 써도 상관은 없지만 AWS Code Series를 이용해보기 위해 전부 다 aws 서비스를 활용하였다.

해당 리포지토리를 이용하는 방법은 ssh와 https 같은 방법이 있다. 여기서는 간단하게 https를 이용해보려고 한다. 추가로 GRC는 git-remote-codecommit으로 Git 자격 증명 설정 필요 없이 AWS CLI를 이용해서(aws 커맨드를 설치해야한다.) IAM으로 접근할 수 있다. 그리고 해당 IAM은 AWSCodeCommitFullAccess 또는 AWSCodeCommitPowerUser 권한을 가지고 있어야 한다. GRC를 설치한 뒤에 aws configure라는 명령어를 통해 설정할 수 있다. 이때 url은 우리가 흔히 아는 https형식이 아니라 codecommit으로 시작하는 GRC용 url(codecommit://)이 따로 있다.

여기선 간단한 방법으로 Git 자격증명을 다운받아서 진행을 해보도록 하겠다. 해당 자격 증명 생성을 누르면 가이드가 뜨게 되고 가이드에 따라서 IAM user 페이지로 이동하면 된다.

그 다음 Git 자격 증명을 생성해서 다운로드 후 github에서 git clone을 하는 git clone https url을 적어주고 user와 password는 자격증명을 생성해서 다운로드 한 계정을 사용하도록 한다.

그 다음 AWS CodeBuild 프로젝트 구성 과정이다. 소스 공급자로 이전에 만든 CodeCommit을 선택하였고 여기서 github이나 gitlab 등을 선택할 수도 있다. branch 같은 경우는 main에 push가 있을 경우 build하기 위해서 main branch를 선택했다.

그 다음 build 환경 구성이다. 프로비저닝 모델은 온디맨드 형태로 새로운 빌드에 대해 자동으로 프로비저닝을 하도록 선택하였고 예약 용량을 설정하는 방법도 있다.

build 환경의 구성 이미지의 경우 관리형 이미지를 사용하였고 컴퓨팅 환경도 EC2의 ubuntu를 선택하였다. 사용자 지정 이미지의 경우 ECR이나 다른 외부 registry를 사용할 수도 있으며 컴퓨팅 환경을 lambda로 설정할 경우 런타임 환경을 언어에 맞게 수정할 수 있다. 하지만 lambda 클릭하면 나오는 안내문처럼 속도 최적화와 작업 시작 시간 최소화를 사용하다보니 예약 용량 같은 옵션 등을 사용할 순 없다. 즉, 필요에 맞게 선택해야한다. CodeBuild 서비스를 위한 역할은 기존에 없어서 새로 생성을 해주었다.

추가로 구성할 수 있는 파라미터로는 제한 시간, 인증서, vpc 설정, 컴퓨팅 환경 등이 있다. 앞서 언급했듯이 build 및 test 단계에서 RDS와 같은 vpc 내부 서비스에 접근할 필요가 있다면 vpc를 선택해주면 된다. 또한, build 환경에 대한 환경 변수를 노출할 수도 있는데 여기선 region 정보나 aws account id 정보를 일반 텍스트로 넘겨주었고 이외에도 parameter store나 secrets manager를 활용할 수 있다.

빌드 사양의 경우 명령을 하나씩 삽입하지 않고 리포지토리 최상단 디렉토리인 root에 buildspec.yml을 정의해서 사용할 예정이기 때문에 파일 사용을 선택하였다. 그리고 도커 이미지를 ECR에 넣을 예정이기 때문에 아티팩트는 없음을 선택하였다.

위는 CodeBuild에 사용한 buildspec.yml 파일이다. build 까지의 단계에선 AWS ECR에 로그인 하고 docker 이미지를 빌드해서 push하는 작업을 하였다. post build 단계에서는 CodeDeploy가 ECR에서 이미지를 검색할 수 있도록 image uri인 imageDetail 파일을 생성했고 ECS의 작업 정의를 수정해서 반영한뒤 개정된 taskDefinitionArn을 반환받아서 CodeDeploy에서 사용할 appspec.yml에 반영하였다. 그 다음 CodeDeploy에서 해당 파일들을 활용할 수 있도록 artifacts에 세개의 파일들을 넘겨주었다.

위는 CodeDeploy에 쓰이는 appspec.yml 파일이다. target service는 ECS로 하였고 taskdefinition에 개정된 task definition을 반영할 수 있도록 하였다. 이 이외에 다른 내용은 기본적인 vpc subnet 설정이나 컨테이너 이름이나 포트 정보 등을 담았다.

여기에 나와있지 않지만 추가로 hooks을 설정해서 install 전이나 install후에 유효성 검사를 lambda function으로 할 수 있고 이외에도 트래픽을 전환하기 전이나 후에 유효성 검사를 하는 hooks을 설정할 수도 있다.

추가로 CodeBuild 서비스에 대한 권한을 조금 변경해야하는데 아래처럼 ECR과 관련된 권한을 추가하고 ECS 작업 정의를 수정하기 위해서 ECS에 대한 접근 정책을 추가해줘야 한다.

다음으로 AWS CodeDeploy 설정이다. CodeDeploy 애플리케이션 생성하는 방법은 되게 간단하게 애플리케이션 이름과 컴퓨팅 플랫폼만 선택해주면 된다.

애플리케이션을 구성했다면 이젠 해당 배포 그룹을 생성해줘야 한다. 배포 그룹의 서비스 역할은 ECS에 배포하고 S3에서 빌드 이후에 전달될 아티팩트에 접근하기 위해 ECS와 S3에 접근할 수 있는 권한을 부여해주어야 한다.
그 다음 배포할 ECS의 클러스터와 서비스를 선택해주면 된다. 이때 CodeDeploy에서 ECS에 대해 블루/그린 배포 전략만 지원하기 때문에 서비스는 블루/그린으로 배포하도록 구성해야 한다.

그 다음 로드 밸런서구성이다. 여기선 테스트 리스너 포트도 선택해서 테스트 과정을 추가할 수 있으며 대상 그룹은 두개를 등록해서 새로운 대상 그룹으로 배포할 수 있도록 구성해야 한다.

배포 설정의 경우 기본으로 되어있는 즉시 트래픽을 다시 라우팅으로 설정하고 배포 구성의 경우 한번에 전부 라우팅하는 것으로 설정했다. 그리고 기존 개정 종료는 기존 작업 세트를 종료하기 전에 대기하는 시간이며 종료가 시작된 후에는 수동 또는 자동으로 롤백할 수 없기 때문에 적절한 시간을 선택하여 새로운 배포에 문제가 생겼을 경우 바로 롤백할 수 있도록 구성해야 한다.

이제 배포를 위한 모든 서비스를 구성하였기 때문에 이를 하나의 워크플로우로 자동화할 수 있도록 AWS CodePipeline을 이용해서 구성하였다.

파이프라인 유형은 queue형태로 순서대로 배포하는 대기 모드를 선택해서 진행하였으며 CodePipeline에 대한 새로운 서비스 역할을 생성하도록 구성하였다. (기존에 있다면 기존 서비스 역할 활용)

소스 공급자로는 AWS CodeCommit을 선택하였고 이외에는 전부 기본 값으로 세팅하였다. 출력 아티팩트 형식의 경우엔 후속 작업에서 git command를 수행할 일이 있다면 전체 복제를 선택하면 되고 아닌 경우엔 기본값을 사용하면 될 것 같다.

빌드 공급자로는 이전에 만든 AWS CodeBuild 프로젝트를 설정해주었고 환경 변수는 이전에 등록을 했기 때문에 추가하지 않고 넘어가면 될 것 같다.

배포 공급자로는 이전에 만들었던 CodeDeploy를 사용하였고 이외에도 ECS나 Elastic Beanstalk 등을 설정할 수도 있다. 또한, 각 스테이지마다 건너뛰기 옵션이 있는데 건너뛰기를 해도 이후에 pipeline 대시보드 각 스테이지에서 추가해주거나 그냥 스킵할 수도 있다.

검토 후 이상이 없다면 파이프라인 생성을 클릭해서 생성해주면 되고 이후에도 파이프라인의 각 스테이지를 편집해서 수정할 수 있다.

이제 자동으로 새로운 이미지를 빌드하고 ECS에서 서비스를 할 수 있도록 CICD 자동화 워크플로우를 구성하였다. 이제 실제로 잘 동작하는지 확인하기 위해 위처럼 코드를 바꾸고 git push를 진행하여 AWS CodePipeline의 대시보드를 관찰하였다.

위에서 살펴본 것처럼 코드를 변경해서 main branch에 반영하면 CodePipeline이 동작하게 되고 각 스테이지가 queue 형태로 동작하게 된다. 배포 단계에서는 설정한 종료 시간 전까지 ECS의 Service에는 기존 Task와 새로운 Task가 존재하고 있고 종료 후에는 기존 Task가 사라지게 된다.

5. 마무리

AWS Code Series 이외에도 많은 CI/CD 도구들이 존재하는데 그 중 많이들 사용하는 Github Actions과 AWS Code Series로 CI/CD를 구성했을 때 각각의 장단점은 다음과 같은 것 같다.

	AWS Code Series	Github Actions
Pros	- Credit이 있는 경우 활용하기 좋음 - console 화면으로 간편하게 구성 가능 - IaC를 활용해 코드로 관리 가능	- 소스 코드를 Github로 관리하는 경우 사용하기 편리 - market에 있는 actions을 가져다가 쓰면 돼서 편리
Cons	- target과 source 요소가 제한적 - 클라우드 서비스라 비용이 존재	- 일정 시간이 넘어가면 별도의 비용 청구가 존재 - Script를 짜야함(code series에 비해 복잡도 증가)

저작자표시

'Cloud > AWS' 카테고리의 다른 글

AWS Lambda 내용 정리 (0)	2023.05.28
AWS Cloudtrail & EventBridge를 이용해서 s3 작업에 대한 컨테이너 작업 (0)	2023.04.05
AWS CodeDeploy에 대해 알아보기 (0)	2023.04.02
AWS Kinesis Data Firehose를 consumer로 이용해서 AWS S3로 데이터 스트리밍 (0)	2023.03.25
AWS ALB에서 경로에 대한 람다 함수 호출 (0)	2023.03.19