[Terraform] 기본 사용법 #2 (테라폼 블록, 리소스)

💡cloudNet@ 팀의 가시다 님이 진행하는 Terraform 101 Study 4기 1주차 내용으로,
[테라폼으로 시작하는 IaC] 도서를 참조하였습니다. 감사합니다..

 

1. 테라폼 블록

테라폼 블록은 테라폼의 구성을 명시하는데 사용된다. 테라폼 버전이나 프로바이더 버전과 같은 값들은 자동으로 설정되지만, 다른 사람과 함께 작업할 때는 버전을 명시적으로 선언하고 필요한 조건을 입력하여 실행 오류를 최소화해야한다.

(또한 협업의 관점에서 보았을 때, 다른 사람이 실행하는 경우에 대비해 테라폼의 구성 정보를 명확히 정의해야 오류 등을 방지할 수 있다.)

terraform {
  required_version = "~> 1.3.0" # 테라폼 버전

  required_providers { # 프로바이더 버전을 나열
    random = {
      version = ">= 3.0.0, < 3.1.0"
    }
    aws = {
      version = "4.2.0"
    }
  }

  cloud { # Cloud/Enterprise 같은 원격 실행을 위한 정보
    organization = "<MY_ORG_NAME>"
    workspaces {
      name = "my-first-workspace"
    }
  }

  backend "local" { # state를 보관하는 위치를 지정
    path = "relative/path/to/terraform.tfstate"
  }
}

• 명심할 것은, 언제 실행하던지 동일한 결과를 얻을 수 있어야 한다!

그리고 잠시 버전 표기에 대해 설명하겟다.

테라폼 내에서 버전이 명시되는 terraform, module에서 사용이 가능하며 버전에 대한 제약을 둠으로 테라폼, 프로바이더, 모듈이 항상 의도한 정의대로 실행되는 것을 목적으로 한다.

버전 체계는 *시멘틱 버전 관리 방식을 따른다.

• 시멘틱 버저닝이란? : 버전 표현 방식 중 하나로, 숫자 3자리로 버전을 표현한다. ex, 1.3.4

# version = Major.Minor.Patch
version = 1.3.4

시멘틱 버전 관리 방식을 이해하면 업그레이드 시 영향도를 추측할 수 있다.

• Major 버전 : 내부 동작의 API가 변경 또는 삭제되거나 하위 호환이 되지 않는 버전
• Minor 버전 : 신규 기능이 추가되거나 개선되고 하위 호환이 가능한 버전
• Patch 버전 : 버그 및 일부 기능이 개선된 하위 호환이 가능한 버전

버전 제약 구문은 다름 프로그램 언어에서의 종속성 관리 시스템과 흡사하다.

• = 또는 연산자 없음 : 지정된 버전만을 허용하고 다른 조건과 병기할 수 없다.
• != : 지정된 버전을 제외한다.
• >, >=, <, <= : 지정된 버전과 비교해 조건(부등호)에 맞는 경우 허용한다.
  • ~> : 지정된 버전에서 가장 자리수가 낮은 구성요소만 증가하는 것을 허용한다.
    • ~> x.y 인 경우 y 버전에 대해서만, ~> x.y.z인 경우 z 버전에 대해서만 보다 큰 버전을 허용한다
• 테라폼 버전 관리로 비유된 선언 방식의 의미

선언된 버전	의미	고려 사항
1.0.0	테라폼 v1.0.0만을 허용한다	테라폼을 업그레이드하기 위해서는 선언된 버전을 변경해야만 한다
>= 1.0.0	테라폼 v1.0.0 이상의 모든 버전을 허용한다	v1.0.0 버전을 포함해 그 이상의 모든 버전을 허용해 실행된다
~> 1.0.0.	테라폼 v1.0.0을 포함한 v1.0.x 버전을 하용하고 v1.x는 허용하지 않는다	부버전에 대한 업데이트는 무중단으로 이루어진다
>= 1.0, < 2.0.0	테라폼 v1.0.0 이상 v2.0.0 미만인 버전을 허용한다	주버전에 대한 업데이트를 방지한다

 

