CloudFormation Template 파일은 기능별로 모듈화하고, 환경별로 분리하여 관리하는 것이 좋다.
CloudFormation 실습 중 느낀 불편한 점
yaml 파일 자체가 행이 많을 수 밖에 없는 구조여서 여러 리소스를 관리하는 도중에 계속 신경이 쓰였다.
(CloudFormation 에만 국한되어 있기 보다는 IaC 사용 중 느낀 불편한 점이다.)
그래서 실습 환경에서도 프로젝트 내에서 어느정도 디렉터리를 구분해 사용해야 할 필요성을 느꼈고, 최소한의 컨벤션을 만들어나가야 앞으로도 일관적인 학습을 실현할 수 있을 것 같아 간략하게 정리해 봤다.
CloudFormation 에서 소규모 프로젝트용 Template 를 관리할 때는 …
모듈화, 환경 기반 분리, 리소스 관계 기반 분리 등 다양한 기준을 두고 디렉터리를 구분할 수 있지만, 내가 느낀 초보자가 가장 사용하기 좋은 방식은 기능 기반 분리였다.
물론 여러 명이서 관리하기 시작하고, 본격적인 배포 프로세스가 시작되면 환경 기반 분리, 모듈화도 필수이다.
AWS의 각 서비스 기능을 기준으로 분리되므로 한 눈에 보기 쉽기 때문이다.
기능 기반 분리에 대해서
기능 기반은 각 서비스나 애플리케이션 기능을 독립적으로 관리하는 방식이다.
아래와 같이 큰 기능 카테고리 안에 포함되는 리소스끼리 yaml 파일을 모아놓을 수 있어 stack 생성 오류 발생 시 추적이 용이하다.
/cloudformation/
├── networking/
│ ├── VPC.yaml
│ └── Subnet.yaml
├── compute/
│ ├── EC2.yaml
│ └── AutoScaling.yaml
├── storage/
│ ├── S3.yaml
│ └── CloudFront.yaml
├── templates/
│ └── master-template.yaml # 모든 스택을 연결하는 마스터 템플릿
└── parameters/
├── dev-parameters.json
└── prod-parameters.json
Parameters 파일에 대해서 (25.05.13 추가)
여러 Stack 을 만들게 되면서 Resource 별로 Parameters 를 관리해줘야 하는 번거로움이 생겼다.
현재는 SSM Parameter Store 를 사용하여 중앙에서 Parameters 를 관리하여 기존보다 비교적 편하게 CloudFormation 코드를 작성하고 있다.
추후에 프로젝트가 확장되고, 더 다양한 경험이 쌓이면 해당 게시글을 업데이트 하고, 제목도 변경할 예정이다.