Udemy AWS-DOP course (2) SDLS 자동화 : CodeBuild, CodeDeploy

[CodeBuild]

• Source : CodeCommit, S3, Bitbucket, GitGub
• Build instructions(빌드 명령) : Code file *buildspec.yaml(소스코드 루트에 둬야함) or 콘솔을 통해서도 가능
• 애플리케이션이 빌드되면 Output logs가 S3에 저장되고 CloudWatch Logs로 분석이 가능
• CloudWatch Metrics로 빌드 지표 모니터링 가능
• EventBridge로 빌드 실패를 감지해 알림 트리거를 발생시킬 수 있음
• CloudWatch Alarms은 실패 횟수가 많은 경우에 사용할 수 있음
• Build Project는 CodeBuild, CodePipeline에서 정의할 수 있으며 파이프라인에서 CodeBuild 빌드 프로젝트를 호출할 수도 있음

 

[Supported Environments]

• Java, Ruby, Python, Go, Node.js, Android, .NET Core, PHP
• 다른 언어를 원한다면 Docker환경에서 사용 가능

 

 

[작동 방식]

1. CodeCommit (Source code + buildspec.yaml)
2. CodeBuild에서 코드를 가져와 자체적으로 컨테이너를 생성(buildspec.yml의 모든 명령 실행) - 빌드 환경 구성
3. CodeBuild는 해당 컨테이너를 빌드하기 위한 Docker image를 가져옴 (AWS에서 미리 패키징한 이미지를 써도되고 별도의 도커 이미지 사용 가능)
4. 컨테이너에서 buildspec.yml의 모든 명령을 실행하는데 이때 S3 버킷의 파일 캐시 기능 사용 가능(빌드에  자주 쓰이는 파일 캐시) - 선택사항
5. 로그 옵션을 활성화하면 모든 로그가 CloudWatch Logs와 S3에 저장됨
6. CodeBuild에서 코드를 빌드하거나 테스트하는 작업이 끝나면 Artifact 생성됨 - 해당 아티팩트에서 최종 결과물을 확인할 수 있음

 

 

[buildspec.yml]

• *해당 파일은 루트에 있어야 함(소스코드 디렉토리 최상단)
• env : buildspec.yml을 실행하는데 필요한 환경 규칙 정의
  • variables(일반 텍스트), parameters-store(SSM 파라미터 스토어 변수), secret-manager(AWS secret manager)
• phases : CodeBuild가 수행해야 할 작업 정의
  • install : 사전 패키지를 설치하는데 필요한 명령어 목록 등 정의
  • pre_build : 실제 빌드 전에 실행할 명령들 정의
  • Build : 실제 빌드 명령
  • post_build : 빌드가 끝난 뒤 결과를 압축 파일로 만드는 등의 작업 (ex. zip output)
• artifacts : 도커 컨테이너에서 추출하여 S3로 보낼 파일을 명시 (encrypted with KMS)
• cache : 빌드 속도 향상을 위해 S3에 캐시할 파일 및 의존성 목록 정의

 

 

[Local Build]

• CodeBuild는 클라우드에서 실행되지만 로컬 데스크톱에서도 CodeBuild 실행 가능
• 먼저 Docker를 설치하고 CodeBuild 에이전트에서 가이드에 따라 실행

 

[Inside VPC]

• CodeBuild를 VPC 내에서 실행할 수도 있음 (기본적으로 CodeBuild는 VPC 외부에서 실행됨 - VPC 내부 리소스에는 액세스 불가)
• VPC ID, Subnet IDs, Security Group IDs를 설정할 수 있고 이를 통해 CodeBuild 컨테이너가 VPC 내부에 있는 RDS, ElasticCache, EC2, ALB 등의 리소스에 접근 가능
• VPC 내부에 CodeBuild를 두는 목적 : 통합 테스트 수행, 데이터 쿼리, 내부 로드밸런서와의 통신 등

 

 

[실습1] - CodeBuild에서 코드 테스트 (Congratulation 문구가 뜨는지 테스트)

