[AWS] CI/CD를 위한 Cloud9, CodeCommit, CodeBuild, CodeDeploy, CodePipeline 의 개념

CI/CD 란?

• CI (지속적인 통합)
• CD (지속적인 전달, 배포)
• CI/CD를 위한 도구들

 

AWS Cloud9 이란?

 

AWS CodeCommit 이란?

• 소스 관리 시스템이란?
• CodeCommit 동작 방식

 

AWS CodeBuild 란?

 

AWS CodeDeploy 란?

• AWS CodeDeploy의 구성요소
• In-Place 배포 방식
• Blue/Green 배포 방식
• AWS CodeDeployment 의 라이프 사이클
• AppSpec.yaml 구성

 

AWS CodePipeline 이란?

 

---

CI/CD 란?

 

 

 

애플리케이션 개발에 필요한 여러 단계에 대한 자동화를 통해 애플리케이션을 보다 빠르고 짧은 주기로 고객에게 제공하는 방법론

새로운 코드의 통합, 빌드, 테스트, 릴리스, 배포 등의 애플리케이션 라이프사이클 전체에 대한 자동화 과정

 

 

CI (Continuous Integration)

지속적인 통합을 의미

개발자가 작성한 코드를 정기적으로 빌드 및 테스트하고 공유 리포지토리로 병합

 

여러 명의 개발자가 동시에 작업할 경우에도 충돌없이 문제 해결 가능

 

목표

• 새 코드가 체크인될 때 새 빌드를 자동으로 시작
• 일관되고 반복 가능한 환경에서 코드 빌드 및 테스트
• 배포에 사용할 아티팩트(산출물)를 지속적으로 준비
• 빌드 실패 시 피드백 루프를 최적화

 

구성요소

• 리포지토리 관리
• 빌드 자동화
• 셀프 테스트
• 반영을 통한 빌드

 

 

CD (Continuous Delivery, Deployment)

지속적인 전달, 배포의 의미소스코드의 변경 사항을 병합하고, 운영 환경에 배포 가능한 적합한 빌드 제공에 필요한 테스트 자동화, 소스 배포의 자동화

 

 

Continuous Delivery vs. Continuous Deployment

 

 

두 용어는 상호 교환적으로 사용.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용

 

Continuous Delivery, 지속적인 전달

개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것

 

 

Continuous Deployment, 지속적인 배포

개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미

 

 

목표

• 테스트를 위해, 스테이징 환경에서 새로운 변경 사항 자동 배포
• 고객의 사용성에 영향을 미치지 않고 안전하게 프로덕션 환경으로 배포
• 고객에게 신속하게 제공. 배포 빈도를 높이고, 변경 리드 타임 및 변경 실패율 감소

 

cf) 프로젝트 환경 : 로컬(Local) / 서버 개발(dev) / 통합 개발 (Integration) / 테스팅 (QA) / 스테이징 (Staging) / 운영 (Production)

 

 

구성요소

Continuous Delivery

• 빌드 자동화
• Continuous Integration
• 테스트 자동화
• 배포 자동화

 

Continuous Deployment

• 리포지토리 체크인
• 통합 테스트
• 운영 환경 배포

 

 

CI/CD 를 위한 도구들

구분	내용
소스코드 관리	GIT, Bitbucket, Subversion
빌드 자동화 도구	Maven, Ant, Gradle
테스트 자동화 도구	Selenium, JUnit, Lambda test
CI 도구	Jenkins, Bamboo, Hudson
구성 관리 도구	Terraform, Puppet, Chef, Ansible
모니터링 도구	프로메테우스, 그라파나

 

 

 

 

---

 

AWS CIoud9 란?

 

웹 브라우저만으로 코드의 개발 및 실행 디버깅을 수행할 수 있는 클라우드 기반 IDE (ODE 라고도 함)

ODE 중 가장 인기가 많음.

2010년 Javascript 개발자를 위한 IDE를 목표로 설립됐으며, 2016년 AWS 에 인수

 

p.s.) cloud9 이라는 말은 '행복의 절정'이라는 뜻이다. ‘I'm on cloud nine’은 '더할 나위 없이 행복하다'는 뜻.

 

 

주요 특징

