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 또는 리소스 수)으로 증가하기 시작하면 상황을 제어하기가 더 쉬워질 겁니다.

• 일관된 구조와 명명 규칙(naming convention)을 실천하세요.

  • 절차적 코드와 마찬가지로 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. Crossplane 및 기타 Kubernetes에서 영감을 받은 솔루션. 때로는 Kubernetes 생태계를 활용하고 조정 루프 기능을 사용해 원하는 Terraform 구성(configuration) 상태를 달성하는 것이 합리적입니다. 자세한 내용은 Crossplane vs Terraform 비디오를 참조하세요.

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

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

Terraform 코드 구조

Terragrunt code structures

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

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

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

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

후원자

Please contact me if you want to become a sponsor.

번역

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

기여

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

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

저자

이 책은 다양한 기고자와 번역가의 도움을 받아 안똔 바벤코(Anton Babenko)가 유지하고 있습니다.

특허(라이선스)

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

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

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