Section 24. AWS CICD: CodeCommit, CodePipeline, CodeBuild, CodeDeploy - 1

지금까지 섹션 24까지 진행하면서 우리는
 AWS 리소스를 생성하고,
 AWS 프로그래밍 방식을 배우고,
 Beanstalk로 AWS에 코드를 배포하기도 하였다.

하지만 이 모든 작업을 수동으로 하였는데, 이런 경우에 실수가 발생할 수 있다.
우리는 이제 자동으로 AWS에 배포되는 방법을 배우고자 한다.

CICD

CICD에서 우리는 다음 사항들을 배울 것이다.

1. AWS CodeCommit | 코드를 저장
2. AWS CodePipeline | 코드에서 Elastic Beanstalk까지 파이프라인을 자동화
3. AWS CodeBuild | 코드를 빌드하고 테스트
4. AWS CodeDeploy | EC2 인스턴스에 코드를 배포
5. AWS CodeStar | 하나의 장소에서 소프트웨어 개발 활동들을 관리
6. AWS CodeArtifact | 소프트웨어 패키지들을 저장, 게시, 공유
7. AWS CodeGuru | 머신 러닝을 이용하여 자동화된 코드를 리뷰

이제 CICD가 무엇인지 배워보자.

Continuous Integration (CI)

• 지속적 통합이라는 의미로 중앙 코드 리포지토리에 자주 푸시한다는 의미이다.
• 푸시되는 즉시 테스트 or 빌드 서버가 이 코드를 확인한다.
• 우리는 조기에 버그를 발견하고 해결할 수 있다.
• 코드가 테스트되는 대로 제공되며, 자주 배포할 수 있다.

Continuous Delivery (CD)

• 지속적인 제공을 통해 푸시할 때마다 테스트를 거치기만 한다면, 어플리케이션 서버로 완료된 코드를 전송한다.
• 배포가 더 자주 발생하고, 신속히 이루어 지게 할 수 있다.
• 3개월마다 한 번씩 릴리즈해야 하는 고정관념에서 벗어날 수 있다.
• 오류가 발생할 수 있지만 이를 자동화하여 하루에도 다섯 번씩 릴리즈할 수 있도록 한다.

새로이 테스트 완료된 코드를 초록색으로 Application v2로 배포된다.

Technology Stack for CICD

• CICD의 전체적인 과정을 다시 살펴보자면 다음과 같다.

---

AWS CodeCommit

• CodeCommit을 알기 전에 먼저 "버전 관리"의 개념부터 알아보자.
• 버전 관리는 시간에 걸쳐 코드에 발생한 다양한 변화들을 이해하고 롤백할 수 있는 기능이다.
  • 이를 통해 과거에 어떤 작업이 수행되었고, 어떤 코드를 누가 커밋했고, 제거 및 변경된 사항은 무엇인지 등등 여러가지 상황들을 한눈에 볼 수 있다!
  • 이미 우리가 아는 Git이 대중적인 버전 관리 기능을 수행한다.
• Git repository가 중앙 온라인 리포지토리일 때의 이점을 알아보자.
  • 많은 개발자가 동시에 작업할 수 있다.
  • 코드가 백업 된다.
  • 코드 작업에 대해 어떤 이가 무엇을 커밋했는지 볼 수 있으며 되돌릴 수도 있다.

❓CodeCommit을 사용하는 이유❓

• Git Repository는 비쌀 수 있다.
  • Github, GitLab, Bitbucket 등 제 3자 서비스가 이에 포함된다.
• AWS CodeCommit을 사용하면 다음과 같은 이점이 존재한다.
  • 코드가 AWS 클라우드의 개인 VPC 내에 있어서 개인 Git 리포지토리가 있는 것과 같다.
  • 원하는 경우 코드를 기가 크기까지 확장할 수 있다!
  • 완전 관리형에 고가용성이기에 좋다!
  • 오직 AWS 계정 내에만 저장된다. 이는 보안이 높다는 것을 의미한다.
  • 암호화와 IAM을 이용한 액세스 제어로 보안이 강화되어 있다!

🔐 Security

