Terraform 코드 구조

Terragrunt code structures

이 안내서에 설명된 내용 중 일부를 연습하고자는 하는 분들을 위한 워크숍도 있습니다.

내용은 여기에 있습니다.

https://github.com/antonbabenko/terraform-best-practices-workshop

공식 Terraform 문서는 구성(configuration)의 모든 측면을 자세히 설명합니다. 이 섹션의 나머지 부분을 이해하려면 주의 깊게 읽으세요

이 섹션에서는 이 책에서 사용되는 주요 개념을 설명합니다.

리소스(Resource)

리소스는 is aws_vpc, aws_db_instance 등입니다. 리소스는 어느 한 프로바이더에 속하며 인수(arguments)를 수락하고 속성(attributes)을 출력(output)하며 수명 주기(lifecycle)를가집니다. 리소스는 생성, 검색, 업데이트 및 삭제할 수 있습니다.

리소스 모듈(Resource module)

리소스 모듈은 공통 작업(예: AWS VPC Terraform 모듈이 VPC, 서브넷, NAT 게이트웨이 등을 생성함)을 함께 수행하는 연결된 리소스의 집합입니다. 이는 공급자 구성에 따라 달라지며, 이는 공급자의 구성에 따라 다르며, 공급자 구성 안에서 정의하거나 상위 수준의 구조(예: 인프라 모듈)에서 정의할 수 있습니다.

인프라 모듈(Infrastructure module)

인프라 모듈은 논리적으로 연결되지는 않지만 현재 상황/프로젝트/셋업에서 동일한 목적을 수행하는 리소스 모듈의 집합입니다. 공급자에 대한 구성을 정의하고 다운스트림 리소스 모듈 및 리소스로 전달됩니다. 일반적으로 논리적 구분자(예: AWS Region, Google Project)당 하나의 엔티티에서 작업하도록 제한됩니다.

예를 들어 terraform-aws-atlantis 모듈은 terraform-aws-vpc 및 terraform-aws-security-group과 같은 리소스 모듈을 사용하여 AWS Fargate에서 Atlantis를 실행하는 데 필요한 인프라를 관리합니다.

또 다른 예로 terraform-aws-modules 모듈을 여러 개 함께 사용하여 인프라를 관리하고 도커 리소스를 사용하여 도커 이미지를 구축, 푸시 및 배포하는 terraform-aws-cloudquery 모듈이 있습니다. 이 모든 것이 한 세트로 이루어집니다.

구성(Composition)

구성은 논리적으로 분리된 여러 영역(예: AWS 지역, 여러 AWS 계정)에 걸쳐 존재할 수 있는 인프라 모듈의 모음입니다. 구성은 전체 조직이나 프로젝트에 필요한 전체 인프라를 설명하는 데 사용됩니다.

구성은 개별 리소스를 구현하는 리소스 모듈들로 이루어진 인프라 모듈입니다.

구성 요소의 구성(Composition)과 설정의 구성(Configuration)

역자의 말: 이 책에서는 어떤 대상을 이루는 구성 요소의 집합을 의미하는 composition과 소프트웨어나 환경 등의 상세 옵션을 설정한다는 의미의 configuration이라는 용어가 많이 쓰입니다. 우리말로 옮기면 둘 다 '구성'으로 번역이 되기 때문에 어떻게 할까 고민하다가, 한국어로 이 책을 접하시는 독자분들께 가장 편안하고 이해하기 쉬운 방법이기를 바라는 마음에서 '구성'이라고 쓰고 괄호 안에 영어 원문의 용어를 병기하는 방식을 선택했습니다. 모쪼록 번역이 도움이 되기를 바라며, composition의 구성과 configuration의 구성이 혼란 없이 잘 전달되기를 바랍니다.

데이터 소스(Data source)

데이터 소스는 읽기 전용 작업을 수행하며 프로바이더 구성에 따라 리소스 모듈 및 인프라 모듈에서 사용됩니다.

