기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 테라폼 모듈에 대한 이해
코드형 인프라 (IaC) 영역에서 *모듈은* 재사용을 위해 격리되고 함께 패키징되는 독립형 코드 블록입니다. 모듈의 개념은 Terraform 개발에서 피할 수 없는 부분입니다. 자세한 내용은 Terraform 설명서의 [모듈을](https://developer.hashicorp.com/terraform/language/modules) 참조하십시오. AWS CloudFormation 모듈도 지원합니다. 자세한 내용은 AWS 클라우드 운영 및 마이그레이션 블로그의 [AWS CloudFormation 모듈 소개를](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/) 참조하십시오.
Terraform의 모듈 간의 주요 차이점은 특수 리소스 유형 () 을 사용하여 CloudFormation 모듈을 가져온다는 것입니다. CloudFormation `AWS::CloudFormation::ModuleVersion` [Terraform의 모든 구성에는 루트 모듈이라는 모듈이 하나 이상 있습니다.](https://developer.hashicorp.com/terraform/language/modules#the-root-module) **기본.tf** 파일에 있는 테라폼 리소스 또는 Terraform 구성 파일의 파일은 루트 모듈에 있는 것으로 간주됩니다. 그러면 루트 모듈이 다른 모듈을 호출하여 스택에 포함할 수 있습니다. [다음 예제는 오픈 소스 eks 모듈을 사용하여 Amazon Elastic Kubernetes Service (Amazon EKS) 클러스터를 프로비저닝하는 루트 모듈을 보여줍니다.](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest)
```
terraform {
required_providers {
helm = {
source = "hashicorp/helm"
version = "2.12.1"
}
}
required_version = ">= 1.2.0"
}
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "20.2.1"
vpc_id = var.vpc_id
}
provider "helm" {
kubernetes {
host = module.eks.cluster_endpoint
cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
}
}
```
위의 구성 파일에 공급자가 포함되어 있지 않다는 사실을 눈치채셨을 것입니다. AWS 모듈은 독립적이며 자체 제공자를 포함할 수 있기 때문입니다. Terraform 공급자는 전 세계적이므로 하위 모듈의 공급자를 루트 모듈에서 사용할 수 있습니다. 하지만 모든 모듈 값에 적용되는 것은 아닙니다. 모듈 내의 다른 내부 값은 기본적으로 해당 모듈로만 범위가 지정되며 루트 모듈에서 액세스할 수 있으려면 출력으로 선언해야 합니다. 오픈소스 모듈을 활용하여 스택 내 리소스 생성을 단순화할 수 있습니다. 예를 들어, eks 모듈은 EKS 클러스터를 프로비저닝하는 데 그치지 않고 완벽하게 작동하는 Kubernetes 환경을 프로비저닝합니다. eks 모듈 구성이 요구 사항에 맞으면 이를 사용하면 수십 줄의 코드를 추가로 작성하지 않아도 됩니다.
## 모듈 호출
[https://developer.hashicorp.com/terraform/cli/commands/init](https://developer.hashicorp.com/terraform/cli/commands/init) 이 `terraform init` 명령이 수행하는 기본 단계 중 하나는 모든 하위 모듈을 찾아 종속 항목으로 디렉터리로 가져오는 것입니다. `.terraform/modules` 개발 중에 외부 소스 모듈을 새로 추가할 때마다 명령을 사용하기 전에 다시 초기화해야 합니다. `apply` Terraform *모듈에* 대한 참조를 들으면 이 디렉터리의 패키지를 참조하는 것입니다. 엄밀히 말하면 코드에서 선언하는 모듈은 *호출 모듈이므로 실제로는 module* 키워드가 실제 모듈을 호출하며, 이 모듈은 종속성으로 저장됩니다.
이런 식으로 호출 모듈은 배포 시 교체될 전체 모듈을 보다 간결하게 나타내는 역할을 합니다. 원하는 기준을 사용하여 스택 내에 자체 모듈을 만들어 리소스를 논리적으로 분리함으로써 이 아이디어를 활용할 수 있습니다. 단, 이 작업의 최종 목표는 스택 복잡성을 줄이는 것이어야 한다는 점만 기억하세요. 모듈 간에 데이터를 공유하려면 모듈 내에서 해당 데이터를 출력해야 하기 때문에 모듈에 너무 많이 의존하면 상황이 지나치게 복잡해질 수 있습니다.
## 루트 모듈
모든 Terraform 구성에는 적어도 하나의 모듈이 있으므로 가장 많이 다루게 될 모듈인 루트 모듈의 모듈 속성을 검사하는 데 도움이 될 수 있습니다. Terraform 프로젝트를 작업할 때마다 루트 모듈은 최상위 디렉터리의 모든 `.tf` (또는`.tf.json`) 파일로 구성됩니다. 최상위 `terraform apply` 디렉토리에서 실행하면 Terraform은 해당 디렉토리에서 찾은 모든 파일을 실행하려고 시도합니다. `.tf` 하위 디렉터리의 모든 파일은 이러한 최상위 구성 파일 중 하나에서 호출되지 않는 한 무시됩니다.
이렇게 하면 코드를 어느 정도 유연하게 구성할 수 있습니다. 단일 프로세스에 여러 파일이 포함될 수 있기 때문에 Terraform 배포를 파일보다 모듈이라고 부르는 것이 더 정확한 이유이기도 합니다. Terraform이 모범 사례로 권장하는 [표준 모듈 구조가](https://developer.hashicorp.com/terraform/language/modules/develop/structure) 있습니다. 하지만 최상위 디렉터리에 `.tf` 파일을 넣으면 나머지 파일과 함께 실행됩니다. 실제로 모듈을 실행하면 모듈의 모든 최상위 `.tf` 파일이 배포됩니다. `terraform apply` 그렇다면 Terraform은 어떤 파일을 가장 먼저 실행할까요? 이 질문에 대한 답은 매우 중요합니다.
Terraform은 초기화 후와 스택 배포 전에 수행하는 일련의 단계가 있습니다. 먼저 기존 구성을 분석한 다음 [종속성 그래프를 생성합니다](https://developer.hashicorp.com/terraform/internals/graph). 종속성 그래프는 어떤 리소스가 필요하고 어떤 순서로 처리해야 하는지를 결정합니다. 예를 들어 다른 리소스에서 참조되는 속성을 포함하는 리소스는 종속 리소스보다 먼저 처리됩니다. 마찬가지로 `depends_on` 파라미터를 사용하여 명시적으로 종속성을 선언한 리소스는 지정한 리소스보다 먼저 처리됩니다. 가능한 경우 Terraform은 병렬 처리를 구현하고 비종속 리소스를 동시에 처리할 수 있습니다. [배포하기 전에 terraform graph 명령을 사용하여 종속성 그래프를 볼 수 있습니다.](https://developer.hashicorp.com/terraform/cli/commands/graph)
종속성 그래프가 생성된 후 Terraform은 배포 중에 수행해야 할 작업을 결정합니다. 종속성 그래프를 최신 상태 파일과 비교합니다. 이 프로세스의 결과를 *계획이라고* 하며 이는 CloudFormation [변경](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-create.html) 세트와 매우 비슷합니다. [terraform plan](https://developer.hashicorp.com/terraform/cli/commands/plan) 명령을 사용하면 현재 계획을 볼 수 있습니다.
가장 좋은 방법은 표준 모듈 구조에 최대한 가깝게 유지하는 것이 좋습니다. 구성 파일이 너무 길어서 효율적으로 관리할 수 없고 논리적 분리가 관리를 단순화할 수 있는 경우 코드를 여러 파일에 분산할 수 있습니다. 스택을 최대한 효율적으로 실행하기 위해 종속성 그래프 및 계획 프로세스가 어떻게 작동하는지 염두에 두세요.