• Source Provider : CodeCommit, GitHub, Bitbucket, GitHub Enterprise
• 브랜치 선택에서 Commit ID를 따로 넣지 않으면 브랜치의 최신버전을 테스트
• Environment image에서 Managed image를 선택하면 AWS가 특정 프로그래밍 언어를 테스트하기 위해 준비해둔 이미지를 사용
• Operating system으로는 Ubuntu 사용 권장
• Additional configuration에서 VPC 설정 가능
• *Buildspec에서 파일 or 명령문 선택 가능 (파일 이름 지정은 선택사항으로 기본적으로 buildspec.yml 이름으로 찾음)
• Arfitact 및 Logs 옵션 사용 가능
• 빌드를 시작하고 에러가 날 경우 Phase details에서 에러 사항 자세히 확인 가능(Duration도 확인 가능해서 timeout으로 에러가 뜨는 경우 어디에서 시간이 오래 걸렸는지도 확인 가능)

 

 

[실습2] - buildspec.yml 파일 CodeCommit에 upload

version: 0.2

 

phases: 

    install:

        runtime-versions:

            nodejs: latest

        commands:

            - echo "installing something"

    pre_build:

        commands: 

            - echo "we are in the pre build phase"

    build:

        commands:

            - echo "we are in the build block"

            - echo "we will run some tests"

            - grep -Fq "Congratulations"index.html

    post_build:

        commands:

            - echo "we are in the post build phase"

            

 

> 해당 commands들은 CloudWatch에서 확인 가능

 

 

 

[Environment Variables]

CodeBuild 프로젝트에는 런타임에 쓸 수 있는 변수들이 있음

- Default 환경변수 : 빌드가 일어날 때 마다 AWS가 정의하여 제공하는 것으로 AWS_DEFAULT_REGION, CODEBUIL_BUILD_ARN, CODEBILD_BUILD_ID, CODEBUILD_BUILD_IMAGE 등의 빌드 관련 메타데이터가 포함되어 있음

- Custom 환경변수 :

• Static : 빌드 시점에 정의되는 변수로 빌드 대상환경 등을 정의하는데 사용됨. 해당 변수의 값은 start-build API를 호출해 재정의 가능
• Dynamic : SSM 파라미터 스토어 또는 Secret Manager에서 환경변수의 값을 동적으로 가져옴. (ex. 보안암호의 경우 정적으로 넘길 수 없기 때문에 CodeBuild 런타임 때 Secret Manager에서 직접 암호를 가져올 수 있도록 함)

 

 

[Security]

• CodeBuild Service Role : AWS 리소스에 액세스할 때 Service Role을 통해 권한을 부여
• 사례 : CodeCommit에서 코드 다운로드, SSM 파라미터 스토어에서 파라미터 가져오기, S3 버킷에 Artifact 업로드, Secret Manager에서 암호 가져오기, CloudWatch에 로그 저장

 

 

[Build Badges]

 - passing, failing 표시

 - 동적으로 생성되며 CodeBuild의 최신 빌드 상태를 반영

 - 프로젝트의 public URL에 접속 가능

 - CodeCommit, GitHub, Bitbucket에서 지원

 - *브랜치 Level에서 제공

 

 

[Trigger]

1. CodeCommit -> EventBridge -> CodeBuild
2. CodeCommit -> EventBridge -> Lambda -> CodeBuild
3. GitHub -> WebHook -> CodeBuild

 

 

[Validata Pull Request]

 - CodeCommit에서 PR을 검증하는데 사용할 수 있음

 - ex) create/update PR -> CodeCommit -> EventBridge -> CodeBuild(test) -> EventBridge -> Lambda -> CodeCommit -> Merge

 

[Test Reports]

• CodeBuild UI에서 수행한 테스트에 대한 보고서를 바로 확인할 수 있음
• 빌드 과정 중 수행하는 테스트의 세부 정보가 담겨 있음
• 테스트 종류를 가리지 않기 때문에 Unit test(단위 테스트), configuration test(설정 테스트), functional test(기능 테스트)에서 보고서 생성 가능
• CodeBuild에서 인식 가능한 파일 포맷 : JUnit XML, NUnit XML, NUit3 XML, Cucumber JSON, TestNG XML, Visual Studio TRX
• 보고서를 생성하기 위해서는 buildspec.yml에 Report Group을 추가하고 그 안에 보고서에 해당하는 파일의 위치를 지정해야 함

 

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

 

[CodeDeploy]

