[Terraform] 기본 사용법 #3 (데이터 소스, 입력 변수)

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

 

1. 데이터 소스

데이터 소스는 테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용한다. (예를 들면 aws image 등)

 

1.1 데이터 소스 구성

데이터 소스 블록은 data로 시작된다. 이후 데이터 소스 유형을 정의한다.(resource 블록과 유사함)

 

데이터 소스 정의 예시

data "local_file" "cwtest" {
    filename = "${path.module}/cwtest.txt"
}

# ex, aws image의 경우
data "aws_iam_user" "cwdev" {
  user_name = "cwdev_name"
}

데이터 소스 유형은 첫 번째 _(언더스코어) 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형을 의미한다.

데이터 소스 유형을 선언한 뒤에는 고유 이름을 붙인다.(리소스 이름과 동일하게 중복될 수 없다)

또한 이름 뒤 데이터 소스 유형에 대한 구성 인수는 { } 안에 선언한다. 인수가 없더라도 { } 는 입력한다.

데이터 소스를 정의할 때 사용 가능한 메타인수는 다음과 같다.

• depends_on : 종속성을 선언하며, 선언된 구성요소와의 생성 시점에 대해 정의
• count : 선언된 개수에 따라 여러 데이터 소스를 선언
• for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
• provider : 동일한 프로바이더가 다수 지정되어 있는 경우 선언
• lifecycle : 데이터 소스의 수명주기 관리

 

데이터 소스 선언 테스트

이제 한번 실습 확인을 해보겠다. 로컬에 아무 파일을 생성하여 이를 데이터 소스로 선언해보겠다.

# 아무 파일을 생성한다.
echo "terraform stady cwcwpack" > cwtest.txt

# plan, apply 진행
terraform plan && terraform apply -auto-approve

# terraform 상태정보를 확인한다. cwtest 데이터 소스가 생성된 것을 확인가능하다.
terraform state list
data.local_file.cwtest

사진-1

• terraform console 확인 내용
• 정상적으로 데이터 소스 구성이 완료되어 콘솔에서도 해당 데이터 소스의 여러 정보를 가져올 수 있다.

 

1.2 데이터 소스 속성 참조

데이터 소스로 읽은 대상을 참조하는 방식은 리소스와 구별되게 앞에 data가 붙는다. 속성 값은 다음과 같이 접근할 수 있다.

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

# 데이터 소스 참조
data.<리소스 유형>.<이름>.<속성>

다음은 AWS 프로바이더의 가용영역을 사용자가 입력하지 않고 데이터 소스를 활용해 subnet 가용영역 인수를 정의하는 예시이다.

 

# Declare the data source
**data** "aws_availability_zones" "available" {
  state = "available"
}

resource "aws_subnet" "primary" {
  availability_zone = **data.aws_availability_zones.**available**.names[0]**
  # e.g. ap-northeast-2a
}

resource "aws_subnet" "secondary" {
  availability_zone = data.aws_availability_zones.available.names[1]
  # e.g. ap-northeast-2b
}

데이터 소스를 활용하여 AWS 프로바이더에 구성된 리전내에서 사용 가능한 가용영역 목록을 읽을 수 있다.

 

더 자세한 인수와 데이터소스 등 내용은 다음 링크를 참조하면 좋다.

Terraform Registry

Terraform Registry

 

 

이제 한번 데이터 소스 동작을 테스트해보겠다.

# main.tf
resource "local_file" "dev-chan" {
  content  = "I'm Chanwoo. Aspiring DebOps"
  filename = "${path.module}/dev-chan.txt"
}

data "local_file" "dev-chan" {
  filename = local_file.dev-chan.filename
}

resource "local_file" "dev-woo" {
  content  = data.local_file.dev-chan.content
  filename = "${path.module}/dev-woo.txt"
}

 

terraform apply를 실행한 뒤, local_file.dev-chan 으로 생성된 리소스 dev-chan.txt 파일 내용과 dev-woo.txt 파일 내용이 동일한지 확인한다.

사진-2

• 일단 data와 resource는 정상적으로 생성되었다.

 

