Terraform 기본사용 1 - T101 1주차

 

가시다님이 진행하시는 T101(Terraform 101 Study) 내용 정리입니다.
스터디 내용은 테라폼으로 시작하는 IaC 책의 내용을 참고하였습니다.

테라폼 기본 사용

테라폼은 hashcorp사에서 공개한 너무나도 유명한 IaC 도구입니다.

테라폼 설치

mac os를 기준, 설치 방법입니다. tfenv는 테라폼의 다양한 버전을 사용할 수 있게 해 주는 도구입니다.

• 테라폼 설치 버전 : 1.8.5
• 테라폼 자동완성 설치

# tfenv 설치
brew install tfenv

# 설치 가능 버전 리스트 확인
tfenv list-remote

# 테라폼 1.5.1 버전 설치
tfenv install 1.8.5

# 테라폼 1.5.1 버전 사용 설정 
tfenv use 1.8.5

# tfenv로 설치한 버전 확인
tfenv list

# 테라폼 버전 정보 확인
terraform version

# 자동완성
terraform -install-autocomplete
## 참고 .zshrc 에 아래 추가됨
cat ~/.zshrc
autoload -U +X bashcompinit && bashcompinit
complete -o nospace -C /usr/local/bin/terraform terraform

HCL(HashiCorp configuration language)

HCL은 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구입니다.

간결하고 읽기 쉬운 문법을 제공합니다. 주요 블록에는 provider, resource, module, variable, output 등이 있으며, 코드 재사용성을 높이기 위해 모듈화를 지원합니다. HCL을 사용하면 인프라의 배포, 수정, 삭제 작업을 자동화하고 일관성을 유지할 수 있습니다.

테라폼 블록

테라폼 구성을 명시하는데 사용하는 데 사용합니다.

테라폼 블록

테라폼 버전이나 프로바이더 버전을 명시적으로 선언하고 코드 오류를 최소화하도록 합니다

다음은 테라폼 1.0.0 이하의 버전을 요구하도록 설정합니다. 1.8.5 버전의 테라폼에서는 에러를 발생하는 것을 보여줍니다.

다음은 프로바이더 버전을 너무 과하게 설정하였을때 에러가 나는 것을 보여줍니다.

백엔드 블록 

• 백엔드 블록의 구성은 테라폼 실행 시에 저장되는 State(상태파일)의 저장 위치를 선언합니다.
• 주의할 점은 하나의 백엔드만 허용합니다.
• 백엔드를 지정하지 않으면 기본 백엔드는 로컬입니다.
• 테라폼은 State의 데이터를 사용해 코드로 관리된 리소스를 탐색하고 추적합니다.
• 작업자 간의 협업과 보안을 고려한다면 리소스 상태 저장 파일을 공유 할 수 있는 외부 백엔드 저장소가 필요합니다.

테라폼은 실행되는 동안 .terraform.tfstate.lock.info 파일이 생성되면서 해당 State를 동시에 사용하지 못하도록 잠금 처리를 합니다.

잠금파일의 내용

 

백엔드가 설정되면 다시 init 명령을 수행해 State의 위치를 재설정해야 합니다.

# init 시 백엔드 변경에 따른 마이그레이션 안내
terraform init
...
Enter a value: yes
...

#
ls terraform.tfstate*
tree state
cat state/terraform.tfstate | jq
cat state/terraform.tfstate | jq -r .serial

# 
terraform apply -auto-approve

# 코드 파일 수정 
terraform {
  backend "local" {
    path = "state/terraform.tfstate"
  }
}

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

# apply
terraform plan
terraform apply -auto-approve

리소스

리소스는 테라폼을 통해 관리되는 인프라 구성 요소를 정의하는 핵심 요소입니다.

리소스 형식

리소스 블록이 생성할 리소스 유형을 정의합니다. 리소스 유형은 프로바이더가 제공하는 다양한 리소스 유형이 존재합니다. 이름은 사용자가 자유롭게 정의하는 이름입니다.

resource "<리소스 유형>" "<이름>" {
  <인수> = <값>
}

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

리소스 실습

AWS 프로바이더의 EC2 인스턴스를 생성하는 리소스를 실습합니다.

# main.tf 파일 작성
resource "local_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

resource "aws_instance" "web" {
  ami = "ami-a1b2c3d4"
  instance_type = "t2.micro"  
}

# init 시 프로바이더 선언 없이도 리소스 추가로 자동 인식된 프로바이더 요구사항과 초기화
terraform init
terraformr apply

종속성

인프라 프로비저닝을 하다 보면, 종속성이 있는 인프라 간에 작업 실행 순서에 따라 영향을 끼치는 경우가 많습니다.

테라폼 종속성은 resource,module 선언으로 프로비저닝 되는 각 요소의 생성 순서를 구분짓습니다.(테라폼 코드 실행 순서)

종속성 실습

다음은 정의한 content 내용의 로컬 파일을 생성하는 테라폼 코드입니다. 서로 관계없는 다른 파일을 생성하는 로직으로, 병렬로 동시에 실행이 됩니다.

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