• Deployment 서비스는 애플리케이션 배포를 자동화해주는 것으로 애플리케이션 버전을 v1에서 v2로 업그레이드 하는 경우 EC2 인스턴스(or온프레미스 서버), Lambda gkatn, ECS 서버 3가지에 배포할 수 있다.
• CodeDeploy로 애플리케이션을 업데이트할 수 있을 뿐만 아니라 롤백도 가능하다. (deployment를 실패하거나 CloudWatch 알람 경보가 발생하면 자동적으로 롤백)
• 애플리케이션 배포 속도를 조절할 수 있다. (ex. 인스턴스를 한번에 하나씩 배포 or 한번에 배포 or 절반만 배포 or blue-green)
• CodeDeploy를 제어하는데는 'appspec.yml'이라는 파일을 사용한다. 해당 파일을 통해 배포 진행 방식을 정의할 수 있다.

 

 

[EC2/On-premises Platform]

- CodeDeploy를 사용하면 EC2 인스턴스와 온프레미스 서버에 배포할 수 있다.

- 배포방식 : in-place deployments , blue/green deployments

- 대상 인스턴스에 CodeDeploy Agent가 필수적으로 배포되어야 함.

- 배포 속도 조절 가능 (AllAtOnce, HalfAtATime, OneAtAtime, Custom)

 

 

[In-place Deployment]

• Half At A Time : 4개의 인스턴스에서 v1을 실행하고 있는 경우, 에이전트가 두 인스턴스의 애플리케이션을 멈추고 v2로 업그레이드함. 업그레이드가 끝나면 나머지 절반의 가동이 중단되고 v2로 업그레이드됨.
• blue/green : 앞단의 ALB가 모든 인스턴스를 가리키고 있고 해당 인스턴스들은 오토스케일링 그룹(v1)에 있는 경우, 추가로 오토스케일링 그룹을 생성함(v2). CodeDeploy는 새로 추가된 오토스케일링 그룹에 최대한 많은 인스턴스를 생성하고 v1과 v2가 병렬로 실행됨. ALB 별도 설정을 거친 후 ALB가 v2 오토스케일링그룹을 가리키게 되면 v1은 가동을 멈춤

 

 

[CodeDeploy Agent]

• EC2 인스턴스에 수동으로 설치도 가능하며 자동화 방식으로 설치도 가능
• EC2 인스턴가 Systems Manager로 관리되고 있다면 에이전트 설치를 자동화할 수 있음
• 에이전트를 설치했다면 IAM 권한을 부여해 S3에 액세스해야 함(S3에 애플리케이션 개정 버전 저장되어있음)

 

 

[Lambda Platform]

• CodeDeploy를 사용해 Lambda alias 트래픽 이동을 자동화시킬 수 있음('Prod'별칭 하에서 v1의 트래픽을 v2로 이동) : SAM 프레임워크에 내재된 기능
• Linear(선형) 방식 : CodeDeploy가 v2로의 트래픽이 100%로가 될때까지 N분마다 트래픽을 증가시킴
• Canary(카나리) 방식 : v2로 소량의 트래픽만 전송하다가 한 번에 100%로 전환하는 방식
• AllAtOnce : v2로 바로 트래픽을 넘김

 

 

 

[ECS Plaform]

 - ECS 작업 정의 배포를 자동화시킬 수 있으며 오직 blue/green 배포만 사용 가능함

- ECS 클러스터 내 새로운 대상그룹으로 v2 버전의 애플리케이션이 있으며 CodeDeploy는 로드밸런서로 명령을 보내 트래픽을 redirect 하여 블루그룹(v1)에서 그린그룹(v2)으로 보내도록 함.

- Linear, Canary, AllAtOnce 방식이 있음

 

 

 

[In-place Deployments - EC2]

- In-Place 배포를 수행하는 방법에는 EC2 태그 or ASG(Auto Scaling Group) 인스턴스를 식별하는 방법이 있다.

- ex. ProjectName 값이 FinanceApp인 인스턴스를 v1에서 v2로 업그레이드

- ex. 특정 ASG에 속한 모든 인스턴스를 v1에서 v2로 업그레이드

- 오토스케일링 그룹을 사용하면 오토스케일링 그룹에 새로운 인스턴스가 추가되었을 때 CodeDeploy가 알아서 해당 EC2 인스턴스에 새 애플리케이션 버전을 배포한다.

- 환경 구성에 로드밸런서가 포함된 경우라면 EC2인스턴스가 업데이트 되기 전 해당 인스턴스러 가는 트래픽이 중단되고 업데이트가 완료된 뒤 다시 트래픽 전송이 시작됨

 

 

 

[In-place Deployment - Hooks]

