발단
회사에서 EKS Blue/Green Migration을 구현해야 할 프로젝트를 시작했다. IaC 및 (자동화 될) 워크플로 툴은 테라폼. 테라폼 프로젝트를 한번 실패하고 나선, 이 프로젝트를 어떻게 진행해야 할 지 정리해보았다.
모듈 만들기 → 워크플로 → 자동화
IaC 프로젝트를 성공적으로 하기 위해선 더 필요한 요소도 있겠지만, 위의 것들은 모두 이전 프로젝트에서 잘 되지 않았던 부분이다.
먼저 테라폼은 필요한 모듈을 만들어 써야 한다. 단순히 리소스를 import 하고 그 기준으로 나열하면, 웹 콘솔에서의 AWS 서비스와 크게 다르지 않다(그럴거면 GUI가 더 보기 좋을 때도 있다!). 그래서 뒤에서 고민할 것들은 제쳐두고 우선 어떤 단위로 모듈을 만들 수 있을지 만들고 부셔보면서 테라폼 프로젝트를 시작하는게 중요하다고 생각했다.
하지만 “우리 회사 워크로드를 어떻게 EKS 수준에서 Blue/Green Migration 가능하게 할까?”라는 질문은 꽤 어려웠다. 이건 워크로드가 모범 사례를 따르지 않고 배포되어 있다는 의미와도 비슷하다. 반대로 “일반적인(또는 모범사례의) EKS Blue/Green Migration 가능한 테라폼 프로젝트에서 우리 워크로드를 어떻게 배포할 수 있을까?”의 반대 방향으로 생각해보기 시작했다. 그러다 찾게 된 것이 EKS Blueprints이다.
Bootstrapping clusters with EKS Blueprints
EKS Blueprints는 IaC 툴(테라폼 또는 AWS CDK)로 EKS 클러스터를 프로비저닝 할 수 있도록 패턴 코드(구성)를 모아 놓은 레포이다. 이 패턴 구성을 참고하여 복붙 후에 사용 사례에 맞게 고쳐 쓰길, IaC로써 EKS 클러스터를 만들고 운영하기 위해 사용하라고 한다. (EKS Blueprints for Terraform은 AWS IA(Integration & Automation) 프로젝트 중 하나이고, 테라폼 프로바이더도 별도로 있다)
최신의 그림은 아닌 듯 하나(애드온 쪽이 더 업데이트 된 걸로 보인다), 큰 구성은 크게 세 가지로 나눌 수 있다.
•
EKS 클러스터와 VPC 등 AWS 서비스들
•
Add-ons; EKS에서 제공되는 쿠버네티스 확장
•
Teams; EKS - AWS 서비스로써 그리고 쿠버네티스 클러스터로써의 RBAC
Amazon EKS Blueprints for Terraform
테라폼 버전의 EKS Blueprints를 사용하기 위해선 (당연한 이야기이지만) 기본적인 AWS 서비스들에 대한 이해(awscli), 쿠버네티스(kubectl) 그리고 테라폼에 대한 이해가 있어야 한다.
이 중 테라폼 관련한 것이 중요하다고 생각하는데 우선, 내가 프로젝트 초반에 신경 쓰려는 모듈과 관련해서도, 패턴 구성 자체가 단일 모듈로 구성되지 않는다.
Therefore, the patterns provided only contain variables when certain information is required to deploy the pattern (i.e. - a Route53 hosted zone ID, or ACM certificate ARN) and generally use local variables. If you wish to deploy the patterns into a different region or with other changes, it is recommended that you make those modifications locally before applying the pattern.
Patterns are not intended to be consumed in-place in the same manner that one would consume a module. Therefore, we do not provide variables and outputs to expose various levels of configuration for the examples. Users can modify the pattern locally after cloning to suite their requirements.
•
입력 변수(variables)를 제어하는게 아니라 로컬 값(locals)을 직접 바꿔야 할 수 있다.
•
코드를 그대로 사용하지 말자. 모든 것이 변수화 되어 있지 않아 커스텀이 필요한 부분들이 있다.
We recognize that most users will already have an existing VPC in a separate Terraform workspace. However, the patterns provided come complete with a VPC to ensure a stable, deployable example that has been tested and validated.
•
패턴마다 새 VPC가 제공된다. PoC를 지나 실제 구축, 운영으로 넘어갈 때 중요한 부분이다. 기존 VPC에 구성된 클러스터에서 새 VPC로 마이그레이션을 하거나, 기존 VPC 부분을 잘 import 해야할 것 같다.
그리고 운영 시 워크플로에 대한 부분도 생략되어 있다. 문서에서 제공하는 init → apply → destroy는 그냥 한번의 실습, PoC 정도만 고려한 것이다. 이 부분은 실제 운영 환경에 도입 시 고민해야한다(아직은 아니다). 이런 부분은 내가 사이드 프로젝트로 진행하는 Terraforming AWS와도 유사하다.