Udemy AWS-DOP course (1) SDLS 자동화 : CodeCommit, CodePipeline

CKA 자격증을 따서 이참에 AWS-DOP 자격증도 준비하는 중이다. (CKA 합격 후기는 추후 업로드 예정!)

강의 링크 : https://www.udemy.com/course/aws-certified-devops-engineer-professional-hands-on/

 - 비용도 비싸지 않고 실습파트들도 있어서 직접 강의를 수강하는것도 추천! 

 

[AWS CICD]

AWS CodeCommit - storing our code

AWS CodePipeline - automating ourt pipeline from code to Elastic Beanstalk

AWS CodeBuild - building and testing our code

AWS CodeDeploy - deploying the code to EC2 instances (not Elastic Beanstalk)

AWS CodeStar - manage software develpment activities in one place

AWS CodeArtifact - store, publish, and share software packages

AWS CodeGuru - automated code reviews using Machine Learning

 

[CI : 지속적 통합]

개발자가 코드저장소 (ex.GitHub, CodeCommit, Bitbucket...)에 코드를 push

빌드서버(ex. CodeBuild(AWS), Jenkins CI..)는 코드 저장소의 해당 코드가 정상적으로 동작하는지 확인

빌드 서버가 코드를 가져가 테스트하고 나면 개발자는 빌드 및 테스트 결과를 피드백 받음

 

[CD: 지속적 배포]

빌드 및 테스트가 통과되면 빌드서버가 애플리케이션을 애플리케이션 서버(v1)에 배포

다시 코드를 푸시하면 코드 저장소에 새로운 코드 버전이 생김 -> 애플리케이션 서버(v2) 생성

배포 자동화 도구 : CodeDeploy(AWS), Jenkins CD, Spinnaker 등

 

[CICD 기술 스택 - AWS]

1. Code - AWS CodeCommit, GitHub, Bitbucket or 3rd party tool
2. Build & Test - AWS CodeBuild, Jenkins CI or 3rd party tool
3. Deploy - AWS CodeDeploy(EC2 Instance, On-premises Instances, AWS Lambda, Amazone ECS로 배포)
4. Provision(선택) - AWS Elastic Beanstalk(Deploy & Provision)
5. Orchestration - AWS CodePipeline (위의 CICD 진행에 필요한 설정을 정의)

----------------------------------------------------------------------------------------------------------------------

 

[CodeCommit]

• 버전 관리(Version control) : 시간이 지나며 코드에 생긴 다양한 변화(누가 코드를 commit 했는지, 무엇을 수정했는지 등)를 파악하고 롤백
• 도구 : AWS CodeCommit (AWS VPC 내 Private Git repo, 사이즈 제한 없음, 완전관리형, 고가용성, 코드는 오직 AWS 클라우드 상에만 존재, 암호화 및 접근제어(IAM) 등을 통한 보안기능)
• Security : 표준 Git 명령줄을 사용해 상호작용
  • 인증(Authentication)
    • SSH keys : 사용자 인증단계에서 SSH key 적용 가능(root계정일 경우 X)
    • HTTPS : HTTPS를 사용해 일반적인 로그인 방법을 사용해 저장소에 접속
  • 권한 부여(Authorization)
    • IAM 정책을 사용해 특정 저장소에 대한 사용자 및 역할의 권한 관리 가능
  • 암호화(Encryption)
    • 모든 코드가 자동적으로 KMS 방식으로 암호화
    • 코드가 CodeCommit에 푸시되는 동안에는 전송 중 보안이 적용됨 (HTTPS or SSH 프로토콜 or both)
  • 교차 계정 액세스(Cross-account Access)
    • SSH key나 자격증명을 다른 사람과 공유 불가
    • 계정에서 IAM 역할을 생성 -> AWS STS의 AssumeRole API를 사용해 CodeCommit 저장소에 대한 액세스 권한을 얻어야 가능

•  

[실습1]

Developer Tools > CodeCommit > Repositories