1.1 테라폼 버전

required_version 으로 정의되는 테라폼 버전은 지정된 조건과 일치하지 않는 경우 오류를 출력하고 이후 동작을 수행하지 않는다.

required_version으로 제어되는 버전 제한을 확인해보기 위해 main.tf에 terraform 블록과 관련된 값을 추가해본다.

사진-1

• 현재 테라폼 버전 확인

 

사진-2

• main.tf 코드파일을 수정 후 init 명령 실행 결과

 

사진-3

• 실행 환경 버전에 대한 조건을 변경하고 다시 진행하니 정상적으로 동작한다.

 

1.2 프로바이더 버전

테라폼 0.13 버전 이전에서는 provider 블록에 함께 버전을 명시했지만, 해당 버전 이후 프로바이더의 버전은 terraform 블록에서 reauired_providers에 정의한다.

 

 

테라폼 레지스트리 공식 페이지에서 원하는 프로바이더를 선택하면 테라폼 코드에 해당 버전을 사용하는 샘플 코드가 나타난다.

사진-4

프로바이더 버전이 동작하는 것을 확인해보겠다.

terraform 블록에 required_providers 값을 추가해본다.

(의도적으로 프로바이더 버전을 제한하는 테스트로, 현재 실행되는 버전보다 많이 높게 설정해봤다.)

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = ">=10000.0.0"
    }
  }
}

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

사진-5

실제 사용 가능한 해당 버전의 프로바이더가 없어 init 명령이 실패했다.

제대로 실행시키기 위해 version을 2.0.0 으로 수정하여 진행해보겠다.

사진-6

 

1.3 Cloud 블록

Terraform Cloud, Terraform Enterprise는 CLS, VCS, API 기반의 실행 방식을 지원하고 cloud 블록으로 선언한다.

• cloud 블록은 1.1 버전에 추가되었고, 기존에는 State 저장소를 의미하는 backend의 remote 항목으로 설정했다.
• hostname의 기본값이 app.terraform.io를 가리키며, 해당 주소는 테라폼 클라우드의 URL이다.

 

 

1.4 백엔드 블록 State

백엔드 블록의 구성은 테라폼 실행 시 저장되는 State(상태 파일)의 저장 위치를 선언한다.

주의할 점은, 하나의 백엔드만 허용한다는 점이다. 테라폼은 state의 데이터를 사용해 코드로 관련된 리소스를 탐색하고 추적한다.

(작업자 간의 협업을 고려하면, 외부 백엔드 저장소가 필요하다. 테라폼으로 생성한 리소스의 상태 저장 파일을 공유해야 하기 때문이다.)

그리고 state에는 외부로 노출되면 안되는 패스워드 또는 인증서 등 민감한 데이터를이 포함될 수 있기 때문에 state의 접근 제어가 필요하다.

 

state 잠금 동작

기본적으로 활성화되는 백엔드는 local이다. 상태를 작업자의 로컬 환경에 저장하고 관리하는 방식이다.

이 밖에 다른 백엔드 구성은 동시에 여러 작업자가 접근해 사용할 수 있도록 공유 스토리지 같은 개념을 갖는다. 공유되는 백엔드에 state가 관리되면 테라폼이 실행되는 동안 .terraform.tfstate.lock.info 파일이 생성되며 해당 state를 동시에 사용하지 못하도록 잠금 처리를 한다.

한번 terraform apply를 실행하여 잠금 파일이 생성되는 것을 확인해보겠다.

