[Terraform] Block 사용법 - 1 (테라폼 블록, 리소스 블록)

Terraform을 활용한 본격적인 인프라를 구성에 앞서,
TF 파일 작성을 위한 문법 및 구성 요소, 사용법에 대해 정리해보려 한다.

블록의 종류

사진과 같이 다양한 블록들이 있다. 그중 가장 많이 사용하게 되는 것들을 위주로 설명해보려한다.

1. 테라폼 블록

terraform {
  required_version = ">= 1.8.0"  # terraform 버전
  
  required_providers {           # provider 버전
    
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45.0"
    }
    
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 2.99.0"
    }
  }
  
}

• 테라폼의 구성 명시 (테라폼 버전, 프로바이더 버전...)
• terraform, provider의 버전은 자동으로 설정됨
• 버전 및 필요조건을 명시적으로 선언하는 경우
  -> 타인과 작업시 오류 최소화를 위해

1-1. 테라폼 버전

• 테라폼 블록의 required_version에 정의

">= 1.0.0" : 테라폼 v1.0.0 이상 모든 버전 허용
"~> 1.0.0" : 테라폼 v1.0.0 포함 ~ v1.0.x 버전 허용, v1.x.x 비허용
">= 1.0 < 2.0.0" : 테라폼 v1.0.0 이상 v2.0.0미만 버전 허용

1-2. 프로바이더 버전

• 테라폼 블록의 required_providers 에 정의
• 전엔 provider 블록에 함께 버전 명시 하였음
• 프로바이더 버전은 https://registry.terraform.io/browse/providers 에서 확인 가능

ex)

required_providers {           # provider 버전
    
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45.0"
    }
    
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 2.99.0"
    }
  }

1-3. 백엔드 블록

• 테라폼 실행시 저장되는 State 파일(상태 파일) 의 저장 위치 선언
• 주의 : 하나의 백엔드만 허용!!
• 기본 백엔드 : local -> 협업 시 외부 벡엔드 저장소(공유 스토리지) 필요

State (상태 파일)

• 테라폼은 State의 데이터를 사용해 코드로 관리된 리소스를 탐색 및 추적
• 민감한 정보 포함(PW, 인증서 정보..) -> State 접근 제어 필요!
• State 관리시, lock.info 파일 생성으로 잠금 처리 -> 동시 사용 제한
• 벡엔드 전환 = State 관리 저장소 선택
• 벡엔드 변경시 terraform init 으로 State 위치 재설정 필요

ex)

backend "local" {
  path = "state/terraform.tfstate"
}

2. 리소스 블록

resource "<프로바이더이름_리소스 유형>" "<이름>" {
  <인수> = <값>
}

resource "local_file" "abc" {      # local 파일
  content = "123!"
  filename = "${path.module}/abc.txt"
}

resource "aws_instance" "web" {     # aws ec2 인스턴스
  ami = "ami-a1b2c3d4"
  instance_type = "t2.micro"
}

• 자원에 대한 정의 (AWS 자원 등...)
• 선언된 자원을 생성하는 동작 수행
  
  

2-1. 리소스 종속성

• 각 요소의 생성 순서를 구분
• 다른 리소스에서 값을 참조해 불러올 경우, 생성 선후 관계에 따라 자동으로 연관 관계 정의 (암시적 종속성)
• depends_on : 강제로 리소스간 명시적 종속성 부여 인수
• 특정 리소스 속성 값이 필요한 경우, 리소스 우선 생성이 필요
  -> 종속성 발생 = 프로비저닝 순서 발생

ex)

resource "local_file" "abc" {      
  content = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {      
  content = local_file.abc.content       # 암시적 종속성 발생  
  filename = "${path.module}/def.txt"
}

resource "local_file" "xyz" {      
  depends_on = [        # 명시적 종속성 발생
    local_file.abc
  ]
  content = "789!" 
  filename = "${path.module}/xyz.txt"
}

• 암시적 종속성: abc.txt -> def.txt 생성
• 명시적 종속성: abc.txt -> xyz.txt 생성
  
  

2-2. 수명주기(lifecycle)

수명주기 옵션 인수

create_before_destroy (bool) : 리소스 수정시 신규 리소스 우선 생성 후 기존 리소스 삭제
prevent_destroy (bool) : 해당 리소스 삭제(destroy)시 명시적으로 거부
ignore_changes (list) : 리소스 요소에 선언된 인수 변경사항을 테라폼 실행 시 무시
precondition : 리소스 요소에 선언된 인수의 조건 검증
postcondition : plan 과 apply 이후 결과를 속성 값으로 검증

ex)

resource "local_file" "abc" {      
  content = "123!"
  filename = "${path.module}/abc.txt"
  
  lifecycle {
    create_before_destroy = true     # 신규 리소스 생성후 기존 리소스 삭제
  }
  
}

출처 : [한빛미디어] 테라폼으로 시작하는 IaC