• Code > 저장소에 파일 업로드하면 오른쪽 상단에 View commit: [커밋 ID] (해당 ID는 Git 내에서만 유효)
• Pull request > 특정 브랜치의 변경 사항을 다른 브랜치에 병합 (특정 브랜치의 내용을 메인 브랜치로 병합)
• Commit > 커밋 history 확인 / 커밋 시각화, 커밋 비교 가능
• Branches > 브랜치 확인 / 브랜치 추가 가능
• Settings > General(repo name, repo ID, repo ARN) , *Notification(코드 저장소를 위한 알림 규칙 생성) , Trigger(트리거 생성)
  • <Notification trigger notifications>
    • Comments : On commits, On pull requests
    • Approvals: Status changed, Rule override
    • Pull request : Source updated, Created, Status changed, Merged
    • Branches and tags : Created, Deleted, Updated
  • <Notification Target>
    • type : SNS topic, AWS Chatbot (Slack)
  • <Trigger Service>
    • service : Amazone SNS, AWS Lambda

 

[실습2]

IAM > Users > Security credentials

• SSH keys for AWS CodeCommit : 보유한 SSH key를 올리면 Git에 자동으로 연결됨 (CodeCommit 저장소에서 Clone SSH 버튼을 통해 복제 가능)
• HTTPS Git credentials for AWS CodeCommit : 최대 2개의 User name과 Password 생성 가능 / Clone HTTPS 버튼을 통해 URL 복제 후 git clone 진행

 

[추가 정보]

<EventBridge> : CodeCommit 이벤트를 실시간 모니터링 할 수 있음.

• pullRequestCreate, pullRequestStatusChanged, referenceCreated, commentOnCommitCreate 등의 이벤트를 EventBridge에서 처리 가능
• 자동화 수단으로 활용 가능 : 이벤트를 EventBridge로 받아 SNS, Lambda, CodePipeline을 호출할 수 있음

 

<Migrate Git Repository to CodeCommit>

1. CodeCommit Repository 생성
2. git clone을 통해 Git 저장소의 모든 프로젝트 파일을 local에 저장
3. 해당 프로젝트를 CodeCommit repo에 push

 

<Cross-Region Replication> (글로벌 개발자 or 저장소 백업 등의 경우)

ex. us-east-1의 저장소를 eu-west-2에 복제하는 경우

1. 개발자가 기존 브랜치에 push 하거나 브랜치를 생성/삭제
2. CodeCommit이 해당 이벤트를 EventBridge에 전달 (referenceCreated or referenceUpdated)
3. EventBridge는 ECS Task 같은 작업을 invoke
4. ECS Task는 us-east-1 저장소로 git clone 명령 수행
5. 그다음 eu-west-2에 있는 저장소에 git remote 진행

 

<Branch Security>

• 어떤 사용자에게 CodeCommit 저장소에 대한 push 권한을 주면 해당 사용자는 모든 브랜치에 push 가능
• 특정 브랜치에만 push할 수 있게 제한하려면 사용자 자체를 제한해야 함 - IAM Policy
• ex. 저장소에 Prod, Stag, Dev 브랜치가 있고 시니어 개발자만 Prod 브랜치에 코드를 Push할 수 있어야 함
  • 주니어 개발자는 Prod 브랜치에 push하는 것을 제한하는 IAM 정책 생성
  • 현재는 IAM 정책을 직접 CodeCommit 연결하는 것은 지원하지 않음 (사용자 or 그룹 Level만 조정 가능)

 

<Pull Request Approval Rules>

- 승인 규칙은 Pull Request(병합)되기 전에 특정 수의 사람들이 코드를 검토한 후 승인하게 하여 코드 품질을 보장할 수 있게 함

- 승인할 사용자 pool을 지정, PR을 승인하는데 필요한 사람의 수를 지정, 승인하는 사람을 지정하려면 IAM Principal 요소의 ARN(IAM users, federated user, IAM Roles, IAM Groups) 지정