{"ID":"8b7f68ed-648c-7644-f15e-22d90636e368","Operation":"OperationTypeApply",
"Info":"","Who":"devcw@woos-dev-server","Version":"1.8.5","Created":"
2024-06-15T08:13:19.029830824Z","Path":"terraform.tfstate"}

• apply 동작 시 생성되는 잠금 파일 내용

첫 번째 터미널에서 apply를 진행하고 대기중인 상태에서, 다른 터미널을 열어 apply를 실행시켜 보겠다.

사진-7

• 두 번째로 실행한 terraform apply 에서는 다른 테라폼 실행으로 state가 잠겼다고 나타난다.

동시에 동일한 state에 접근이 발생했으므로, 잠금 파일의 내용이 표기되며 에러가 발생하였다.

매세지에 나타난 -lock=false 옵션으로 잠금을 무시할 수 있으나, 주의가 필요하다.

 

백엔드 설정 변경

백엔드가 설정되면 다시 init 명령을 통해 state의 위치를 재설정해야 한다.

백엔드 블록에 local를 정의하여 init 명령을 수행한다.

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

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

 

2. 리소스

리소스는 테라폼이 프로비저닝 도구라는 측면에서 가장 중요한 요소다. 리소스 블록은 선언된 항목을 생성하는 동작을 수행한다.

 

2.1 resoruce 리소스 구성

리소스 블록은 resource로 시작한다. 이후 리소스 블록이 생성할 리소스 유형을 정의한다.

• 리소스 이름의 의미 : 프로바이더이름_프로바이더소스유형
• 리소스 유형이 선언되면 뒤에는 고유한 이름을 붙인다. 이름은 동일한 유형에 대해 식별자 역할을 하기 때문에 동일한 이름을 사용할 수 없다.
• 이름 뒤에는 리소스 유형에 대한 구성 인수들이 중괄호 내에 선언된다.(유형 인수가 필요하지 않더라도 중괄호는 입력한다)

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

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

리소스에서 사용되는 유형들은 프로바이더에 종속성을 갖는다. 특정 프로바이더의 유형만 추가해도 terraform init를 수행하면 해당 프로바이더를 설치한다.

기존 main.tf에 aws_instance 유형을 추가하고 init을 수행해보겠다.

# main.tf
resource "**local**_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

resource "**aws**_instance" "web" {
  ami = "ami-a1b2c3d4"
  instance_type = "t2.micro"  
}

사진-8

AWS 프로바이더 선언 없이도 설치가 진행되는 것을 확인할 수 있다.

(보통 프로바이더에 따라 접속 정보나 필수 인수를 선언해야 하는 경우가 있으므로, 일반적으로는 프로바이더 구성과 함께 사용해야 한다.)

프로바이더와 리소스 유형은 테라폼 레지스트리 페이지에서 확인할 수 있고, 이후 포스팅해보겠다.

• 리소스 동작 보조 추가 메타인수를 정의 할 수 있다.
  • depends_on : 종속성을 선언하며, 선언된 구성요소와의 생성 시점에 대해 정의
  • count : 선언된 개수에 따라 여러 리소스를 생성
  • for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
  • provider : 동일한 프로바이더가 다수 정의되어 있는 경우 지정
  • lifecycle : 리소스의 수명주기 관리
  • provisioner : 리소스 생성 후 추가 작업 정의
  • timeouts : 프로바이더에서 정의한 일부 리소스 유형에서는 create, update, delete에 대한 허용 시간 정의 가능

 

2.2 종속성

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

기본적으로 다른 리소스에서 값을 참조해 불러올 경우 생성 선후 관계에 따라 작업자가 의도하지 않았지만 자동으로 연관 관계가 정의되는 암시적 종속성을 가지게 되고, 강제로 리소스 간 명시적 종속성을 부여할 경우에는 메타인수인 depends_on을 활용한다.

—> 즉, 리소스의 생성 순서 등을 지정할 수 있고, 생성 시 선후 관계가 명확한 경우 따로 지정하지 않아도 자동으로 정의되어 진행된다는 것 같다.

실습에 앞서, graph의 결과를 시각화 할 수 있는 graphviz를 설치한다.

사진-9

 

 

기존에 선언된 내용은 삭제하고 main.tf에 다음과 같이 두 개의 요소를 선언한다.

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

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

두 리소스 구성요소는 서로 선후 관계가 없는 동일한 수준이므로, 테라폼의 병렬 실행 방식에 따라 apply를 실행하면 동시에 수행된다.

사진-10

• 동시에 실행되는 것을 확인할 수 있다.

(지금 graphviz가 안먹혀서 이미지로 확인할 수 없다.. 추후 해결되면 수정하도록 하겠다.)

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

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

다음엔 리소스 속성을 다른 리소스에 주입하여 종속성을 부여해보겠다.

사진-11

결과를 확인하면 특정 리소스의 속성 값이 필요한 경우 해당 리소스가 우선적으로 생성되어야 하므로 생성시 순서가 발생되었다.

두 리소스 구성에 종속성이 없는 경우에는 프로바이더에 대한 종속성만이 존재하지만 위 코두에서 local_file def는 local_file abc 값을 참조해야 하므로 순서에 대한 종속이 발생함을 확인할 수 있다.

 

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

 

2.3 리소스 속성 참조

리소스 구성에서 참조 가능한 값은 인수와 속성이다

• 인수 : 리소스 생성 시 사용자가 선언하는 값
• 속성 : 사용자가 설정하는 것은 불가능하지만 리소스 생성 이후 획득 가능한 리소스 고유 값

리소스의 인수와 속성은 다음과 같이 접근할 수 있다.

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

# 리소스 참조
<리소스 유형>.<이름>.<인수>
<리소스 유형>.<이름>.<속성>

• 리소스 인수의 선언과 참조 가능한 인수 및 속성 패턴

아래 코드는 쿠버네티스 프로바이더의 Namespace 리소스를 생성하고 이후 Secret을 해당 Namespace에 생성하는 종속성을 리소스 인수 값 값으로 생성하는 예이다. Namespace의 이름만 변경해도, 해당 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"
  }
}

