Terraform 코드를 구조화하는 간단한 방법

기본 구조

Terraform 코드를 작성하는 것은 네트워크 스위치에 전선을 연결하는 것과 같지만(저는 네트워크 엔지니어가 아닙니다) 감정을 얻습니다(전선이 얼마나 나빠질 수 있는지 모두 알고 있습니다).

Terraform 코드 작성을 시작하면 일반적으로 모든 것이 동일한 폴더에 있으므로 인스턴스가 적은 프로젝트나 프로젝트를 빠르게 시작해야 하는 경우에 유용할 수 있습니다.

귀하의 구조는 다음과 같습니다.

.
 backend.tf
 db-instance.tf
 iam.tf
 igw.tf
 provider.tf
 s3.tf
 subnets.tf
 variables.tf
 vpc.tf

이는 초보자 프로젝트와 소규모 프로젝트에 매우 적합하고 간단하지만 천천히 더 많은 리소스를 추가하게 되며 곧 Terraform이 코드를 변경할 때마다 20개의 리소스를 모두 새로 고침하는 것을 기다리게 될 것입니다. 이것이 이유 중 하나이고 다른 이유는 폭발 반경이라는 것이 있기 때문입니다. 폭발 반경은 기본적으로 인프라가 실수로 삭제될 수 있는 정도를 의미하는 용어입니다.

마지막이자 주된 이유는 온전한 온전함을 유지하는 것입니다(몇 가지 테라포름 공포 이야기를 읽었습니다).

더 나은 코드 작성

당신이 해야 할 일은 코드를 논리 섹션으로 나누는 것입니다. 예를 들어 "프로덕션"환경과 "비프로덕션"환경이 있습니다. 따라서 리소스를 하위 폴더로 논리적으로 분할한 두 개의 별도 폴더를 만들 수 있습니다. 이것의 라인을 따라 뭔가.

production/
 backend
    dyanmodb.tf
    outputs.tf
    s3-backend.tf
    terraform.tf
    terraform.tfvars
    variables.tf
 cloudwatch
    main.tf
    terraform.tf
    terraform.tfvars
    variables.tf
 ecs
     main.tf
     outputs.tf
     terraform.tf
     terraform.tfvars
     variables.tf

각 폴더의 파일은 Terraform Provider=>terraform.tf , Terraform code => main.tf 및 변수를 나타내며 여러 파일로 분할할 수도 있습니다.

ECS용 Terraform 구조

ECS(Elastic Container Service)와 관련하여 다음과 같은 작업을 수행하는 것이 좋습니다. 이렇게 하면 서비스가 분리되고 하나의 서비스가 변경되어도 아무 것도 변경되지 않습니다.

 ecs
    main.tf
    terraform.tf
    terraform.tfvars
    variab
 services
     service1
     service2
     service

이제 Terraform은 하나의 폴더 내에서만 작동하므로 이러한 리소스를 분할하면 어떻게 작동할지 궁금할 것입니다. 음, Terraform Remote State Data Source 으로 알려진 것이 있습니다.

이것이 어떻게 작동하는지에 대한 요지를 제공하기 위해 폴더, 즉 outputs.tf에 정의된 출력은 원격 백엔드를 통해 액세스할 수 있습니다.

이것은 network/terraform.tf 파일입니다.

network/terraform.tf

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.4.0"
    }
  }
  backend "s3" {
    key = "network/terraform.tfstate"
    bucket = "Leos-tf-prod"
    encrypt = true
    profile = "My-custom-profile"
    region = "us-west-2"
    dynamodb_endpoint = "dynamodb.us-west-2.amazonaws.com"
    dynamodb_table = "production-tf-state"

  }
 }

Note: Specifying the profile makes sure Terraform doesn't use the default profile.

이제 AWS VPC 모듈을 사용하여 리소스를 설정하겠습니다. 그런 다음 다른 폴더의 VPC ID와 같은 데이터에 액세스해야 하는 경우 outputs.tf의 Terraform 출력 블록을 사용하여 정의해야 합니다.

# VPC
output "vpc_id" {
  description = "The ID of the VPC"
  value = module.vpc.vpc_id
}

output "vpc_cidr_block" {
  description = "The CIDR block of the VPC"
  value = module.vpc.vpc_cidr_block
}

이제 그렇게 하면terraform output 값을 볼 수 있습니다.

$ terraform output

vpc_cidr_block = "20.0.118.0/17"
vpc_id = "vpc-03434c243d05599f"

계속 진행하겠습니다. 이제 내 Elastic Container Service에서 동일한 항목에 액세스해야 합니다.

이렇게 하려면 간단히 a terraform_remote_state Data Source를 다음과 같이 정의해야 합니다.

ecs/terraform.tf

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "Leos-tf-prod"
    key = "network/terraform.tfstate"
    region = "us-west-2"
    profile = "My-custom-profile"
  }
}

이제 알아차리셨다면 data.terraform_remote_state.network.vpc_cidr를 입력하면 더 많이 입력하거나 내용을 기억해야 합니다. 이를 방지하기 위해 locals를 그대로 사용할 수 있습니다.

locals {
  vpc_id = data.terraform_remote_state.network.outputs.vpc_id
  private_subnets = data.terraform_remote_state.network.outputs.public_subnets
  public_subnets = data.terraform_remote_state.network.outputs.public_subnets
}

그런 다음 폴더에서 변수를 다음과 같이 간단히 호출할 수 있습니다.

local.vpc_id

이 접근법의 이점.

폭발 반경을 줄이면 예를 들어 실수로 파괴를 실행할 경우 제한된 수의 리소스가 영향을 받습니다.

누군가가 코드의 한 부분에 대해서만 작업해야 하는 경우 보안이 향상되었습니다.

파일을 분할하면 변경 사항을 적용하는 데 걸리는 시간이 줄어듭니다.

토론을 계속하고 싶으시면 언제든지 또는 에서 저에게 연락하실 수 있습니다. Github을 팔로우하고 싶으시면 그렇게 하셔도 됩니다.

읽어 주셔서 감사합니다.