- 모든 pull 요청에 대해 승인규칙을 자동적으로 생성하려면 template을 사용하여 특정 브랜치로 들어오는 모든 풀 요청에 승인 규칙을 적용하도록 정의

 

----------------------------------------------------------------------------------------------------------------------

 

[CodePipeline] : AWS에서 CICD와 관련된 동작을 오케스트레이션하는 시각적 업무 도구

• Source : CodeCommit, ECR, S3 Bitbucket, GitHub
• Build : CodeBuild, Jenkins, CloudBees, TeamCity
• Test : CodeBuild, AWS Device Farm, 3rd party tools
• Deploy : CodeDeploy, Elastic Beanstalk, CloudFormation, ECS, S3
• Invoke : Lambda, Step Functions

 

[Artifacts]

• 모든 파이프라인은 아티팩트를 생성할 수 있음(모든 아티팩트는 파이프라인 외부에 생성됨)
• 생성된 아티팩트는 S3에 저장되어 다음단계로 전달됨 (CodePipeline 내에서 CodeCommit이 직접 CodeBuild로 넘기지 않아도 됨)

 

[Troubleshooting]

• pipeline, action, stage 상태를 확인하려면 CloudWatch Events(Amazon EventBridge)를 사용
  • Ex. failed pipeline, cancelled stages 등의 event가 생기면 이메일 알림 등이 오도록 설정

• pipeline 진행 중 문제가 생기면 콘솔을 통해서 시각적으로 확인 가능
  • Ex. CodeBuild에서 코드를 실행하지 못하거나 코드를 가져오기 못할 경우 Codepipeline의 IAM 서비스 역할을 확인 > 적절한 권한 부여
• 인프라 내부에서 거부된 API 호출이 있는지 확인해야 하는 경우 CloudTrail을 사용

 

[실습1]

Developer Tools > CodePipeline > Pipelines > Create new Pipeline

• Choose pipeline setting
  • Service Role : IAM 역할 연결
  • Encryption key
  • Advanced settings
• Add source stage
  • Source Provider 선택
  • Codecommit을 추적방법 선택 가능 : CloudWatch Events(권장), CodePipeline
  • Output artifact format
• Add build stage(선택 사항)
• Add deploy stage
  • CloudFormation, CodeDeploy, Elastic Beanstalk, Service Catalog, ECS, ECS(Blue/Green), S3
• pipeline edit을 통해 stage 추가 가능(Add stage)
  • Add action group (Action name, Action Provider)
  • Action Provider로 Manual Approval 선택 가능 - 수동 승인이 있을 때만 실행되도록
  • *시험 문제 : Stage가 여러 action group을 가질 수 있는지 : yes
  • action group 순차/병렬 작업 지정 가능

 

[추가 정보]

Events vs Webhooks vs Polling

• 파이프라인을 시작하는 방법에는 Events, webhooks, polling
• Events는 CodePipeline에서 가장 선호되는 방법으로 이벤트가 있을 때마다 CodePipeline 실행
  • EventBridge로 이벤트가 넘어오면 CodePipeline 실행(trigger)
  • GitHub로 Events를 구성하려면 CodeStar Source Connetcion(GitHub App) 사용
• Webhooks (구식 CodePipeline 실행방법)
  • CodePipeline을 HTTP 엔드포인트에 노출 > 해당 엔드포인트를 스크립트로 실행
• Polling(CodePipeline이 소스를 폴링 / 권장하진 않음-비효율적)

 

*Manual Approval Stage

• 동작 방식
  • 파이프라인에서 Manual Approval 을 추가하는 경우 Owner=AWS, Action=Manual
  • 수동 승인 단계에 도달하면 SNS topic을 실행(trigger)시키고 이를 통해 사용자(IAM사용자)에게 이메일 전송
  • 이때 사용자에게는 2개의 권한이 필요함 : GetPipeline*, PutApprovalResult

 

[CloudFormation]

CloudFormation Deploy Action을 사용하면 모든 종류의 AWS 자원을 배포할 수 있음(Lambda 함수 포함 - CKD 프레임워크나 SAM으로도 사용 가능)