• 리소스가 생성될 때, 사용자가 입력한 ‘인수’를 받아 실제 리소스가 생성되면 일부 리소스는 자동으로 기본값이나 추가되는 ‘속성’이 부여된다.
• 각 리소스마다 문서를 확인해보면 인수는 Arguments로 표현되어 있으며, 리소스 생성 후 추가되는 속성 값으로 Attributes에 안내되어 있다
• 리소스 속성을 참조하는 다른 리소스 또는 구성요소에서는 생성 후의 속성 값들도 인수로 가져올 수 있다.

 

2.4 수명주기

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

 

create_before_destroy

리소스 수정 시 리소스 특성에 따라 대상을 삭제하고 다시 생성해야 하는 경우가 있다. 대표적으로 클라우드의 image가 변경되는 경우에는 해당 VM의 리소스를 삭제하고 다시 생성한다.

• 테라폼의 기본 수명주기는 삭제 후 생성이기 때문에 작업자가 의도적으로 수정된 리소스를 먼저 생성하기를 원할 수 있다.

이 경우 create_before_destroy가 true로 선언되면 지정한 생성을 실행한 후 삭제를 동작한다.

주의 !

하지만 생성되는 리소스가 기존 리소스로 인해 생성이 실패되거나 삭제 시 함께 삭제될 수 있으니 주의해야 한다.

• 잘못된 사례 1 : 리소스의 명시적 구분이 사용자가 지정한 특정 이름이나 ID인 경우 기존 리소스에 할당되어 있기 때문에 생성 실패
• 잘못된 사례 2 : 생성 후 삭제 시 동일한 리소스에 대한 삭제 명령이 수행되어 리소스가 모두 삭제

실습을 통해 잘못된 사례를 확인해보겠다.

resource "local_file" "abc" {
  content  = "lifecycle - step 1"
  filename = "${path.module}/abc.txt"

  lifecycle {
    create_before_destroy = false
  }
}

• main.tf 파일

