출처: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

이 예시에는 다음을 사용하는 중간 규모 인프라에 대한 Terraform 구성(configurations)을 구조화하는 예제 코드가 포함되어 있습니다.

• AWS 계정 2개

• 2개의 별도 환경(아무것도 공유하지 않는 prod 및 stage). 각 환경은 별도의 AWS 계정에 존재

• 각 환경은 Terraform Registry에서 제공되는 기존 인프라 모듈(alb)의 다른 버전을 사용합니다.

• 로컬 디렉토리에서 소스를 제공하므로 각 환경은 같은 버전의 내부 모듈 modules/network을 사용합니다.

제가 알고 있어야 하고 사용을 고려해야 할 도구는 무엇일까요?

• Terragrunt - 오케스트레이션 도구

• tflint - 코드 린터

• tfenv - 버전 관리자

• Atlantis - 풀 리퀘스트 자동화

• pre-commit-terraform - pre-commit 프레임워크와 함께 사용하는 Terraform용 git 후크 모음

• Infracost - 풀 요청에서 Terraform에 대한 클라우드 비용 추정. Terragrunt, Atlantis 및 pre-commit 테라폼에서도 사용 가능합니다.

의존성 지옥에 대한 해결책은 무엇입니까?

리소스 및 인프라 모듈의 버전을 지정해야 합니다. 프로바이더는 모듈 외부에서, 하지만 구성(composition) 내에서만 구성되어야(configure) 합니다. 프로바이더 및 Terraform 버전도 잠글 수 있습니다.

마스터 의존성 관리 도구는 없지만 의존성 사양과 관련된 문제를 줄이는 몇 가지 팁이 있습니다. 예를 들어, Dependabot을 사용하여 의존성 업데이트를 자동화할 수 있습니다. Dependabot은 의존성을 안전하게 최신 상태로 유지하기 위해 풀 리퀘스트를 생성합니다. Dependabot은 Terraform 구성(configurations)을 지원합니다.

Terraform 코드 구조와 관련된 질문은 커뮤니티에서 가장 자주 묻는 질문입니다. 우리 모두가 어느 시점엔가 프로젝트에 가장 적합한 코드 구조가 무엇일지 고민해보기도 했죠.

Terraform 구성(configurations)을 어떻게 구성해야 할까?

이는 많은 해결책이 존재하는 질문 중 하나이며 보편적인 조언을 드리기가 매우 어렵습니다. 따라서 우리가 다루고자 하는것이 무엇인지 이해하는 것부터 시작해 봅시다.

• 프로젝트의 복잡성은 어떻게 되나요?

  • 관련 리소스 수

  • Terraform 프로바이더 수(아래 "논리적 제공자(logical providers)"에 대한 참고 사항을 확인하세요)

• 인프라가 얼마나 자주 변경됩니까?

  • 월/주/일에 1회부터

  • 지속적으로까지(새 커밋이 있을 때마다)

• 코드 변경 게시자? 새 아티팩트가 빌드되면 CI 서버가 저장소를 업데이트하도록 허용합니까?

  • 개발자만 인프라 저장소에 푸시할 수 있습니다.

  • 누구나 PR을 열어 무엇에 대한 변경이든 제안할 수 있습니다(CI 서버에서 실행되는 자동화된 작업 포함).

• 어떤 배포 플랫폼이나 배포 서비스를 사용하시나요?

  • AWS CodeDeploy, Kubernetes 또는OpenShift에는 약간 다른 접근 방식이 필요합니다.

• 환경은 어떻게 그룹화되나요?

  • 환경, 지역, 프로젝트별

Terraform 구성(configurations) 구조화 시작하기

모든 코드를 main.tf에 넣는 것은 프로젝트를 막 시작하거나 예제 코드를 작성할 때는 좋은 생각입니다. 다른 모든 경우에는 다음과 같이 여러 파일에 논리적으로 분할하는 것이 더 좋습니다.

• main.tf - 모듈, 로컬 및 데이터 소스를 호출하여 모든 리소스 생성

• variables.tf - main.tf에서 사용되는 변수 선언을 포함합니다

• outputs.tf - main.tf에서 생성된 리소스의 출력(outputs)을 포함합니다.

• versions.tf - Terraform 및 프로바이더에 대한 버전 요구 사항을 포함합니다.

terraform.tfvars는 구성(composition) 외에는 어디에도 사용하면 안 됩니다.

Terraform 구성(configuration)의 구조를 어떻게 생각하면 될까?

코드 구조화에 대한 일반적인 권장 사항

• 적은 수의 리소스로 작업하는 것이 더 쉽고 빠릅니다.

  • terraform plan 및 terraform apply는 모두 클라우드 API 호출(예: AWS, GCP, Azure)을 보내 리소스 상태를 확인합니다.

  • 전체 인프라를 단일 구성(composition)으로 구성(configure)하는 경우 시간이 다소 걸릴 수 있습니다.

• 리소스가 적을 경우 폭발 반경(역주: blast radius. 보안 침해의 경우 문제가 생겼을 시 그 여파로 영향을 받는 범위를 폭발의 반경에 비유)이 더 작습니다.

  • 관련되지 않은 리소스를 별도의 구성(composition)에 배치하여 서로 격리하면 문제가 발생할 경우 위험이 줄어듭니다.

• 원격 상태(remote state)를 사용해 프로젝트를 시작하세요. 이유는 다음과 같습니다.

  • 노트북은 인프라의 단일 진실 공급원(infrastructure source of truth)을 위한 장소가 아닙니다.

  • tfstate 파일을 git에서 관리하는 것은 헬게이트의 시작입니다.

  • 나중에 인프라 계층이 여러 방향(의존성dependencies 또는 리소스 수)으로 증가하기 시작하면 상황을 제어하기가 더 쉬워질 겁니다.