파일 또한 잘 생성되었고, diff 명령으로 파일 내용을 비교해보았을때, 차이점이 발견되지 않는다.

정상적으로 동작한 것 같다.

사진-3

echo "data.local_file.dev-chan.content" | terraform console
"I'm Chanwoo. Aspiring DebOps"

 

 

---

 

 

2. 입력 변수 variable

입력 변수는 인프라를 구성하는 데 필요한 속성 값을 정의해 코드의 변경 없이 여러 인프라를 생성하는데 목적이 있다. 테라폼에서는 이것을 입력 변수(input variables)로 정의한다.

(여기서 입력이라는 말은, 일반적인 애플리케이션 코드에서의 변수 선언과 달리 테라폼은 plan 수행 시 값을 입력한다는 것.)

 

2.1 변수 선언 방식

변수는 variable로 시작되는 블록으로 구성된다. 변수 블록 뒤 이름 값은 동일 모듈 내 모든 변수 선언에서 중복되면 안된다. 이 이름으로 다른 코드에서 참조하기 때문!!

 

variable 블록 선언의 예

# variable 블록 선언의 예
**variable** "<이름>" {
 <인수> = <값>
}

**variable** "image_id" {
 type = string
}

테라폼 코드 구성에 미리 예약되어 있어서 변수 이름으로는 사용 불가능한 이름들이 있다.

• source
• version
• providers
• count
• for_each
• lifecycle
• depends_on
• locals

 

변수 정의 시 사용 가능한 메타인수는 다음과 같다.

• default : 변수 값을 전달하는 여러 가지 방법을 지정하지 않으면 기본값이 전달됨, 기본값이 없으면 대화식으로 사용자에게 변수에 대한 정보를 물어봄
• type : 변수에 허용되는 값 유형 정의, string number bool list map set object tuple 와 유형을 지정하지 않으면 any 유형으로 간주
• description : 입력 변수의 설명
• validation : 변수 선언의 제약조건을 추가해 유효성 검사 규칙을 정의
• sensitive : 민감한 변수 값임을 알리고 테라폼의 출력문에서 값 노출을 제한 (암호 등 민감 데이터의 경우)
• nullable : 변수에 값이 없어도 됨을 지정

 

2.2 변수 유형

지원되는 변수의 범주와 형태는 다음과 같다.

- 기본 유형
    - string : 글자 유형
    - number : 숫자 유형
    - bool : true 또는 false
    - any : 명시적으로 모든 유형이 허용됨을 표시
- 집합 유형
    - list (<유형>): 인덱스 기반 집합
    - map (<유형>): 값 = 속성 기반 집합이며 키값 기준 정렬
    - set (<유형>): 값 기반 집합이며 정렬 키값 기준 정렬
    - object ({<인수 이름>=<유형>, …})
    - tuple ([<유형>, …])

각 유형의 예로, list와 set은 선언하는 형태가 비슷하지만, 참조 방식이 인덱스와 키로 각각 차이가 있고 map과 set의 경우 선언된 값이 정렬되는 특징이 있다.

 

 

# 전달할 값이 number인지 확인하는 입력 변수 예제
**variable** "number_example" {
  description = "An example of a number variable in Terraform"
  **type        = number**
  default     = 42
}

# 전달할 값이 list인지 확인하는 입력 변수 예제
**variable** "list_example" {
  description = "An example of a list in Terraform"
  **type        = list**
  default     = ["a", "b", "c"]
}

조건 결합도 사용 가능하다.

# 리스트의 모든 항목이 number 인 list의 예시
variable "list_numeric_example" {
  description = "An example of a numeric list in Terraform"
  **type        = list(number)**
  default     = [1, 2, 3]
}

# 모든 값이 string인 map의 예시
variable "map_example" {
  description = "An example of a map in Terraform"
  **type        = map(string)**

  default = {
    key1 = "value1"
    key2 = "value2"
    key3 = "value3"
  }
}

다음은 복잡한 구조적 유형으로 작성한 예시이다

# object 또는 tuple 제약 조건을 사용
variable "object_example" {
  description = "An example of a structural type in Terraform"
  **type        = object({
    name    = string
    age     = number
    tags    = list(string)
    enabled = bool**
  })

  default = {
    name    = "value1"
    age     = 42
    tags    = ["a", "b", "c"]
    enabled = true
  }
}

 

 

