1. CodeDeploy에서 Target Group 및 기타 수정
아래의 편집 클릭
대상 그룹을 tg-B로 변경
코드 디플로이가 수행되고 Green 타겟 그룹에서 정상 트래픽 헬스 체크를 감지할 경우 Blue에서 Green으로 즉시 트래픽을 라우팅하며, Blue는 5분 동안 컨테이너를 남겨놓는다.
배포에 실패하는 경우 롤백하도록 롤백 설정
2. CodePipeline 생성
파이프라인 이름 설정
서비스 역할의 경우 기존에 생성해둔게 있으면 기존 서비스 역할 사용해도 무방하며, 없을 경우 새 서비스 역할을 생성해준다.
아티팩트를 저장할 위치를 지정해도 되고 기본 위치로 설정해도 된다.
소스 스테이지 추가
CodePipeline을 통해 소스 변경을 감지한다.
빌드 스테이지 추가
기 생성해준 CodeBuild로 설정해준다.
배포 스테이지 추가
Amazon ECS (Blue/Green) 으로 공급자를 설정하고
코드 디플로이의 애플리케이션 이름 및 배포 그룹을 선택해준다.
그리고 S3에 저장이 될 빌드 아티팩트의 taskdef.json과 appspec.yml을 ECS 작업 정의와 Appspec 파일로 사용될 수 있도록 설정해준다.
CodePipeline을 통해 CodeBuild를 트리거하였을 때 403 에러가 발생
Ref : https://andrew.hawker.io/dailies/2020/02/24/aws-codepipelines-source-access-denied/
Default 아티팩트 저장소가 아닌 별도의 S3 저장소 버킷 위치를 선택할 때 발생하며, AWS에서 자동으로 생성한 역할은 사용자 지정 S3 버킷 위치에 액세스할 수 없다고 한다.
CodeBuild에 아래의 권한을 추가하면 될 것으로 보인다.
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::${BUCKET_NAME}*"
]
},
정책 추가...
V3로 변경 후 Push
권한 추가 후 우선 아까 실패했던 Download Source 부분은 통과하였다.
빌드까지 성공
현재 CodeDeploy에서 Green으로 배포하는 중이다.
타겟 그룹 B에 컨테이너들이 등록된 모습
Healthy로 변경됨
CodeDeploy에서도 트래픽을 전체적으로 Blue → Green으로 변경하였다.
3단계에서 5분동안 Blue는 대기해놓는다. 문제가 발생할 경우 언제든 RollBack이 가능하다.
Version 3로 배포된 모습
물론 트래픽이 많이 들어오는 서비스라면 앞단에 Nginx를 두어 Docker compose로 Link 연결하여 사용하는 것이 성능상 이점이 많을 것이지만 단일 앱만 배포해보았다.
추후에는 Database와의 연동 또한 고려해보면 좋을 것으로 보인다.
외에 GitHub Actions 라던지 EKS에서의 CICD 배포 자동화 또한 진행해볼 예정이다.
