티스토리 뷰

CDK에서 원하는 배포 환경으로 배포하기 위해 나는 ID를 바꾸는 Practice를 가장 많이 쓴다.

https://jhb.kr/419

 

[CDK] 배포 환경에 따라 다른 스택으로 배포하기

CDK로 스택을 배포 할 때 Dev / Test / Prod 등의 환경으로 배포 하기 위해 여러가지 방법이 있다. 여러 가지 방법 중 핵심이 되는 것은 결국 '스택의 아이디를 배포 환경에 맞추어 바꾸어 준다'는 것이

jhb.kr

 

그러면 Service와 CI/CD에 대한 스택은 어떻게 구성하는게 좋을까?

처음에 나는 서비스 생성 자체는 ecs_patterns.ApplicationLoadBalancedFargateService 를 사용하였고, 이를 ServiceStack${env}이라 두고, 이를 관리하는 CI/CD를 ServiceCicdStack${env} 으로 나눠서 관리하려 하였다.
이때 ServiceStack에서는 서비스 생성 및 ECS 클러스터를 생성하게 하였고, CI/CD Stack에서는 CodeCommit Repository, CodeBuild, ECR Repository, CodeDeploy를 구성하였다.

잘못된 선택이었다.
일단, CodeCommit의 branch 명에 따라서 ${env}에 맞는 서비스를 배포 하려고 했었는데 아래의 문제가 발생했다.

1. CodeCommit은 사실 1개만 생성되면 된다. 따라서 CodeCommit을 생성하는 Stack은 한개만 존재해야 하며, 다른 Stack${env}에서는 이 값을 가져와서 써야했다.

2. ECS Cluster 생성은 따로 빼야했다.

3. QA, Production용 CI/CD Pipeline은 Dev와는 다른 방식을 택해야 했다. Staging 에서 QA가 끝난 후 Approve를 통해 Prod로 가는 형태가 돼야 했다.

따라서 결과적으로 아래의 구성을 갖는게 바람직한 것으로 결론 내렸다.

서비스 이름이 Order 라면

OrderServiceProdStack, OrderServiceEcsStack${env}, OrderServiceStack${env} 이렇게 3개를 생성한다.

OrderServiceProdStack : OrderService의 QA와 Prod용 ECS Cluster를 생성하고 각각에 대한 Fargate Service를 생성. 그리고 이에 대한 CI/CD Pipeline 생성. 이때 CodeCommit Repository의 경우 다른 ${env} 에서도 사용될 예정이다.

OrderServiceEcsStack${env} : ${env}에 해당하는 ECS Cluster를 생성하기 위한 스택

OrderServiceStack${env} : ${env}에 해당하는 ECR Repository 생성, CodeBuild 생성 (CodeCommit에서 Build 후 Push 하는 용도)

이렇게 구성하는 경우 dev 환경 (${env})의 경우 원하는 대로 배포해서 사용이 가능하고 QA / Prod는 그에 맞는 Pipeline을 구성해서 사용하는 것이 가능하다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함