# 모니터링
cd 03.lifecycle
watch -d 'ls -l;echo;cat abc.txt'

# apply 
terraform init && terraform plan && terraform apply -auto-approve
terraform state list

# 파일 내용 확인
cat abc.txt
# 파일 내용
lifecycle - step 1

content 내용을 수정하여 테스트한다.

resource "local_file" "abc" {
  content  = "lifecycle - step **1111111111111111**"
  filename = "${path.module}/abc.txt"

  lifecycle {
    **create_before_destroy = false**
  }
}

사진-12

• create_before_destroy - flase 동작이 확인된다.

 

prevent_destroy

작업자가 의도적으로 특정 리소스의 삭제를 방지하고 싶은 경우 사용한다.

main.tf 파일을 다음과 같이 수정하였다.

resource "local_file" "abc" {
  content  = "lifecycle - step 3"
  filename = "${path.module}/abc.txt"

  lifecycle {
    **prevent_destroy = true**
  }
}

이후 apply를 진행하였더니 다음과 같이 에러가 발생하였다.

사진-13

원인은? : 기존에 steb2 content를 지정하여 생성이 되어있는 상황이다. 테라폼은 선언적인 특성을 가지고 있기 때문에, 리소스를 삭제했다가 다시 생성하는 개념이다. prevent_destory를 명시하여 삭제를 방지하였기 때문에, abc 파일이 삭제되지 않은것이다. (틀렸다면 알려주세요..)

사진-14

• prevent_destory를 없애고 진행하니 정상적으로 변경된다.

 

ignore_changes (list)

리소스 요소의 인수를 지정해 수정 계획에 변경 사항이 반영되지 않도록 한다.

테라폼 코드를 다음과 같이 작성하여 확인해보겠다.

resource "local_file" "abc" {
  content  = "lifecycle - step 4"
  filename = "${path.module}/abc.txt"

  lifecycle {
    **ignore_changes = []**
  }
}

사진-15

• 잘 변경되었다. 다음은 content를 추가하여 진행해보겠다.

resource "local_file" "abc" {
  content  = "lifecycle - step 5"
  filename = "${path.module}/abc.txt"

  lifecycle {
    **ignore_changes = [
      content**
    ]
  }
}

사진-16

리소스 속성에 변경이 있었지만, ignore_changes의 대상이므로 실행계획에 변경 사항이 포함되지 않아 변경이 발생하지 않았다.

(모든 변경 사항을 무시하고 싶다면 ignore_changes = all 로 설정하면 된다.)

 

precondition

리소스 생성 이전에 입력된 인수 값을 검증한다.

프로비저닝 이전에 미리 약속된 값 또는 필수로 명시해야 하는 인수 값을 검증할 수 있다.

사진-17

• precondition 조건에 맞지 않은 경우 에러가 발생한다.

precondition은 프로비저닝해야 하는 클라우드 VM이나 내부적으로 검증된 이미지를 사용하는지, 암호화 설정이 되어 있는지 등 구성을 미리 확인하고 잘못된 프로비저닝을 실행할 수 없도록 구성할 수 있다.

 

postcondition

프로비저닝 변경 이후 결과를 검증함과 동시에 의존성을 갖는 다름 구성의 변경을 막는 효과가 있다.

사진-18

• prostcondition 조건에 맞지 않아 에러가 발생하였다. (precondition와 달리 프로비저닝 이후 생성되는 속성 값이 상이하여 차단되었다.)

사진-19

content에 값을 추가하니, 정상적으로 실행되었다.

종속성을 갖는 여러 리소스를 구성하는 경우, 리소스의 데이터가 다른 리소스 생성 시 활용될 때 원하는 속성이 정의되어야 하는 경우 유용하다.

• 특히 , 프로비저닝 이후 생성되는 속성 값이 있으므로 영향을 받는 리소스가 생성되기 전 예상되지 않는 프로비저닝 작업을 방지할 수 있다.