[T101] Terraform 101 Study 2주차 (1)

Data Source

Terraform에서 Data는 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용한다.

 

- 데이터 소스 유형은 첫 번째 _를 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형이다.

- 데이터 소스 유형 선언 후 뒤에는 고유한 이름을 붙인다.

- 리소스의 이름과 마찬가지로 이름은 동일한 유형에 대한 식별자 역할을 하기 때문에 중복될 수 없다.

 

ex) AWS EC2의 AMI와 같이 프로바이더의 상품을 조회해 사용할 때 사용하기도 한다.

예제 코드 [Terraform Registry]

# 프로바이더 = aws, 리소스 유형 = ami, 고유 이름 = example
data "aws_ami" "example" { 
  executable_users = ["self"]
  most_recent      = true
  name_regex       = "^myami-\\d{3}"
  owners           = ["self"]

  filter {
    name   = "name"
    values = ["myami-*"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

local을 사용해 기본 동작을 확인해본다.

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

# data가 조회할 수 있는 파일 사전 생성
$ echo "t101 study - 2week" > abc.txt

# terraform 배포
$ terraform init && terraform plan && terraform apply -auto-approve

# 배포 후
$ terraform state list

# 상세 데이터 확인
$ terraform console
> data.local_file.abc # 상세 내역 전체 확인
> data.local_file.id # file id 확인
> data.local_file.content # file 내용 확인
> data.local_file.filename # file 이름 확인

 

Data resource 에서 사용할 수 있는 메타인수
- depends_on : 종속선 선언이며, 선언된 구성 요소와의 생성 시점에 대해 정의
- count : 선언된 개수에 따라 여러 리소스를 생성
- for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
- lifecycle : 리소스의 수명 주기 관리

 

- 데이터 속성 참조

• 데이터 소스로 읽은 대상을 참조하는 방식은 data로 블럭이 시작된다.

예제) 로컬 환경이 아닌 외부 데이터 aws 자원을 조회해보자. [Terraform registry]

# 사용 가능한 az 조회
data "aws_availability_zones" "available" {
  state = "available"
}

 

[도전과제] 위에서 불러온 az를 사용하여 VPC 만들기

provider "aws" {
  region = "ap-northeast-2"
}

data "aws_availability_zones" "az-zone" {
  state = "available"
}

resource "aws_vpc" "ssungz-aws_vpc" {
  cidr_block = "10.10.0.0/16"
  tags = {
    Name = "ssungz-vpc"
  }
}

resource "aws_subnet" "subnets" {
  vpc_id = aws_vpc.ssungz-aws_vpc.id
  count = length(local.cidr_list)

  cidr_block = element(local.cidr_list, count.index)
  availability_zone = element(data.aws_availability_zones.az-zone.names, count.index)
  
  tags = {
    Name = "Pub-subnet-${count.index}"
  }
}

# count.index로 줄 수 있지만, CIDR을 지정하고 싶어 locals를 사용했다.
# 변수는 뒤에서 할 예정이기 때문에 data 참조에서는 변수를 사용하지 않았다.

locals {
    cidr_list = [
        "10.10.1.0/28",
        "10.10.2.0/28"
    ]

}

 

코드에서 선언한 것과 같이, AZ를 잘 가지고 왔고,

cidr과 tag도 정상적으로 할당되었고, 배포 시 콘솔에서도 정상 배포된 것을 확인했다.

 

입력 변수 Variable

입력 변수는 인프라를 구성하는 데 필요한 속성 값을 정의해 코드의 변경 없이 여러 인프라를 생성하는데 목적이 있다.

테라폼에서는 이것을 입력 변수 Input Variables로 정의한다.

 

data, resource와 같이 variable이라는 불록으로 선언되어 구성된다. 변수 블럭 뒤의 이름은 고유해야하고,

해당 네이밍을 통해 코드 내 또는 다른 코드에서 참조된다.

 

variable에 아무런 값이 없을 경우 배포 시 interactive 하게 변수 값을 입력 시켜야 한다.

provider "aws" {
  region = "ap-northeast-2"
}

variable "vpc_cidr_block" {
  default = "10.10.0.0/16"
}

variable "ssungz" {
    default = "ssungz"
}

resource "aws_vpc" "ssungz-vpc" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "${var.ssungz}-vpc"
  }
}

 

