Terraform 스택을 3단계로 나눈 이유
인프라 전체를 Terraform 하나로 관리하면 편해 보이지만, 앱을 배포할 때마다 클러스터까지 plan에 걸리게 됩니다. 그래서 바뀌는 빈도에 따라 세 단계로 나눴습니다.
| 단계 | 디렉토리 | 만드는 것 | 적용 |
|---|---|---|---|
| 1 | platform/cluster |
kind 클러스터 | 수동 (거의 안 바뀜) |
| 2 | platform/gateway |
Envoy Gateway, GatewayClass, Gateway | 수동 (가끔) |
| 3 | envs/dev, envs/prd |
Namespace, Deployment, Service, HTTPRoute, 터널 | dev 자동 / prd 수동 |
왜 나눴나
- CRD 순서 문제: GatewayClass 같은 CRD는 2단계에서 설치됩니다. 3단계를 plan할 때 CRD가 이미 있어야 합니다.
- 사고 반경 축소: 3단계(배포)가 1단계(클러스터)를 실수로 지우거나 재생성하지 못합니다.
- state 분리: 스택마다 별도
tfstate를 써서 잠금과 변경 범위가 독립적입니다.
서비스 목록은 데이터로
서비스 정의는 HCL 대신 JSON 카탈로그(services.auto.tfvars.json)에 둡니다. 서비스를 추가할 때는 한 줄만 넣으면 됩니다.
"api": { "port": 8080, "route_path": "/api", "replicas": 1, "memory_mb": 512 }
route_path를 빼면 클러스터 안에서만 접근할 수 있는 내부 서비스가 됩니다. 배포된 이미지 태그는 images.auto.tfvars.json에 따로 기록하기 때문에 Git만 봐도 "지금 무엇이 떠 있는지" 알 수 있습니다.