• 클라우드에서 사용하기 쉬운 클라우드 기반 IDE
• AWS 서비스 터미널을 직접 엑세스 가능
• AWS CodePipeline 구성을 통해 업데이트에 대한 빌드 자동화 기능
• 손쉬운 서버리스 애플리케이션 개발 지원
  • 내장형 Github과 내장형 Lambda BluePrint 지원
  • Lambda에 직접 배포하거나 Github에 업데이트 푸시 가능
  • 내장 SAM Local을 활용하여 로컬 환경에서 테스트, 디버깅 수행 가능

 

---

 

AWS CodeCommit 이란?

 

안전한 Git 기반의 리포지토리를 클라우드 기반으로 제공하는 완전 관리형 소스 제어 서비스 (분산형 버전 관리 시스템, 형상관리도구)

일반적인 애플리케이션 개발을 진행하면서 개발된 소스를 저장하고 제어할 수 있는 기능을 제공

AWS CLI 또는 SDK를 활용하여 리포지토리를 생성하고 Git을 통해 해당 리포지토리를 사용할 수 있음

HTTPS, SSH를 활용하여, 파일을 송수신할 수 있음. 소스 저장에 사용되는 리포지토리는 Key Management Service(KMS)를 사용해 데이터 암호화 가능

AWS IAM, CloudTrail, CloudWatch를 통해 누가,언제,어떻게,무엇을,어디서 접근했는지 모니터링 가능

 

 

 

 

Git 자격 증명을 사용한 AWS CodeCommit 설정

Git 자격 증명을 사용한 HTTPS 사용자

개발 도구(IDE)에서 연결

 

 

Git 자격 증명을 사용하지않고 AWS CodeCommit 접속

AWS CLI를 사용하지 않는 SSH 사용자

리눅스,macOS,유닉스에서 AWS CodeCommit 리포지토리

Windows에서 AWS CodeCommit 리포지토리 SSH 연결 설정

 

 

주요 특징

• 안전한 Git 기반 리포지토리를 호스팅하는 완전 관리형 소스 제어 서비스
• 뛰어난 확장성의 안전한 에코시스템으로 여러 팀이 협업하여 코드 작업 수행
• 자체 소스 제어 시스템 운영이나 인프라 확대/축소 불필요
• 소스코드에서 바이너리까지 모든 항목 안전하게 저장
• 기본 Git 도구와 원활하게 연동 가능

 

 

소스 관리 시스템이란?

 

 

 

 

CodeCommit의 동작 방식

 

 

---

 

 AWS CodeBuild 이란?

 

 

 

소프트웨어 개발에 필요한 소스코드를 컴파일하는 단계에서부터 테스트 후 소프트웨어 배포까지의 단계를 지원하는 완전 관리형 지속적 통합 서비스 (CI tool)

 

주요 기능

1. 코드에 대한 빌드와 테스트

2. 구성 설정

3. 지속적인 통합,배포 워크플로우

4. 빌드 프로세스에 대한 모니터링

 

 

단계	내용
Source Control	CodeCommit, Github, S3 등의 소스 관리 툴에서 데이터 불러오기
Build Project	Build Project는 CodeBuild에서 빌드 실행 방식 정의
Build Environment	CodeBuild가 Build Project를 사용하여 Build Environment 생성
S3 Bucket	Build Environment에서 Output을 Amazon S3 버킷에 업로드
Notifications	Amazon SNS, CodeBuild, Amazon CloudWatch Logs 빌드 정보전송
Destroy Build Environment	빌드 작업 완료 후 Build Environment 삭제 후 Clean Up 작업 수행

 

 

 

 

AWS 환경에서

젠킨스 vs. AWS CodeBuild

	젠킨스	AWS CodeBuild
Docker 이미지를 빌드할 수 있나?	✅	✅
도커 이미지 캐싱	✅(같은 호스트에서 실행 중인 경우)	❌
간단한 Docker 프로젝트 빌드하는 평균 시간	1분 8초	1분 59초
비용	구축 순간부터 하드웨어 비용 지속적 발생	사용하는 만큼 지불
간단한 설정	❌	✅
간단한 유지보수	❌	✅
코드 구성 옵션	CloudFormation, CDK + Jenkins Configuration as Code Plugin 필요	CloudFormation, CDK

 

---

 

AWS CodeDeploy 란?

 

다양한 컴퓨팅 서비스에 대해 소프트웨어 배포를 자동화하여 제공하는 완전 관리형 배포 서비스

AWS CodeDeploy는 지속적인 배포(Continuous Deployment)를 지원하는 대표적인 CD 도구

 

주요 기능

1. 자동화된 배포

2. 서비스 가동 중지 시간 최소화

3. 배포 서비스에 대한 모니터링