데이터 소스 terraform_remote_state는 상위 모듈 및 구성(compositions)에 접착제 역할을 합니다.

데이터 소스 external(외부)는 외부 프로그램이 데이터 소스 역할을 하여, 테라폼 구성(configuration)의 다른 곳에서 사용할 수 있도록 임의의 데이터를 노출시킵니다. 예로terraform-aws-lambda module이 있습니다. 여기서 파일 이름은 외부 파이썬 스크립트를 호출하여 계산됩니다.

데이터 소스 http는 주어진 URL로 HTTP GET 요청을 보내고 응답에 대한 정보를 내보냅니다. 이는 네이티브 Terraform 프로바이더가 존재하지 않는 엔드포인트에서 정보를 얻는 데 유용한 경우가 많습니다.

원격 상태(Remote state)

인프라 모듈 및 구성(compositions)은 Terraform state를 다른 사용자가 제어 가능한 방식(예: ACL 지정, 버전 관리, 로깅)으로 검색할 수 있는 원격 위치에 지속시켜야 합니다.

프로파이더(provider), 프로비저너 (provisioner) 및 기타

프로파이더, 프로비저너 및 기타 몇 가지 용어는 공식 문서에 매우 잘 설명되어 있으므로 여기서 반복할 필요가 없습니다. 제 생각에는 좋은 Terraform 모듈을 쓰는 것과는 거의 관련이 없습니다.

왜 이렇게 어려울까?

개별 리소스는 인프라의 원자와 같으며 리소스 모듈은 분자(여러 개의 원자로 구성됨)와 같습니다. 모듈은 버전이 관리되고 공유가 가능한 가장 작은 단위입니다. 모듈에는 정확한 인수 목록이 있으며, 해당 단위가 필요한 기능을 수행하도록 기본 논리를 구현합니다. 예를 들어 terraform-aws-security-group 모듈은 입력을 기반으로 리소스 aws_security_group 및 aws_security_group_rule을 생성합니다. 이 리소스 모듈 자체를 다른 모듈과 함께 사용하여 인프라 모듈을 만들 수 있습니다.

분자(리소스 모듈 및 인프라 모듈) 전반의 데이터에 대한 액세스는 모듈의 아웃풋(outputs) 및 데이터 소스(data sources)를 사용하여 이루어집니다.

구성(compositions) 간 액세스는 원격 상태(remote state)의 데이터 소스를 사용하여 수행되는 경우가 많습니다. 구성 간에 데이터를 공유하는 방법에는 여러 가지가 있습니다.

위에서 설명한 개념을 의사 코드(pseudo-relations)로 표현한다면 다음과 같이 보일 것입니다.

# 한국어
구성-1 {
  인프라-모듈-1 {
    데이터-소스-1 => d1

    리소스-모듈-1 {
      데이터-소스2 => d2
      리소스-1 (d1, d2)
      리소스-2 (d2)
    }

    리소스-모듈-2 {
      데이터-소스-3 => d3
      리소스-3 (d1, d3)
      리소스-4 (d3)
    }
  }
}

# 영어(English)
composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }
}

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는 외에는 어디에도 사용하면 안 됩니다.

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

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

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

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

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

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

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

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

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

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

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

• 일관된 구조와 을 실천하세요.

  • 절차적 코드와 마찬가지로 Terraform 코드는 무엇보다 사람들이 읽을 수 있도록 작성되어야 합니다. 6개월 후에 변경 사항이 발생하더라도 구조에 일관성이 있다면 도움이 될 겁니다.

  • Terraform 상태 파일에서 리소스를 이동할 수 있지만 구조와 이름 지정이 일관되지 않은 경우 이동하기가 더 어려울 수 있습니다.

• 리소스 모듈을 최대한 단순하게 유지하세요.