• CodeCommit(template) -> CloudFormation(Create Change Set) -> Manual Approval -> CloudFormation(Execute Change Set)
• 특정 리전의 CloudFormation 뿐만 아니라 CloudFormation StackSets를 사용해 여러 AWS 계정과 AWS 리전에 배포 가능
• 다양항 설정 변경 가능 - Stack name, Change Set name, template, parameters, IAM Role, Action Mode 등

 

 

[CloudFormation Intergration]

1. CodeBuild (Build app) -> CloudFormation (Deploy Infra & app)
2. CloudFormation (CREATE_UPDATE) -> CloudFormation Stack(create an existing stack)
3. CodeBuild Test (Test app) -> CloudFormation Stack(HTTP Test Suite)
4. CloudFormation(DELETE_ONLY) -> CloudFormation Stack(delete a stack if it exits)
5. CloudFormation(CREATE_UPATE) -> update an existing stack(deploy to production)

 

[CloudFormation as a Target]

• Action Modes
  • Create or Replace a Change Set, Execute a Change Set
  • 승인 단계를 거치고 싶지 않다면 스택으로 관리 : Create or Update a Stack, Delete a Stack, Replace a Falied Stack
• Template Paramete Overrides(템플릿 매개변수 재정의) : 파이프라인을 사용해 런타임에 매개변수를 오버라이드 할 수 있음
  • JSON 객체를 만들어 매개변수 값 재정의, 해당 객체를 파이프라인 Input Artifact에 포함 가능
  • 모든 매개변수가 템플릿에 포함되어야 하며 static 오버라이드 방식(권장)을 써서 템플릿 구성 파일을 사용하거나 dynamic 방식을 써서 템플릿을 넘겨받아도 됨

 

 

[모범사례]

1. 하나의 CodePipeline, 하나의 CodeDeploy, 여러개의 Deployment group에 병렬 배포
2. RunOrder을 사용하여 병렬 작업 (ex. RunOrder값을 동일하게 지정하여 CodeCommit에서 CodeBuild가 병렬로 실행되게 할 수 있음 : 해당 작업은 여러 리전에 배포하는 경우 등에 활용 가능)
3. prod 환경에 배포하기 전 pre-prod에 배포

 

 

[EventBridge]

• EventBridge는 모든 이벤트를 감지할 수 있는데 모든 실행 상태의 변화를 감지하여 실행이 중지된 것도 감지함.
• ex. CodeBuild에서 실행 실패가 감지되면 EventBridge가 동작을 인터셉트하여 Lambda 함수 같은 것을 실행해 코드를 진단하거나 SNS 알림 호출

 

[Invoke Action]

• CodePipeline에서 API 호출을 실행하는데 가장 좋은 방법은 Invoke(호출)
• Lambda 함수를 호출하면 그 안에서 원하는 코드를 무엇이든 실행 가능하며 REST API 호출도 가능 (CodePipeline에서 API를 바로 호출할 수 없음)
• Step 함수 : ex) 파이프라인에서 State Machine을 실행시키고 step 함수를 통해 DynamoDB 테이블에 아이템을 삽입하거나 ECS Task를 실행해 작업 처리 상황 확인 가능

 

 

[Multi Region]

• 파이프라인의 일부 또는 대부분의 작업은 서로 다른 리전에 존재할 수 있음
• *CodePipeline을 위한 S3 Artifact 스토어를 작업이 존재하는 모든 리전에 정의해야 함(콘솔을 사용하여 파이프라인 생성 시에는 아티팩트 버킷 생성 단계가 있으나 CLI나 SDK를 사용해 파이프라인을 생성시에는 아티팩트 버킷을 미리 생성하여 파이프라인에 적절한 권한을 부여해야 함)
• 교차 리전 작업을 수행할 때 원하는 입력 아티팩트를 참조하면 CodePipeline이 이를 자동으로 한쪽 리전에서 다른 리전으로 복사