4. 손쉬운 서비스 확장

 

 

 

AWS CodeDeploy의 구성 요소

 

구분	내용
애플리케이션	배포할 응용 프로그램을 고유하게 식별하는 이름
컴퓨팅 플랫폼	AWS CodeDeploy가 애플리케이션을 배포하는 대상 플랫폼 ex) EC2/On-Premise 인스턴스, AWS Lambda, AWS ECS
애플리케이션 사양 파일	배포할 애플리케이션에 대한 정보를 지정하는 YAML 형식 또는 JSON 형식의 파일
배포 구성	배포 중 AWS CodeDeploy에서 사용하는 배포 규칙과 배포 성공 및 실패 조건 세트로 EC2/On-Premise 인스턴스의 최소 개수를 지정. Lambda 함수 버전으로 특정 트래픽이 라우팅되는 방식 (Canary, Linear, All-at-once) 지정 가능
배포 그룹	개별 인스턴스들의 세트로 배포 그룹에는 개별적으로 태그가 지정된 인스턴스 또는 Auto Scaling 그룹에 포함된 Amazon EC2 포함
배포 방식	배포를 수행하는 방식 1. 실행 중 배포를 수행하는 인플레이스(In-Place) 2. 대체 환경을 만들어 점진적인 배포를 수행하는 블루/그린(Blue/Green)
서비스 역할	AWS 리소스에 엑세스할 수 있는 권한을 지정하는 IAM 역할
IAM 프로파일	애플리케이션이 저장되는 공간(S3, Github Repo)에 엑세스할 때 필요한 권한 포함

 

• Canary: 트래픽이 2 증분씩 이동합니다. 나머지 트래픽이 두 번째 증분으로 이동하기 전에 첫 증분에서 업데이트된 Amazon ECS 작업 세트로 이동할 트래픽 비율 (%), 간격 (분) 을 지정하는 사전 정의된 Canary 옵션 중에서 선택할 수 있습니다.
• Linear: 트래픽이 동일한 증분으로 이동하며 각 증분 간에 시간(분)이 동일합니다. 각 증분에서 이동되는 트래픽 비율(%)과 각 증분 간의 시간(분)을 지정하는 사전 정의된 선형 옵션에서 선택할 수 있습니다.
• All-at-once: 모든 트래픽이 기존 Amazon ECS 작업 세트에서 업데이트된 Amazon ECS 작업 세트로 한 번 에 이동합니다.

 

 

In-Place 배포 방식

• 각 인스턴스의 애플리케이션에 대해 중지를 수행하고 애플리케이션 수정 버전(Revision) 설치를 진행한 후 유효성 검사를 수행하여 이상 유무를 확인
• 로드 밸런서에 배포를 진행하는 경우 배포 대상인 인스턴스를 로드 밸런스 서비스에서 제외한 후 배포 수행, 테스트 완료하고 로드 밸런스에 대상 인스턴스를 추가하여 서비스 수행
• 해당 방식으로는 Lambda에는 적용할 수 없음

 

 

 

 

 

Blue/Green 배포 방식

애플리케이션을 기존 환경에서 대체 환경으로 트래픽을 라우팅하며, 점진적으로 트래픽을 전환하고 최종적으로 배포된 서버가 이상이 없으면, 모든 트래픽에 대한 라우팅을 전환하고 기존 환경을 제거하는 배포 방식

 

 

Canary

신버전 배포 운영에 문제가 없는 것을 확인하면 점차적으로 증분 배포하는 방식

 

 

p.s.) 옛날, 광부들은 광산에 유독가스가 나오는 것을 알아채기 위해 유독가스에 민감한 카나리아를 키웠다고 한다.

카나리아가 죽으면 유독가스가 나오는 것으로 판단하고 조치를 취했다고 한다. 이 개념을 개발에서 사용하는 것이 카나리 테스트 방식

 

 

 

 

AWS CodeDeployment의 라이프사이클 이벤트

 

 

AppSpec.yaml 구성

AppSpec 파일은 다음과 같이 구성

version: 0.0
os: operating-system-name
files:
  source-destination-files-mappings
permissions:
  permissions-specifications
hooks:
  deployment-lifecycle-event-mappings

 

version (옵션)

AppSpec 파일의 버전을 지정합니다. 기본값은 0.0 

 

 

 

os

대상 Amazon EC2 인스턴스의 OS를 지정합니다. Amazon Linux 또는 Ubuntu Server의 경우 linux , Windows Server의 경우 windows 를 지정합니다.

 

 

 