- EC2 인스턴스를 업데이트할 때는 '배포 후크'라는 것을 사용하는데 후크는 업데이트 주기 동안 실행되는 스크립트이다.

- 업데이트 lifecycle (파란색의 경우 hooks(스크립트) 실행 가능한 상태 , 파란색이 아닌 경우 CodeDeploy 에이전트에 의해 수행됨)

1. Start
2. [LB를 사용하는 경우] : BeforeBlockTraffic -> BlockTraffic -> AfterBlockTraffic
3. ApplicationStop (애플리케이션을 중단하는 스크립트 실행)
4. DownloadBundle (S3 같은 곳에서 번들을 다운로드)
5. BeforeInstall (파일권한을 변경하는 등 기타작업 마무리)
6. Install
7. AfterInstall (설치가 끝난 뒤 스크립트로 무언가를 확인하거나 파일 권한 다시 변경 등)
8. ApplicationStart (CodeDeploy에게 어떤 스크립트를 실행해야 하는지 알려줘야 함)
9. ValidateService (서비스를 검증하는 서비스 실행)
10. [LB를 사용하는 경우] : BeforeAllowTraffic -> AllowTraffic -> AfterAllowTraffic
11. End

 

<Hooks 동작 방식>

- appspec.yml파일에는 hooks가 정의되어 있고 스크립트를 실행하는 방법(location(파일위치), timeout, runas)이 정의되어 있음

 - Ex. BeforeInstall hook을 실행하면 EC2의 CodeDeploy 에이전트가 해당 hook에 정의되어있는 location의 파일을 실행

- CodeDeploy 에이전트는 환경변수를 가져와 스크립트의 일부로 참조할 수 있음

 - Ex. DEPLOYMENT_GROUP_NAME에 CodeDeploy에서 가져온 환경 변수를 넣을 수 있음

 

<appspec.yml>

version: 0.0

os: linux

files:

  - source: /index.html

    destination: /var/www/html/

hooks:

  BeforeInstall:

    - location: scripts/install_dependencies

      timeout: 300

      runas: root

    - location: scripts/start_server

      timeout: 300

      runas: root

  ApplicationStop:

    - location: scripts/stop_server

      timeout: 300

      runas: root

 

<Deployment Hooks Examples>

• BeforeInstall : 사전 설치 작업을 수행하는 단계로 파일을 복호화하거나 구 버전의 백업을 생성한다.
• AtferInstall : 주로 애플리케이션 설정이나 파일 권한 변경에 사용된다.
• ApplicationStart : ApplicationStop에서 중단된 서비스 재시작
• ValidateService : 배포가 성공적으로 끝났는지 확인하는 목적으로 사용된다.
• BeforeAllowTraffic : 상태 확인 등의 작업을 실행하여 로드밸런서로부터 실제 트래픽을 받기 전 EC2 인스턴스에서 애플리케이션이 정상적으로 실행되고 있는지 확인

 

[Blue/Green Deployments]

• Manual mode (수동 모드) : 블루 인스턴스를 태그로 식별하고 그린 인스턴스도 태그로 식별한다. 두 인스턴스 모두 미리 프로비저닝해야 한다.
• Automatic mode (자동 모드) : 오토스케일링 그룹을 두고 이를 참조하기만 하면 CodeDeploy에 의해 자동으로 새로운 오토스케일링 그룹이 생성되고 동일한 설정/용량이 복사되어 적용된다. 오토스케일링 그룹에 새로운 인스턴스가 추가되면 ALB는 v1에서 v2로 트래픽을 redirection한다.
• blue/green 배포방법을 사용하기 위해서는 로드밸런서가 필수이다.

 

<Instance Termination>

- blue/green 배포에서 인스턴스를 종료하는데는 두가지 옵션이 있다.

1. 배포가 완료된 후 블루 인스턴스를 자동으로 종료하는 옵션(종료 대기 시간 : 1시간(default) - 최대 2일)

2. 배포가 완료된 후에도 블루 인스턴스를 계속 살려두는 옵션(가장 안전하고 가장 비쌈 / 수동으로 종료해야 함)

 

<Hooks>

- blue/green 배포에서 Hook 종류는 동일하나 실행하는 순서가 조금 다름

- BeforeBlockTraffic -> BlockTraffic -> AfterBlockTraffic : v1(original Instance)에서만 실행됨

 

 

[Deployment Configurations]