• 표준 git를 사용할 수 있다.
• 인증 방식
  • SSH Keys | AWS 사용자들을 IAM 콘솔에서 SSH 키를 설정하여 Git 리포지토리에 접근할 수 있다.
  • HTTPS | IAM 사용자들을 위한 Git Credentials를 사용하여 접근할 수 있다.
• 권한 부여
  • IAM 정책을 이용하여 사용자와 특정 리포지토리에 대한 권한을 관리할 수 있다.
• 암호화
  • 리포지토리들은 AWS KMS를 사용해서 자동으로 암호화된다.
  • 안전한 HTTPS나 SSH 프로토콜을 사용하여 암호화된 채로 전송된다.
• Cross-account Access
  • SSH 키나 AWS credentials를 공유하면 안된다.
  • AWS 계정 내에 IAM 역할을 사용하고 AWS STS나 AssumeRoleAPI를 이용한다.

CodeCommit vs. GitHub

---

AWS CodePipeline

Pipeline은 CICD를 조율하는 워크플로우이다.
특징은 다음과 같다.
1. 계획을 세울 수도 있고 소스를 선택할 수 있다.
2. 빌드 단계로 이동하여 코드를 빌드할 수도 있다.(ex. CodeBuild, Jenkins, CloudBees, TeamCity)
3. 테스트를 할 수 있다.(ex. CodeBuild, AWS Device Farm, 3rd party)
4. 배포를 할 수 있다.(ex. CodeDeploy, Elastic Beanstalk, CloudFormation, ECS, S3..)
5. 람다 함수 등을 호출할 수 있다.

CodePipeline은 각 스테이지를 통해 병렬적 동작과 연속적인 동작을 할 수 있다.
그 예시로 Build -> Test -> Deploy -> Load Testing 같은 과정을 연속으로 처리할 수 있다.

 

CodePipeline의 구조는 다음과 같다.

이 구조로 인해 높은 유연성을 가진다.

CodePipeline의 Artifact를 살펴보자.

• 각 파이프라인 스테이지는 아티팩트를 생성하며,
  아티팩트는 S3 버킷에 저장되어 다음 스테이지로 이동한다.

각 아티팩트가 동작을 수행하고 다음 단계로 이동한다!

CodePipeline - Troubleshooting

• CodePipeline의 모든 사항들을 확인해야 한다면, 우리는 파이프라인, 액션, 단계 실행 상태 변화 등을 확인할 필요가 있다.
• 이때 우리는 CloudWatch Events를 사용하여 이를 확인할 수 있다.
• 만일 CodePipeline이 어떠한 스테이지에서 실패하게 된다면, 파이프라인은 멈추고, 콘솔에서 이에 대한 정보를 얻을 수 있다.
• 만일 CodePipeline이 어떠한 액션을 수행할 수 없게 되면, IAM Service Role을 확인하여 충분한 IAM 권한을 갖고 있는지 확인할 수 있다.

---

AWS CodeBuild

CodeBuild는 다음과 같은 성분들을 사용한다.
Source - CodeCommit, S3, Bitbucket, Github
Build instructions: 소스 안에 빌드 지침이 있다.(buildspec.yml)
출력 로그는 나중을 위해 S3나 CloudWatch logs에 저장될 수 있다.
Metrics를 통해 지표를 확인 및 빌드 통계를 볼 수도 있고, EventBridge 빌드 실패와 트리거 알림을 감지할 수 있다.

CodeBuild - Supported Environments

• Java, Ruby, Python, Go, Node.js 등 여러 어플리케이션을 지원한다.
• Docker 이미지를 확장하여 원하는 언어를 테스트 할 수도 있다.

S3 Bucket을 이용하여 파일들을 재사용할 수 있다!

CodeBuild - buildspec.yml

• buildspec.yml은 최상단에 위치해야 하는 파일이며, 환경 변수를 정의할 수 있다.
  • variables | plaintext 변수
  • parameter-store | SSM 파라이터 스토어에 저장된 변수
  • secrets-manager | Secrets Manager에 저장된 변수
• phases는 CodeBuild가 무엇을 할 지 정의한다.
• artifacts는 Docker 컨테이너에서 추출되어 Amazon S3로 보내지는 파일이며, 암호화된다.
• cache는 빌드 속도를 올리기 위해 S3에 캐싱될 파일이나 의존성들을 의미한다.