variable "string" {
  type        = string
  description = "var String"
  default     = "myString"
}

variable "number" {
  type    = number
  default = 123
}

variable "boolean" {
  default = true
}

variable "list" {
  default = [
    "google",
    "vmware",
    "amazon",
    "microsoft"
  ]
}

output "list_index_0" {
  value = var.list.0
}

output "list_all" {
  value = [
    for name in var.list : upper(name)
  ]
}

variable "map" { # Sorting
  default = {
    aws   = "amazon",
    azure = "microsoft",
    gcp   = "google"
  }
}

variable "set" { # Sorting
  type = set(string)
  default = [
    "google",
    "vmware",
    "amazon",
    "microsoft"
  ]
}

variable "object" {
  type = object({ name = string, age = number })
  default = {
    name = "abc"
    age  = 12
  }
}

variable "tuple" {
  type    = tuple([string, number, bool])
  default = ["abc", 123, true]
}

variable "ingress_rules" { # optional ( >= terraform 1.3.0)
  type = list(object({
    port        = number,
    description = optional(string),
    protocol    = optional(string, "tcp"),
  }))
  default = [
    { port = 80, description = "web" },
  { port = 53, protocol = "udp" }]
}

 

2.3 유효성 검사

입력되는 변수 타입 지정 외에 테라폼 0.13.- 버전부터 사용자 지정 유효성 검사가 가능해졌다.

변수 블록 내 validation 블록에서 조건인 condition에 지정되는 규칙이 true 혹은 false를 반환해야 하며, error_message는 condition 값의 결과가 false인 경우 출력되는 메시지를 말한다.

 

regex 함수는 대상의 문자열에 정규식을 적용하고 일치하는 문자열을 반환한다. 여기에 can 함수를 사용하면 정규식에 일치하지 않는 오류를 검출한다.

!! validation 블록은 중복으로 선언할 수 있다!!

 

 

다음과 같이 코드를 수정하여 유효성 검사를 테스트해보겠다.

**variable** "image_id" {
  type        = string
  description = "The id of the machine image (AMI) to use for the server."

  **validation** {
    condition     = length(var.image_id) > 4
    error_message = "The image_id value must exceed 4."
  }

  **validation** {
    # regex(...) fails if it cannot find a match
    condition     = can(regex("^ami-", var.image_id))
    error_message = "The image_id value must starting with \"ami-\"."
  }
}

 

terraform apply를 실행하였을때 왼쪽 터미널인 입력 값에서 ami를 입력하였을때는 두 조건(4글자 이상, ami- 형식)이 맞지 않아 error가 발생하였고 오른쪽 터미널에서는 두 조건값을 통과하여 문제없이 명령이 실행되었다.

사진-4

 

2.4 변수 참조

variable은 코드 내에서 var.<이름>으로 참조된다.

main 파일에 변수 선언을 추가하고 plan을 진행한다.

**variable** "my_password" {}

**resource** "local_file" "abc" {
  content  = var.my_password
  filename = "${path.module}/abc.txt"
}

사진-5

지금 선언된 variable 값이 비어있어 plan 혹은 apply 실행을 하게 되면 변수값을 입력하라는 항목이 나타난다. 해당 변수에 값을 입력하면 입력받은 값으로 실행 계획이 생성되어 수행하게 된다.

 

local_file 리소스의 content에 변수로 선언한 값이 참조되어 파일 내에 값이 추가된 것을 확인할 수 있다.

사진-6

 

2.5 민감한 변수 취급

민감한 입력 변수를 위해 테라폼 0.14.0 버전부터 입력 변수의 민감 여부를 선언할 수 있다.

 

main.tf 변수 선언에 sensitive를 추가하고 terraform apply를 진행했다.

variable "my_password" {
  default   = "password"
  **sensitive = true**
}

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

 

default = "password"를 추가하여 입력받는 항목은 나타나지 않으나 테라폼 계획 출력 부분에서 참참조되는 변수 값이 sensitive value로 감춰지는 것을 확인할 수 있다.