resource "local_file" "def" {
  content  = "456!"
  filename = "${path.module}/def.txt"
}


# 
terraform apply -auto-approve

# 리소스 확인
ls *.txt
terraform state list
local_file.abc
local_file.def

abc 파일의 내용을 가져와 def 파일의 내용을 참조하는 종속성이 있는 리소스입니다.

테라폼은 기본적으로 암시적으로 종속성부여하여 처리합니다. graph 명령어를 통해 의존성을 그래프로 확인할 수도 있습니다.

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"
}

#
terraform apply -auto-approve
... abc 먼저 만들고 def 파일을 만듬 
Plan: 2 to add, 0 to change, 0 to destroy.
local_file.abc: Refreshing state... [id=5f30576af23a25b7f44fa7f5fdf70325ee389155] 
local_file.def: Refreshing state... [id=5f30576af23a25b7f44fa7f5fdf70325ee389155]

ls *.txt
terraform state list
cat abc.txt
cat def.txt
diff abc.txt def.txt

# graph 확인 > graph-2.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph
terraform graph > graph-2.dot

terraform graph

depends_on

리소스의 속성을 주입하지 않아도 두 리소스 간에 종속성이 필요한 경우에, depends_on 선언으로 적용 가능합니다.

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

resource "local_file" "def" {
  depends_on = [
    local_file.abc
  ]

  content  = "456!"
  filename = "${path.module}/def.txt"
}

terraform graph - depends_on

리소스 속성 참조

Terraform에서 리소스 속성 참조는 다른 리소스나 리소스 속성을 참조하여 특정 리소스의 속성 값을 설정하거나 사용하는 것을 말합니다. 이는 인프라 구성을 정의할 때 특히 유용합니다. 다른 리소스의 ID 또는 속성을 가져와 사용하여 연결하거나 구성할 수 있습니다.

 

예를 들어, 쿠버네티스 프로바이더의 Namespace 리소스를 생성하고 이후 Secret을 해당 Namespace에 생성하고 싶다고 가정할 때, 활용할 수 있습니다. 시크릿은 네임스페이스의 리소스를 참조하여 가져오기 때문에 휴먼 에러를 줄일 뿐만 아니라, 유지보수에도 용이합니다.

resource "kubernetes_namespace" "example" {
  metadata {
    annotations = {
      name = "example-annotation"
    }
    name = "terraform-example-namespace"
  }
}

resource "kubernetes_secret" "example" {
  metadata {
    namespace = kubernetes_namespace.example.metadata.0.name # namespace 리소스 인수 참조
    name      = "terraform-example"
  }
  data = {
    password = "P4ssw0rd"
  }
}

수명주기(LifeCycle)

• lifecycle은 리소스의 기본 수명주기를 작업자가 의도적으로 변경하는 메타인수입니다.
  • create_before_destroy (bool): 리소스 수정 시 신규 리소스를 우선 생성하고 기존 리소스를 삭제
  • prevent_destroy (bool): 해당 리소스를 삭제 Destroy 하려 할 때 명시적으로 거부
  • ignore_changes (list): 리소스 요소에 선언된 인수의 변경 사항을 테라폼 실행 시 무시
  • precondition: 리소스 요소에 선언해 인수의 조건을 검증
  • postcondition: Plan과 Apply 이후의 결과를 속성 값으로 검증

create_before_destroy

테라폼은 기본적으로 리소스를 수정할 때 기존 리소스를 삭제하고 생성합니다.

작업자가 의도적으로 리소스 수정 시, 신규 리소스를 우선 생성하고 기존 리소스를 삭제할 수 있습니다.

이와 같이 create_brefore를 true로 설정하면 다운타임을 최소화하고 서비스 가용성을 유지하는 데 유용합니다.

예를 들어, 로드벨런서 교체 시에 새 로드 밸런서를 먼저 생성하여 트래픽을 새로운 로드 밸런서로 전환한 후, 기존 로드 밸런서를 삭제함으로써 다운타임을 방지할 수 있습니다.

prevent_destroy

해당 리소스를 destroy(삭제)하려 할 때 명시적으로 거부합니다.

ignore_changes

리소스 요소에 선언된 인수의 변경 사항을 테라폼 실행 시 무시하여, 수정 계획에 변경 사항이 반영되지 않도록 합니다.

 

precondition 

리소스 생성, 업데이트, 또는 삭제 작업이 실행되기 전에 특정 조건이 충족되는지 확인하는 데 사용됩니다. 이 기능은 인프라의 안정성을 높이고 예상치 못한 변경으로 인한 문제를 방지하는 데 유용합니다.

 

PostCondition

리소스가 생성, 업데이트, 또는 삭제된 후 특정 조건이 충족되는지 확인하는 데 사용됩니다. 이 기능은 변경 후 리소스 상태가 예상한 대로 되었는지 검증하는 데 유용하며, 예상치 못한 결과를 방지하는 데 도움을 줍니다.

예외 조건 발생