배포 시 선언된 변수 값을 잘 참조하는 것을 확인했다.

 

# 변수 정의 시 사용 가능한 메타 인수

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

 

변수 유형별 선언 예

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" {
   default = {
     aws     = "amazon",
     azure   = "microsoft",
     gcp     = "google"
   }
 }
 
 variable "set" {
   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"
   type = list(object({
     port        = number,
     description = optional(string),
     protocol    = optional(string, "tcp"),
   }))
   
   default = [
     { port = 80, description = "web" },
     { port = 53, protocol = "udp" }]
   }

 

- 유효성 검사 : 입력되는 변수 타입 지정 이외, 사용자 지정 유효성 검사 가능

    [유효성 검사 코드 예시]

      validation 조건은 아래와 같다

      1) image_id의 길이가 4보다 커야한다. 그렇지 않으면 에러 메시지를 표시

      2) image_id의 시작이 "ami-" 가 아니면 에러 메시지를 표시

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

 

 

변수 입력 방식과 우선순위

• variable의 목적은 코드 내용을 수정하지 않고, 테라폼의 모듈적 특성을 통해 입력되는 변수로 재사용성을 높이는데 있다.
• 입력 변수는 프로비저닝 실행 시에 원하는 겂으로 변수에 정의할 수 있다.
• 선언되는 방식에 따라 우선순위가 있기 때문에 로컬 환경과 빌드 서버 환경에서의 정의를 다르게 하거나,
  프로비저닝 파이프라인을 구성하는 경우 외부 값을 변수에 지정할 수 있다.

 

- 변수 우선 순위 예제
(우선 순위가 낮은 순에서 높은 순으로)

 

[우선순위 수준 1] 실행 후 입력

variable "my_var" {}

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

interactive 하게 입력하라는 표시가 나오고, 입력된 값이 변수 값으로 지정된다.

 

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

variable "my_var" {
  default = "var2"
}

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

블럭 내부의 default가 우선순위가 높기 때문에 content 내용이 var1 > var2로 변경되었다.

 

[우선순위 수준 3] 환경 변수

• 시스템 환경(OS) 변수에 등록하는 방법이다.
  변수의 접두사에 TF_VAR_ 가 포함되면 그 뒤의 문자열을 Terraform에서 변수 이름으로 인식한다.

# OS 변수 등록
EXPORT TF_VAR_my_var=var3
echo $TF_VAR_my_var

terraform apply -auto-approve

OS에 선언된 TF_VAR_가 우선되어 변수 값으로 변경된다.

 

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

• 루트 모듈의 main.tf 파일과 같은 위치에 terraform.tfvars 파일을 생성해 변수에 대한 값을 추가

echo 'my_var="var4"' > terraform.tfvars
cat terraform.tfvars

 

[우선순위 수준 5,6]

terraform.tfvars 와 비슷하게, *.auto.tfvars에 변수를 선언하고, *.auto.tfvars.json에 변수를 선언하는 방식으로

terraform.tfvars와 동작 방식에 큰 차이는 없다.

(단, 파일이 여러개가 있을 경우 파일명의 정렬 순서에 따라 우선 순위가 적용된다.)

 

[우선순위 수준 7]

CLI 실행 시 -var 옵션을 통행 지정하거나, 선언 형식이 맞다면 -var-file 옵션을 통해 파일을 지정할 수 있다.

terraform apply -auto-approve -var=my_var=var7
terraform apply -auto-approve -var-file="var9.txt"

동일 변수명이 두개 선언될 경우에는 나중에 선언된 변수의 우선순위가 높다.