files

CodeDeploy에서 EC2 인스턴스에 설치하는 파일 또는 디렉토리를 지정합니다. 응용 프로그램의 버전의 파일 또는 디렉토리를 인스턴스의 특정 위치에 복사합니다. source 와 destination 쌍으로 설정합니다. 복수 지정 가능합니다.

 

 

다음 예제에서는 config.txt 파일을 / webapps / Config 디렉토리에 source 디렉토리를 / webapps / myApp 디렉토리에 복사

files:
   - source: Config/config.txt
     destination: /webapps/Config
   - source: source
     destination: /webapps/myApp

 

 

permissions

files 섹션에 설명 된 파일에 어떤 권한을 적용할지 설정하는 부분입니다. 옵션이므로 설정하지 않아도 문제 없습니다. 현재는 Amazon Linux 또는 Ubuntu Server에만 적용(?)

 

object (필수)

권한을 적용 할 대상으로 복사 된 파일 또는 디렉토리를 지정합니다. 복수 지정 가능합니다.

pattern (옵션)

디렉토리에 있는 어떤 파일에 적용 할건지 패턴을 지정합니다. * 또는 pattern 가 지정되어 있지 않은 경우, 디렉토리 내의 모든 파일 디렉터리에 적용합니다.

except (옵션)

예외로 제외 할 파일 패턴을 지정합니다.

owner (옵션)

적용 할 파일 디렉토리의 소유자를 지정합니다. 지정하지 않으면, 원래의 파일 또는 디렉토리에 적용된 모든 기존 소유자가 유지됩니다.

group (옵션)

적용 할 파일 디렉토리의 소유 그룹을 지정합니다. 지정하지 않으면, 원래의 파일 또는 디렉토리에 적용된 모든 기존 그룹 소유자가 유지됩니다.

mode (옵션)

적용 할 파일 디렉토리 권한 모드를 정수로 지정합니다. 예를 들어 644 을 지정한 경우 소유자는 읽기, 쓰기 그룹 모든 사용자는 읽기 전용입니다. 지정되지 않은 경우, 원본 파일 또는 디렉토리에 적용된 권한 모드가 유지됩니다.

acls (옵션)

적용 할 파일 디렉토리 Access Control List (ACL)을 문자열로 지정합니다. 예를 들어 u : bob : rw 를 지정하는 경우 bob이라는 사용자에게 읽기 및 쓰기 권한을 부여합니다. 여러 ACL을 지정할 수 있습니다. 지정되지 않은 경우, 원본 파일 또는 디렉토리에 적용된 모든 기존 ACL이 유지됩니다. 또한 이들은 기존의 ACL을 바꿉니다.

context (옵션)

적용 할 파일 디렉토리 보안 컨텍스트를 지정합니다 (SELinux가 활성화되어 기계의 경우). user , type , range 를 SELinux의 정의에 따라 지정합니다. 지정되지 않은 경우, 원본 파일 또는 디렉토리에 적용된 보안 컨텍스트가 유지됩니다.

type (옵션)

적용 대상 파일 또는 디렉터리를 지정합니다. 파일의 경우 file , 디렉토리의 경우 directory 를 지정합니다. 지정하지 않으면 모든 파일 디렉토리가 포함됩니다.

 

 

hooks

배포 라이프 사이클 이벤트를 연결하고 연결 하나 이상의 스크립트를 지정합니다. hooks 섹션은 어떠한 처리를 추가하려는 경우에만 지정합니다.  후크 가능한 이벤트와 후크 불가능한 이벤트로 나눌 수 있습니다.

 

 

1. ApplicationStop - 이전 버전의 종료가 시작될 때 (후크 가능).
2. DownloadBundle - (후크 불가능).
3. BeforeInstall - AWS CodeDeploy이 files 섹션에 지정된 위치에 파일을 복사하기 전에 (후크 가능).
4. Install - AWS CodeDeploy이 files 섹션에 지정된 위치에 파일을 복사 할 때 (연결 불가능).
5. AfterInstall - AWS CodeDeploy이 files 섹션에 지정된 위치에 파일을 복사 한 후 (후크 가능).
6. ApplicationStart - 응용 프로그램의 버전이 시작하기 직전 (후크 가능).
7. ValidateService - 서비스 검증이 끝난 후 (후크 가능).

 

location (필수)

수행하려는 쉘 스크립트 파일의 위치를 ​​지정합니다.

timeout (옵션)