- 배포구성을 'AllAtOnce'로 설정하면 한 번에 많은 인스턴스를 배포할 수 있지만 가동 중단 시간이 길다.

- 배포구성을 'HalfAtATime'로 설정하면 한 번에 절반의 인스턴스를 배포

- 배포구성을 'OneAtATime'로 설정하면 한 번에 하나씩 인스턴스를 배포

- 사용자 정의 배포구성을 통해 배포 비율을 정의할 수도 있다.

 

 

[Triggers]

• CodeDeploy는 배포 관련 이벤트를 SNS topic으로 전송할 수 있다. (ex. EC2 인스턴스 그룹을 배포했는데 그 중 하나가 실패하면 InstanceFailure 이벤트가 SNS topic으로 전송되도록 구성하여 SNS topic에서 이메일로 전송 가능)
• SNS topic으로 전송가능한 이벤트 : DeploymentSuccess, Deployment Failure, InstanceFailure 등

 

 

[Deployment to ECS]

• ECS플랫폼을 사용하면 새 ECS 작업정의를 ECS 서비스로 배포하는 작업을 자동으로 처리할 수 있음
• blue/green 배포만을 지원하며 서비스에는 반드시 로드밸런서가 연결되어 있어야 함
• ESC 작업정의와 새 컨테이너 이미지가 반드시 생성되어 있어야 함
• 새 컨테이너 이미지를 ECR에 업로드 -> 새 ECS 작업 정의 개정버전을 생성 -> 해당 개정버전이 ECR에서 생성한 새 이미지를 참조하도록 함 -> appspec.yml 파일이 앞서 생성한 새 ECS 작업정의를 참조하도록 정의(필요할 경우 로드밸런서 정보도 지정)
• CodeDeploy를 호출할 때 appspec.yml파일(appspec.yml 파일은 S3 내 저장되어 있어야 함)을 통해 어떤 ECS 작업정의를 배포해야 하는지 파악 -> CodeDeploy가 새 ECS 작업을 클러스터에 배포 -> 모든 작업이 끝나면 구 버전의 ECS 작업 삭제)
• 이러한 경우 CodeDeploy agent는 필요하지 않음 (ECS 서비스와 CodeDeploy가 모두 처리)

 

<CodePipeline> - code push 부터 ECS 클러스터 배포까지 자동화

1. push code
2. CodeCommit
3. CodeBuild (Docker Image 빌드 -> 새 ECS 작업 개정버전 생성 -> 새 이미지를 참조하는 appspec.yml 파일(S3 내) 생성)

 

<appspec.yml>

version: 0.0

Resources:

  - TargetService:

    Properties:

               TaskDefinition: "arn:aws:ecs:aws-region-id:

aws-account-id: task-definition/ecs-demo-task-definition:revition-number"

                LoadBalancerInfo:

                    ContainerName: "container-name"

                    ContainerPort: "container-port"

 

4. CodeDeploy (appspec.yml을 입력 아티팩트로 참조 -> ECS 클러스터로 트래픽을 배포하고 이동하는 방법을 파악 -> 새 ECS 작업 등록 및 기존 작업 제거)

 

 

<ECS 배포 방식>

- ECSLinear, ECSCanary, ECSAllAtOnce 방법이 있다. (로드밸런서에서 ECS 그룹으로 배포하는 방식은 동일)

- 로드밸런서에 'Test Listener'라는 두 번째 리스너를 정의하는 방법도 있는데 주 프로덕션 리스너가 모든 트래픽을 리디렉션 하기 전 새 대상 그룹으로 테스트용 트래픽을 전송하는 방식이다.

 

 

<ECS Deployment Hooks>

Start -> BeforeInstall -> Install -> AfterInstall -> AllowTestTraffic -> AfterAllowTestTraffic -> BeforeAllowTraffic -> AllowTraffic -> AferAllowTraffic -> End

• ECS에서는 후크로 스크립트를 쓸 수 없기 때문에 Lambda 함수를 사용함. (배포 때마다 람다 함수가 실행됨)
• AfterAllowTestTraffic : 테스트 리스너를 정의했다면 새 대상 그룹으로 테스트 트래픽을 보낼 수 있음. 그 다음 새 Hook와 새 Lambda 함수로 ECS 작업이 정상적으로 동작하는지 검증

 

[Deployment to Lambda]

