테라폼 모듈에 대한 이해

코드형 인프라 (IaC) 영역에서 모듈은 재사용을 위해 격리되고 함께 패키징되는 독립형 코드 블록입니다. 모듈의 개념은 Terraform 개발에서 피할 수 없는 부분입니다. 자세한 내용은 Terraform 설명서의 모듈을 참조하십시오. AWS CloudFormation 모듈도 지원합니다. 자세한 내용은 AWS 클라우드 운영 및 마이그레이션 블로그의 AWS CloudFormation 모듈 소개를 참조하십시오.

Terraform의 모듈 간의 주요 차이점은 특수 리소스 유형 () 을 사용하여 CloudFormation 모듈을 가져온다는 것입니다. CloudFormation AWS::CloudFormation::ModuleVersion Terraform의 모든 구성에는 루트 모듈이라는 모듈이 하나 이상 있습니다. 기본.tf 파일에 있는 테라폼 리소스 또는 Terraform 구성 파일의 파일은 루트 모듈에 있는 것으로 간주됩니다. 그러면 루트 모듈이 다른 모듈을 호출하여 스택에 포함할 수 있습니다. 다음 예제는 오픈 소스 eks 모듈을 사용하여 Amazon Elastic Kubernetes Service (Amazon EKS) 클러스터를 프로비저닝하는 루트 모듈을 보여줍니다.

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 모듈 구성이 요구 사항에 맞으면 이를 사용하면 수십 줄의 코드를 추가로 작성하지 않아도 됩니다.

모듈 호출

Terraform 배포 중에 실행하는 두 가지 기본 Terraform CLI 명령은 테라폼 초기화와 테라폼 적용입니다. 이 terraform init 명령이 수행하는 기본 단계 중 하나는 모든 하위 모듈을 찾아 종속 항목으로 디렉터리로 가져오는 것입니다. .terraform/modules 개발 중에 외부 소스 모듈을 새로 추가할 때마다 명령을 사용하기 전에 다시 초기화해야 합니다. apply Terraform 모듈에 대한 참조를 들으면 이 디렉터리의 패키지를 참조하는 것입니다. 엄밀히 말하면 코드에서 선언하는 모듈은 호출 모듈이므로 실제로는 module 키워드가 실제 모듈을 호출하며, 이 모듈은 종속성으로 저장됩니다.

이런 식으로 호출 모듈은 배포 시 교체될 전체 모듈을 보다 간결하게 나타내는 역할을 합니다. 원하는 기준을 사용하여 스택 내에 자체 모듈을 만들어 리소스를 논리적으로 분리함으로써 이 아이디어를 활용할 수 있습니다. 단, 이 작업의 최종 목표는 스택 복잡성을 줄이는 것이어야 한다는 점만 기억하세요. 모듈 간에 데이터를 공유하려면 모듈 내에서 해당 데이터를 출력해야 하기 때문에 모듈에 너무 많이 의존하면 상황이 지나치게 복잡해질 수 있습니다.

루트 모듈

모든 Terraform 구성에는 적어도 하나의 모듈이 있으므로 가장 많이 다루게 될 모듈인 루트 모듈의 모듈 속성을 검사하는 데 도움이 될 수 있습니다. Terraform 프로젝트를 작업할 때마다 루트 모듈은 최상위 디렉터리의 모든 .tf (또는.tf.json) 파일로 구성됩니다. 최상위 terraform apply 디렉토리에서 실행하면 Terraform은 해당 디렉토리에서 찾은 모든 파일을 실행하려고 시도합니다. .tf 하위 디렉터리의 모든 파일은 이러한 최상위 구성 파일 중 하나에서 호출되지 않는 한 무시됩니다.

이렇게 하면 코드를 어느 정도 유연하게 구성할 수 있습니다. 단일 프로세스에 여러 파일이 포함될 수 있기 때문에 Terraform 배포를 파일보다 모듈이라고 부르는 것이 더 정확한 이유이기도 합니다. Terraform이 모범 사례로 권장하는 표준 모듈 구조가 있습니다. 하지만 최상위 디렉터리에 .tf 파일을 넣으면 나머지 파일과 함께 실행됩니다. 실제로 모듈을 실행하면 모듈의 모든 최상위 .tf 파일이 배포됩니다. terraform apply 그렇다면 Terraform은 어떤 파일을 가장 먼저 실행할까요? 이 질문에 대한 답은 매우 중요합니다.

Terraform은 초기화 후와 스택 배포 전에 수행하는 일련의 단계가 있습니다. 먼저 기존 구성을 분석한 다음 종속성 그래프를 생성합니다. 종속성 그래프는 어떤 리소스가 필요하고 어떤 순서로 처리해야 하는지를 결정합니다. 예를 들어 다른 리소스에서 참조되는 속성을 포함하는 리소스는 종속 리소스보다 먼저 처리됩니다. 마찬가지로 depends_on 파라미터를 사용하여 명시적으로 종속성을 선언한 리소스는 지정한 리소스보다 먼저 처리됩니다. 가능한 경우 Terraform은 병렬 처리를 구현하고 비종속 리소스를 동시에 처리할 수 있습니다. 배포하기 전에 terraform graph 명령을 사용하여 종속성 그래프를 볼 수 있습니다.

종속성 그래프가 생성된 후 Terraform은 배포 중에 수행해야 할 작업을 결정합니다. 종속성 그래프를 최신 상태 파일과 비교합니다. 이 프로세스의 결과를 계획이라고 하며 이는 CloudFormation 변경 세트와 매우 비슷합니다. terraform plan 명령을 사용하면 현재 계획을 볼 수 있습니다.

가장 좋은 방법은 표준 모듈 구조에 최대한 가깝게 유지하는 것이 좋습니다. 구성 파일이 너무 길어서 효율적으로 관리할 수 없고 논리적 분리가 관리를 단순화할 수 있는 경우 코드를 여러 파일에 분산할 수 있습니다. 스택을 최대한 효율적으로 실행하기 위해 종속성 그래프 및 계획 프로세스가 어떻게 작동하는지 염두에 두세요.