• 변수로 전달할수 있거나 데이터 소스를 사용하여 검색할 수 있는 값은 하드코딩하지 마세요.

• 데이터 소스와 terraform_remote_state를 특히 구성(composition) 내 인프라 모듈 간의 접착제로 사용하세요.

이 책에서는 예제 프로젝트들이 소규모 인프라부터 대규모 인프라까지 복잡성에 따라 그룹화되어 있습니다. 이 분리는 엄격하지 않으므로 다른 구조도 확인하세요.

인프라 모듈 및 구성의 오케스트레이션(composition)

인프라가 작다는 것은 의존성도 적고 리소스도 적다는 것을 의미합니다. 프로젝트가 성장함에 따라 Terraform 구성(configurations) 실행을 연결하고, 다양한 인프라 모듈을 연결하고, 구성(composition) 내에서 값을 전달해야 할 필요성이 분명해집니다.

개발자가 사용하는 오케스트레이션 솔루션에는 최소 5가지 그룹이 있습니다.

1. 테라폼만 사용합니다. 매우 간단합니다. 개발자는 작업을 완료하려면 Terraform만 알면 됩니다.

2. Terragrunt. 전체 인프라를 조율하고 의존성을 처리하는 데 사용할 수 있는 순수 오케스트레이션 도구입니다. Terragrunt는 기본적으로 인프라 모듈 및 구성(composition)으로 작동하므로 코드의 중복을 줄입니다.

3. 인하우스(in-house) 스크립트. 오케스트레이션을 위한 출발점으로, 그리고 Terragrunt를 발견하기 전에 사용하곤합니다.

4. Ansible 또는 유사한 범용 자동화 도구. 주로 Ansible 이후에 Terraform을 채택하거나 Ansible UI를 적극적으로 사용할 때 사용됩니다.

5. 및 기타 Kubernetes에서 영감을 받은 솔루션. 때로는 Kubernetes 생태계를 활용하고 조정 루프 기능을 사용해 원하는 Terraform 구성(configuration) 상태를 달성하는 것이 합리적입니다. 자세한 내용은 비디오를 참조하세요.

이를 염두에 두고 이 책에서는 이러한 프로젝트 구조 중 처음 두 개, Terraform만 사용하는 경우와 Terragrunt를 알아봅니다.

다음 장에서 또는 의 코드 구조 예를 참조하세요.

출처:

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

• AWS 계정 2개

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

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

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

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

이 예시에는 외부 의존성을 전혀 사용하지 않는 소규모 인프라에 대한 Terraform 구성(configurations)을 구조화하는 예제 코드가 포함되어 있습니다.

locals를 사용해 리소스 간의 명시적 의존성 지정하기

Terraform 구성(configurations)에 직접적인 의존성이 없는 경우에도 특정 리소스가 삭제되어야 함을 Terraform에 알려주는 유용한 방법입니다.

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

Terraform 0.12 - 필수적 vs 선택적 인수

1. var.website가 빈 맵이 아닌 경우 필수적 인수 index_document를 반드시 설정해야 합니다.

2. 선택적 인수 error_document는 생략할 수 있습니다.

variable "website" {
  type    = map(string)
  default = {}
}

resource "aws_s3_bucket" "this" {
  # omitted...

  dynamic "website" {
    for_each = length(keys(var.website)) == 0 ? [] : [var.website]

    content {
      index_document = website.value.index_document
      error_document = lookup(website.value, "error_document", null)
    }
  }
}

website = {
  index_document = "index.html"
}

은 강력하며(지금 최강의 툴이 아니라면) 가장 많이 사용되는 도구 중 하나로, 인프라를 코드로 관리할 수 있습니다. 개발자들이 많은 일을 할 수 있도록 해주며 지원과 통합을 손쉽게 만들어 줍니다.