1. 새 Lambda 함수를 생성하여 이를 별칭에 배포 (1을 가리키고 있는 별칭이 v2를 가리키게 만들어야 함)
2. 새 버전에 대한 정보를 appspec.yml 파일에 정의 (S3에 저장)
3. appspec.yml파일을 사용해 CodeDeploy 호출
4. CodeDploy가 자동으로 Lambda 별칭을 업데이트하여 새 버전인 v2를 참조하게 됨
5. 트래픽도 자동으로 v1에서 v2로 이동하며 모든 게 업데이트 됨
6. CodeDeploy 에이전트는 필수가 아님.

 

<appspec.yml>

version: 0.0

Resources:

  - myLambdaFunction:

               Type: AWS::Lambda::Function

        Properties:

                   Name: [LambdaFuntion name]

                   Alias: [LambdaFunction Alias]

                   CurrentVersion: 1

                   TargetVersion: 2

 

> Name, Alias, CurrnetVersion, TargetVersion 항목은 필수이다.

 

<CodePipeline>

1. code push
2. CodeCommit
3. CodeBuild (새로운 Lambda 버전 생성 -> appspec.yml 파일 생성)
4. CodeDeploy (appspec.yml 파일을 입력 아티팩트로 받아 이를 참고해 목적지를 Lambda 함수 별칭의 현재버전에서 대상버전으로 바꿈)

 

별칭 간 트래픽 이동 속도를 조절할 수 있으며 이동방식에는 Canary, Linear, AllAtOnce 가 있다.

 

 

[Lambda Deployment Hooks] (Blue-Green)

• Lambda에서도 배포 hook를 사용할 수 있는데 hook는 Lambda 함수로 실행된다.
• Start -> BeforeAllowTraffic -> AllowTraffic -> AfterAllowTraffic -> End
• BeforeAllowTraffic, AfterAllowTraffic hook에서 Lambda함수를 호출 (ex. BeforeAllowTraffic hook에서 Lambda함수를 invoke하여 ValidateBeforeAllowTraffic 실행)

 

 

[Redeploy & Rollbacks]

• Rollback : CodeDeploy가 이전에 배포한 애플리케이션 버전을 다시 배포
• Automatically rollback : 새 EC2 인스턴스 또는 ECS 작업에 배포하는 것이 실패하였거나 CloudWatch 알람에 연결된 상태에서 알람이 발생한 경우
• Manually rollback
• Rollback 비활성화 : 어떠한 경우에도 rollback이 일어나지 않음
• 롤백이 일어날 때 중요한 점은 CodeDeploy가 마지막 정상 버전을 사용해 새로운 배포를 실행한다(복원된 버전X)

 

[Troubleshooting] - CodeDeploy에서 어떤 배포실패가 발생하던 EventBridge에서 확인 가능하다.

• InvalidSAignatureExcepsion : CodeDeploy와 EC2 인스턴스의 time이 맞지 않는 경우 발생(시간이 정확이 맞아야 함) -> EC2의 시간과 AWS에서 제공하는 시간이 같도록 만들어야 함.
• LifeCycle Event 누락(EC2/On-Premises)
  • [Error message]
  • The overall deployment failed because too many individual instances failed deployment
  • Too few healty instances are available for deployment
  • Some instances in your deployment group are experiencing problems(Error code : HEALTH_CONSTRANITS)
  • [Reasons]
  • CodeDeploy 에이전트가 설치 및 실행중인지 확인하고 IAM 인스턴스 프로필에 적절한 권한이 있는지 확인
  • HTTP proxy를 사용 중이라면 CodeDeploy에서 'proxy_uri' 파라미터를 설정했는지 확인
  • CodeDeploy와 에이전트 사이에 날짜 및 시간이 동일한지 확인

• ASG에 v2 배포 중 ASG에서 scale-out 이벤트가 발생하는 경우 : 
  • scale-out 이벤트에서는 v1버전을 추가한다. (아직 새 배포 작업이 완료되지 않았기 때문)
  • 이런 경우, ASG에는 v1버전과 v2전이 혼재하게 됨
  • ASG에 대한 배포 작업이 마무리되면 CodeDeploy가 자동으로 후속 배포를 진행해 구식 인스턴스를 v1에서 v2로 업데이트

• AllowTraffic 단계가 실패한 경우(green/blue): ELB의 상태 확인 필요 (health check가 설정되지 않았거나 잘못 설정되었을 수 있음)