피드로 돌아가기
Dev.toDevOps
원문 읽기
lab: centralized terraform module support
플랫폼 팀이 중앙화된 Terraform 모듈과 for_each 기반 팀 구성으로 멀티리전 ECR 배포를 관리하며 팀 추가 시 기존 리소스 재생성 없이 신규 리소스만 생성
AI 요약
Context
Application 팀들이 Terraform 코드를 복사하면서 코드 중복, 환경 불일치, 위험한 변경사항이 발생하고 있었다. 플랫폼 팀이 단일 리포지토리에서 모든 팀과 리전의 인프라를 관리하려면 확장 가능한 구조 설계가 필요했다.
Technical Solution
- 중앙화된 모듈 구조 도입: modules/ecr_repositories/ 하위에 재사용 가능한 child 모듈을 작성하고, 환경별 root 모듈(envs/prod/)에서 호출하여 플랫폼 팀이 모듈 소유
- 멀티리전 지원 via Provider 별칭: provider alias(use2, usw1)로 us-east-2와 us-west-1을 동일 구성 내에서 관리하되, 각 module call에 특정 aliased provider 할당
- for_each + 안정적 키로 팀 구성 모델링: teams_by_region을 nested map 구조로 정의하고, 로컬 변수 repo_matrix에서 for_each loop로 전개하여 team-repo 조합별 리소스 생성
- terraform.tfvars를 설정 소스로 단일화: teams_by_region = { region = { team-name = { repositories, scan_on_push, mutable_tags, max_images, team_owner } } } 구조로 정의하여 production 팀이 코드 수정 없이 설정만 변경
- lifecycle prevent_destroy 적용: aws_ecr_repository와 aws_ecr_lifecycle_policy 리소스에 prevent_destroy = true로 명시하여 운영 중 실수로 인한 삭제 방지
- ECR 라이프사이클 정책 자동 적용: 각 리포지토리마다 aws_ecr_lifecycle_policy를 for_each로 생성하고, max_images 값으로 "Keep only last N images" 규칙을 jsonencode로 정책화
Impact
아티클에 정량적 수치가 명시되지 않음
Key Takeaway
for_each와 안정적인 키(team name, repository name)로 비즈니스 엔티티를 모델링하면 새로운 팀 추가 시 기존 리소스가 인덱스 변경으로 재생성되는 count 패턴의 위험을 제거하고, 멀티리전·멀티팀 환경에서 설정 기반 리소스 관리를 실현할 수 있다.
실천 포인트
멀티팀 멀티리전 Terraform 구성을 설계할 때, application 팀별 리포지토리·서비스·정책을 terraform.tfvars의 nested map으로 모델링하고 root module에서 for_each + aliased provider로 처리하면, 팀 추가/제거 시 terraform plan이 해당 팀의 리소스만 신규/삭제 대상으로 표시되어 기존 환경에 대한 의도하지 않은 변경을 방지할 수 있다.