이 책에서 설명하는 정보의 일부는 모범 사례처럼 보이지 않을지 모릅니다. 저도 이를 인지하고 있습니다. 따라서 독자들이 사용자들이 선호하는 비슷한 방식과 업계에서 확립된 모범 사례를 구분할 수 있도록, 문맥에 대한 힌트와 아이콘을 사용해 각 하위 항목과 관련된 모범 사례의 깊이를 표시해 두었습니다.

이 책은 2018년 햇살이 가득한 마드리드에서 집필을 시작했으며, 여기 이 주소에서 읽어볼 수 있습니다. .

Terraform 1.0에서 사용할 수 있는 실질적 모범 사례를 지난 몇 년 간 업데이트해 왔습니다. 결과적으로 이 책에는 Terraform 사용자들을 위한, 논란의 여지가 없는 모범 사례와 권장 사항이 대부분 포함되어 있다고 할 수 있습니다.

후원자

Please if you want to become a sponsor.

번역

이 책을 다른 언어로 번역하는 데 기여하고 싶다면 저에게 연락주세요.

기여

시간이 지남에 따라 커뮤니티가 성숙해가고 새로운 아이디어가 구현 및 검증되어감에 따라 저는 항상 피드백을 받아 이 책을 업데이트 하고자 합니다.

특정 주제에 관심이 있다면 다루어졌으면 하는 이슈에 엄지손가락을 눌러주세요. 기여하고 싶은 콘텐츠를 가지고 계시면 초안을 작성해 풀 리퀘스트를 제출해 주세요(이 단계에서는 빼어난 글솜씨를 걱정할 필요가 없습니다!).

저자

이 책은 다양한 기고자와 번역가의 도움을 받아 가 유지하고 있습니다.

특허(라이선스)

이 저작물은 Apache 2 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 를 참조하세요.

본 컨텐츠의 저자와 기여자는 본 컨텐츠에서 발견되는 정보의 유효성을 보장하지 않습니다. 귀하는 본 컨텐츠에서 제공되는 정보는 자유롭게 제공되며, 귀하와 본 컨텐츠 또는 프로젝트와 관련된 사람들 사이에 그 어떤 종류의 합의나 계약도 이루어지지 않는다는 점을 이해하셔야 합니다. 오류 또는 누락이 과실, 사고 또는 어떤 기타 원인에 의한 것이든, 본저자와 기여자는 컨텐츠에 포함되거나, 관련되거나, 연결된 정보의 오류 또는 누락으로 인한 그 어떠한 손실, 손상 또는 중단에 대해서 당사자에게 그 어떠한 책임도 지지 않으며 그책임을 부인함을 여기밝힙니다.

저작권© 2018-2023 안똔 바벤코 Anton Babenko.

출처:

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

• AWS 계정 2개

• 지역 2곳

• 2개의 개별 환경(아무것도 공유하지 않는 prod 및 stag). 각 환경은 별도의 AWS 계정에 존재하며 두 지역 간의 리소스를 포괄합니다

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

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

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

• - 오케스트레이션 도구

• - 코드 린터

• - 버전 관리자

• - 풀 리퀘스트 자동화

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

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

에 대한 해결책은 무엇입니까?

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

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

문서

자동으로 생성된 문서

(사전 커밋)은 다중 언어 사전 커밋 후크를 관리하고 유지하기 위한 프레임워크입니다. Python으로 작성되었으며 코드가 git 저장소에 커밋되기에 앞서 개발자의 컴퓨터에서 자동으로 작업을 수행하는 강력한 도구입니다. 일반적으로 린터를 실행하고 코드 형식을 지정하는 데 사용됩니다(참조).

Terraform 구성(configurations)을 사용하면 pre-commit(사전 커밋)을 사용하여 코드 형식을 지정하고 유효성을 검사할 수 있을 뿐만 아니라 문서를 업데이트할 수 있습니다.

사전 커밋이 익숙해지도록 를 확인해보세요. 그리고 이 저장소가 이미 사용되고 있는 기존 저장소(예: )도 확인해 보세요.