사진-7

 

그러나 출력에는 값이 나타나지 않으나 실제 생성되는 결과물에는 지정된 값이 입력된다.

사진-8

 

!! 민감한 변수로 지정해도 terraform.tfstate 파일에는 결과물이 평문으로 기록되므로 state 파일의 보안에 유의해야 한다.

사진-9

 

2.6 변수 입력 방식과 우선순위

variable의 목적은 코드 내용을 수정하지 않고 테라폼의 모듈적 특성을 통해 변수로 재사용성을 높이는 데 있다. 특히 ‘입력 변수’라는 명칭에 맞게 사용자는 프로비저닝 실행시에 원하는 값으로 변수에 정의할 수 있다.

선언되는 방식에 따라 변수의 우선순위가 있으므로, 적절히 사용하여 로컬과 빌드 환경의 정의를 다르게 하거나 파이프라인을 구성하는 경우 외부 값을 변수에 지정할 수 있다.

 

입력 변수의 우선순위를 확인해보겠다. 다음과 같이 코드를 작성한다.

# main.tf
variable "my_var" {}

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

위 코드를 기준으로 우선순위를 확인해보겠다. 적용되는 변수는 resource.local_file.abc의 content 인수 결과로 확인이 가능하다. 숫자가 작을수록 우선 순위도 낮다.

 

[우선순위 수준 1] 실행 후 입력(변수에 값이 선언되지 않아 CLI에서 직접 입력)

사진-10

 

[우선순위 수준 2] variable 블록의 default 값

# variable 블록 수정
variable "my_var" {
    default = "woo2"
}

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

사진-11

• woo2가 우선 순위가 더 높아 변경된다.

 

[우선순위 수준 3] 환경 변수 (TF_VAR_변수 이름)

시스템 환경 변수의 접두사의 TF_VAR_가 포함되면 그 뒤의 문자열을 변수 이름으로 인식한다.

 

default 와 비교해보겠다.

사진-12

 

main.tf에 default로 woo2가 이미 선언되었으나, 환경 변수로 선언된 woo3가 우선 순위가 높아 woo3로 변경되는 것을 확인할 수 있다. (woo2가 졌다…)

 

[우선순위 수준 4] terraform.tfvars에 정의된 변수 선언

루트 모듈의 main.tf 파일과 같은 위치에 terraform.tfvars 파일을 생성해 변수에 대한 값을 추가하고 비교 해보겠다.

사진-13

그럼 terraform.tfvars에 선언된 변수가 킹왕짱일까?

…아니다 아직 남았다.

 

[우선순위 수준 5] *.auto.tfvars에 정의된 변수 선언

동일한 위치에 cwking.auto.tfvars 파일을 생성해 비교해보겠다.

사진-14

추가로, *.auto.tfvars 파일 끼리에서는 파일명의 정렬에 따라 우선순위가 적용된다.

(ex, A.auto.tfvars > B.auto.tfvars )

 

[우선순위 수준 6] *auto.tfvars.json에 정의된 변수 선언

사진-16

 

[우선순위 수준 7] CLI 실행 시 -var 인수에 지정 혹은 -var-file로 파일 지정

사진-17

-var 인수에 선언된 입력 값이 제일 우선하여 적용되는 것을 확인할 수 있다.

 

*.tfvars 와 같은 형식 내용의 파일이라면, -var-file로 지정할 수 있다.

ex, terraform plan -var=my_var=var7 -var-file=”var9.txt”

이 경우 -var-file로 지정된 파일에 선언된 입력 변수 값이 적용된다.

 

 

---

 

 

이렇게 다양한 방식으로 입력 변수를 정의하고 각 방식의 우선순위를 확인하였다.

선언 방식이 다양한 이유는 테라폼 실행 환경, 실행 방식에 따라 입력 변수 값을 선언하도록 해 동일한 코드로 다수의 프로비저닝을 수행하도록 디자인하기 위함이다.

 

.tfvars 확장자로 생성된 파일에 변수를 미리 기입하면 실행 시 입력해야 하는 변수 값을 하나의 파일에서 관리할 수 있다는 장점이 있다.