쉘 스크립트 실행시 제한 시간을 초 단위로 지정합니다. 지정된 시간을 초과 한 경우 배포 오류가 발생 처리가 중단됩니다. 기본값은 1800 초 (30 분)입니다.

runas (옵션)

쉘 스크립트를 실행할 사용자를 지정합니다. 기본값은 AWS CodeDeploy Agent를 실행하는 사용자입니다. AWS CodeDeploy 암호를 저장하지 않기 때문에 지정된 사용자 암호가 설정되어 있으면 배포 오류가 발생 처리가 중단됩니다. 이 옵션은 Amazon Linux 또는 Ubuntu Server 만 지정할 수 있습니다.

 

다음의 예에서는 AfterInstall (지정한 파일 디렉토리를 특정 디렉토리에 복사 한 후) 이벤트를 연결하고 RunResourceTests.sh 라는 쉘 스크립트 파일을 실행합니다. 제한 시간은 180 초로 지정되어 있기 때문에 처리가 3 분 이상 경과 한 후 배포 오류입니다.

hooks:
   AfterInstall:
     - location: Scripts/RunResourceTests.sh
       timeout: 180

---

AWS CodePipeline 이란?

 

애플리케이션, 인프라의 업데이트를 위한 릴리스 파이프라인을 자동화할 수 있도록 서비스 형태

코드에 변경이 있을 때마다 사용자가 사전에 정의한 릴리스 모델을 기반으로 애플리케이션의 릴리스 프로세스의 빌드, 테스트, 배포 단계에 걸친 프로세스에 대해 자동화를 수행

 

주요 기능

1. 지속적인 배포를 위한 워크플로우 모델링

2. AWS 서비스와의 통합

3. 타사 개발자 도구 및 사용자 지점 시스템과의 통합

4. 선언형 템플릿과 엑세스 제어

 

 

 

AWS CodePipeline의 구성 요소

 

 

구분	내용
파이프라인 (Pipeline)	S/W 변경 사항이 배포 프로세스의 적용 방법을 설명하는 워크플로우 구성
단계(Stage)	CodePipeline의 워크플로우를 구분하는 단위 단계는 파이프라인 당 최소2개 에서 최대 10개까지 생성 가능
작업(Action)	파이프라인 실행의 최소 단위로 '단계' 구성 시 정의한 대로 지정된 순서또는 연속, 병렬로 발생 단계 당 작업 수는 최소 1개에서 최대 50개
전환(Transition)	워크플로우의 한 단계에서 다음 단계로 이어지는 파이프라인 수행 절차
승인 작업(approval action)	권한이 부여될 때 까지 다음 작업으로 전환되는 것 방지 (승인 작업 유효 기간 : 7일)
실패(Failure)	단계의 작업이 성공적으로 완료되지 않고, 파이프라인 실행 단계의 다음작업으로 전환되지 않을 때 발생
아티팩트(Artifacts)	CodePipeline의 배포를 위한 작업 대상 파일 지칭 (산출물)

 

 

 

 

AWS CodePipeline 동작 방식

1. Request 단계

• 고객으로부터 기존 프로그램에 대한 변경 요청이나 수정 사항에 대한 요구사항을 수집하고, 이러한 아이디어 또는 버그 사항에 대한 처리 요청을 받음

 

2. Development 단계

• 고객의 요청사항에 대해 개발팀에서 버그에 대한 수정과 새로운 아이디어를 반영하여 프로그램에 대한 수정 변경 작업을 진행

 

3. Source 단계

• 개발자는 프로그램의 변경 사항에 대해 Git, AWS CodeCommit 등 소스 변경을 반영하기 위한 Commit을 수행하거나 업데이트를 수행

 

4. Build 단계

• 소스에 대한 Commit과 변경이 발생되면 AWS CodePipeline이 자동으로 변경 사항을 감지하고 소스로부터 아티펙트를 읽어와 AWS CodeBuild 를 통해 빌드를 수행하고, 테스트 환경에 구성되어 있는 경우 테스트를 수행

 

5. Staging 단계

• 스테이징 환경에서 테스트를 수행하기 위해 빌드된 코드를 스테이징 환경에 배포한 후 부하 테스트나 통합 테스트와 같은 추가 테스트를 수행

 

6. Production 단계

• 모든 테스트가 성공적으로 완료된 후 파이프라인에 추가된 수동 승인 작업을 통해 승인을 받고 나면 테스트가 완료된 코드를 운영 환경에 배포