테라폼 독스(terraform-docs)

(테라폼 독스)는 Terraform 모듈에서 다양한 출력 형식으로 문서를 생성하는 도구입니다. 사전 커밋 후크 없이 수동으로 실행하거나, (사전 커밋 Terraform 후크)를 사용하여 문서를 자동으로 업데이트할 수 있습니다.

@todo: Document module versions, release, GH actions

리소스

3. 블로그 글:

일반적인 규칙

1. 리소스 이름, 데이터 소스 이름, 변수 이름, 출력 등 모든 곳에서 -(대시, dash) 대신 _(밑줄)을 사용합니다.

2. (UTF-8이 지원되더라도) 소문자와 숫자를 사용하는 것이 좋습니다.

리소스 및 데이터 소스 인수

1. (이름 일부 또는 전체를 포함해) 리소스 이름에 리소스 유형을 반복하지 마세요.

`resource "aws_route_table" "public" {}`

`resource "aws_route_table" "public_route_table" {}`

`resource "aws_route_table" "public_aws_route_table" {}`

1. 보다 더 설명적이고 일반적인 이름을 사용할 수 없거나 리소스 모듈이 해당 유형에 대해 단 한 개의 리소스를 생성하는 경우(예: AWS VPC module에는 aws_nat_gateway 유형의 리소스 한 개와 aws_route_table 유형의 리소스가 여러 개 있는 경우에 aws_nat_gateway는 this로, aws_route_table은 private, public, database와 같이 더 설명적인 이름을 지어줘야 합니다.

2. 이름에는 항상 단수 명사를 사용하세요.

3. 인수 값 내부와 값이 사람에게 노출되는 곳(예: RDS 인스턴스의 DNS 이름 내부)에는 -를 사용합니다.

4. 리소스 또는 데이터 소스 블록 내부에 인수 count / for_each를 맨 위의 첫 번째 인수로 포함하고 그 뒤는 줄바꿈으로 구분합니다.

5. 리소스에서 지원하는 경우 인수 tags를 마지막 실제 인수로 포함하고 필요한 경우 depends_on 및 lifecycle을 포함합니다. 이들 모두는 하나의 빈 줄로 구분되어야 합니다.

6. 인수 count / for_each에 조건을 사용할 때는 length나 다른 표현식을 사용하는 대신 불(bool) 값을 쓰는 것이 좋습니다.

resource 코드 예제

count / for_each의 사용

resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "private" {
  for_each = toset(["one", "two"])

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

tags의 배치

resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

count의 조건

resource "aws_nat_gateway" "that" {    # Best
  count = var.create_public_subnets ? 1 : 0
}

resource "aws_nat_gateway" "this" {    # Good
  count = length(var.public_subnets) > 0 ? 1 : 0
}

변수

1. 리소스 모듈의 바퀴를 다시 만들지 마세요(역주: Don't reinvent the wheel! 이미 만들어져서 잘 쓰이고 있는 것을 두고 굳이 비슷한 수준의 것을 새로 만드는 데 에너지를 쏟는 것을 피하라는 말). 작업 중인 리소스에 대한 "인수 참조" 섹션에 정의된 대로 변수에 대한 name, description, 및 default값을 사용하세요.

2. 변수의 유효성 검사에 대한 지원은 다소 제한적입니다(예: 다른 변수에 액세스하거나 조회를 수행할 수 없음). 대부분의 경우 이 기능은 쓸모가 없으므로 상황에 맞춰 계획하세요.

3. 유형이 list(...) 또는 map(...)인 경우 변수 이름에 복수형을 사용합니다.

4. 변수 블록의 키 순서를 다음과 같이 지정하세요: description , type, default, validation

5. 분명하다고 생각되더라도 항상 모든 변수에 대한 description(설명)을 포함하세요(향후 필요할 것입니다).

6. 각 키에 엄격한 제약을 적용할 필요가 없는 한 object()와 같은 특정 유형보다는 간단한 유형 (number, string, list(...), map(...), any)을 사용하는 것이 좋습니다.

7. 지도의 모든 요소가 동일한 유형(예: string문자열)이거나 해당 유형으로 변환될 수 있는 경우(예: number 숫자 유형을 string 문자열로 변환할 수 있는 경우) map(map(string))과 같은 특정 유형을 사용합니다.

8. 특정 깊이에서 시작하거나 여러 유형을 지원해야 하는 경우에 유형 유효성 검사를 비활성화하려면 any 유형을 사용하세요.

9. 값 {}은 지도일 때도 있고 객체일 때도 있습니다. 객체를 만들 수 있는 방법이 없기 때문에 지도를 만들려면 tomap(...)을 사용하세요.

출력(outputs)

모듈의 범위 밖에서도 출력을 일관되고 이해하기 쉽게 만드세요(사용자가 모듈을 사용할 때 반환되는 값의 유형과 속성이 무엇인지 명확해야 합니다).

1. 출력 이름은 자신이 포함하는 속성을 설명해야 하며 일반적으로 우리가원하는 것보다는 형식이 덜 자유롭습니다.

2. 출력 이름에 적합한 구조는 {name}_{type}_{attribute}이며 다음을 참고하세요.

   1. {name}은 프로바이더 접두사가 없는 리소스 또는 데이터 소스 이름입니다. aws_subnet의 {name}은 subnet이고, aws_vpc의 경우 vpc입니다.

   2. {type}은 리소스 소스의 유형입니다.

   3. {attribute}는 출력이 반환하는 속성입니다.

   4. 예제 보기.

3. 출력이 보간 함수 및 여러 리소스가 포함된 값을 반환하는 경우 {name} 및 {type}은 가능한 한 일반적이어야 합니다(접두사로 this는 생략해야 함). 예를 참조하세요.

4. 반환된 값이 리스트인 경우 복수형 이름을 가져야 합니다. 예를 참조하세요.

5. 분명하다고 생각되더라도 항상 모든 변수에 대한 description(설명)을 포함하세요.

6. 모든 모듈의 모든 위치에서 이 출력의 사용을 완전히 제어할 수 있는 게 아니라면 sensitive 인수를 설정하지 마세요.

7. element(concat(...))(0.13 이전 버전의 레거시 접근 방식)보다 try()(Terraform 0.13부터 사용 가능)를 쓰는 것이 좋습니다.

output 코드 예제

보안 그룹의 ID를 최대 1개 반환합니다

output "security_group_id" {
  description = "The ID of the security group"
  value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}

동일한 유형의 리소스가 여러 개 있는 경우 출력 이름에서 this를 생략해야 합니다.

output "this_security_group_id" {
  description = "The ID of the security group"
  value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}

반환 값이 리스트인 경우 복수형 이름을 사용하세요.

output "rds_cluster_instance_endpoints" {
  description = "A list of all cluster instance endpoints"
  value       = aws_rds_cluster_instance.this.*.endpoint
}

https://twitter.com/antonbabenko/lists/terraform-experts - 매우 적극적으로 Terraform을 사용해 일을 하고 (물어보면) 많은 것을 알려줄 수 있는 사람들의 목록

https://github.com/shuaibiyy/awesome-terraform - HashiCorp의 Terraform에 대한 선별된 리소스 목록

http://bit.ly/terraform-youtube - 안똔 바벤코의 "당신을 위한 Terraform 주간 복용량" YouTube 채널. 리뷰, 인터뷰, Q&A, 라이브 코딩 및 Terraform 꿀팁을 알려주는 라이브 스트리밍

https://weekly.tf - Terraform 주간 뉴스레터. 안똔 바벤코가 제공하는 Terraform 세계의 다양한 뉴스(프로젝트, 공지, 토론)