[테라폼으로 시작하는 IaC] 반복문, 조건식, 함수 등 HCL 문법

 

[테라폼으로 시작하는 IaC] HCL 블록 및 변수 선언 문법

포스팅 내용은 "테라폼으로 시작하는 IaC" 도서를 읽고 요약한 내용입니다. 본 포스팅은 위 포스팅 내용에서 이어집니다.

 

Chapter 3 - (7) 반복문

count

count로 생성되는 리소스와 모듈의 경우 아래와 같이 참조한다.

<리소스 타입>.<이름>[<인덱스번호>]
module.<모듈 이름>[<인덱스 번호>]

 

주의할 점

• 모듈 내 count 적용이 불가능한 선언이 있다. (ex: provider 블록 선언부가 포함되어 있는 경우)
• 외부 변수가 list 타입인 경우 중간 값이 삭제되면 이후에 정의된 리소스들도 삭제되고 재생성된다.

for_each

for_each에 입력된 데이터 형태가 map 또는 set이면, 선언된 key값 개수만큼 리소스를 생성하게 된다.

• each.key : 인스턴스에 해당하는 map 타입의 key 값
• each.value : 인스턴스에 해당하는 map의 value 값

for_each로 생성되는 리소스와 모듈의 경우 아래와 같이 참조한다.

<리소스 타입>.<이름>[<key>]
module.<모듈 이름>[<key>]

for

for문은 복합 형식 값의 형태를 반환하는 데 사용된다.

• list 타입의 경우, 값 또는 인덱스와 값을 반환
• map 타입의 경우, 키 또는 키와 값에 대해 반환
• set 타입의 경우 키 값에 대해 반환

규칙

• list: 반환받는 값이 하나로 되어 있으면 값, 두 개인 경우 앞의 인수가 인덱스를 반환하고 뒤의 인수가 값을 반환 (관용적으로 인덱스는 i, 값은 v로 표현)
• map: 반환 받는 값이 하나로 되어 있으면 키를, 두 개인 경우 앞의 인수가 키를 반환하고 뒤의 인수가 값을 반환 (관용적으로 키는 k, 값은 v로 표현)
• 결과 값은 for 문을 묶는 기호가 [ ]인 경우 tuple로 반환되고 { }인 경우 object 형태로 반환
• object 형태의 경우 키와 값에 대한 쌍은 ⇒ 기호로 구분
• { } 형식을 사용해 object 형태로 결과를 반환하는 경우 키 값은 고유해야 하므로 값 뒤에 그룹화 모드 심볼(…)를 붙여서 키의 중복 방지 (ex: SQL의 group by, Java의 MultiValueMap)
• if 구문을 추가해 조건 부여 가능

dynamic

리소스 내에 선언되는 구성 블록을 다중으로 작성해야 하는 경우 사용한다. dynamic 블록에서는 기존 속성 이름을 dynamic 블록의 이름으로 선언하고 기존 블록 성성에 정의되는 내용을 content 블록에 작성한다.

resource "provider_resource" "name" {
	name = "some_resource"
	
	dynamic "some_setting" {
		for each = {
			a_key = a_value
			b_key = b_value
			c_key = d_value
			d_key = d_value
		}

		content {
			key = some_setting.value
		}
	}
}

 

 

 

Chapter 3 - (8) 조건식

테라폼에서의 조건식은 3항 연산자 형태를 갖는다.

# <조건 정의> ? <옳은 경우> : <틀린 경우>
var.a != "" ? var.a : "default-a"

조건식의 각 조건은 비교 대상의 형태가 다르면 테라폼 실행 시 조건 비교를 위해 형태를 추론하여 자동으로 변환하므로 협업 시에 명시적인 형태로 작성하는 것이 좋다.

var.example ? 12 : "hello".             # 비권장
var.example ? "12" : "hello"            # 권장
var.example ? tostring(12) : "hello"    # 권장

 

 

Chapter 3 - (9) 함수

테라폼의 내장 함수 외에 사용자가 구현하는 별도의 사용자 정의 함수를 지원하지는 않는다.

terraform console 커맨드를 사용해 테라폼에서 함수를 적용했을 때 어떤 결과가 나오는지 확인할 수 있다. terraform.tfstate 파일이 생성된 상태에서 해당 상태 파일의 값을 이용해 참조 값을 활용하는 것도 가능하다.

 

Chapter 3 - (10) provisioner

프로바이더로 실행되지 않는 커맨드와 파일 복사 같은 역할을 수행한다. 프로비저너로 실행된 결과는 테라폼의 상태 파일과 동기화되지 않으므로 프로비저닝에 대한 결과가 항상 같다고 보장할 수 없기 때문에 프로비저너 사용을 최소화하는 것이 좋다. 프로비저너는 선언된 리소스 블록의 작업이 종료되고 나서 지정한 동작을 수행한다. 프로비저너에서는 리소스 속성에 대해서 self 값에 대한 참조가 가능하다.

on_failure = continue

기본값은 on_failure = fail 로 continue로 설정 시에 해당 커맨드 수행 실패 시에도 다음 단계로 넘어간다.

when = destroy

terraform destroy를 수행할 때에만 정보를 출력한다.

local_exec 프로비저너

테라폼이 실행되는 환경에서 수행할 커맨드를 정의한다.

• command(필수): 실행할 명령줄을 입력하며 << 연산자를 통해 여러 줄의 커맨드 입력 가능
• working_dir(선택) : command의 명령을 실행할 디렉터리를 지정해야 하고 상대/절대 경로로 설정
• interpreter(선택) : 명령을 실행하는 데 필요한 인터프리터를 지정하며, 첫 번째 인수는 인터프리터 이름이고 두 번째부터는 인터프리터 인수 값
• environment(선택) : 실행 시 환경 변수는 실행 환경의 값을 상속받으며, 추가 또는 재할당하려는 경우 해당 인수에 key = value 형태로 설정

remote_exec와 file 프로비저너를 실행하기 위해서는 원격지에 연결할 SSH, WinRM 연결 정의가 필요하다. connection 블록 선언이 필요하다. 워격 연결이 요구되는 프로비저너의 경우 스크립트 파일을 원격 시스템에 업로드해 해당 시스템의 기본 쉘에서 실행하도록 한다.

file 프로비저너

테라폼을 실행하는 시스템에서 연결 대상으로 파일 또는 디레거리를 복사하는 데 사용된다.

• source: 소스 파일 또는 디렉터리로, 현재 작업 중인 디렉터리에 대한 상대 경로 또는 절대 경로로 지정할 수 있다. content와 함께 사용할 수 없다.
• content: 연결 대상에 복사할 내용을 정의하며 대상이 디렉터리인 경우 tf-file-content 파일이 생성되고, 파일인 경우 해당 파일에 내용이 기록된다. source와 함께 사용할 수 없다.
• destination : 필수 항목으로 항상 절대 경로로 지정되어야 하며, 파일 또는 디렉터리다.

remote_exec 프로비저너

원격 환경에서 실행할 커맨드와 스크립트를 정의한다. ex: AWS EC2 인스턴스를 생성하고 해당 VM에서 명령을 실행하고 패키지를 설치.

• inline: 명령에 대한 목록으로 [ ] 블록 내에 “ “로 묶인 다수의 명령을 , 로 구분해 구성한다.
• script: 로컬의 스크립트 경로를 넣고 원격에 복사해 실행한다.
• scripts: 로컬의 스크립트 경로의 목록으로 [ ] 블록 내에 “ “로 묶인 다수의 스크립트 경로를 ,로 구분해 구성한다.

 

Chapter 3 - (11) null_resource와 terraform_data

1. null_resource

아무 작업도 수행하지 않는 리소스. 사용자가 의도적으로 프로비저닝 하는 동작을 조율해야 하는 상황 및 프로바이더가 제공하는 리소스 수명주기로는 관리가 어렵기 때문에 null_resource가 필요하다.

• trigger: null_resource에 정의된 내용을 강제로 다시 실행한다. string 형태의 map 데이터를 정의하고, 정의된 값이 변경되면 null_resource에 정의된 행위를 다시 실행한다.

2. terraform_data (테라폼 1.4 버전 이상)

null_resource와 달리 추가 프로바이더 없이 테라폼 자체에 포함된 기본 수명주기 관리자가 제공된다. 강제 재실행을 위해 triggers_replace, 상태 저장을 위해 input 인수, 저장된 값을 출력하는 output 속성이 제공된다.

 

Chapter 3 - (12) moved 블록

테라폼의 state에 기록되는 리소스 주소의 이름이 변경되면 기존 리소스는 삭제되고 새로운 리소스가 생성된다. 리소스 이름이 변경되거나, count로 처리하던 반복문을 for_each로 변경 또는 리소스가 모듈로 이동하여 참조되는 주소가 변경됐을 때 moved 블록을 사용할 수 있다. 테라폼 state에서 옮겨진 대상의 이전 주소와 새 주소를 알리는 역할을 수행한다. 변경되는 주소를 리소스 영향 없이 반영할 수 있다.

 

 

Chapter 3 - (13) CLI를 위한 시스템 환경 변수

1. TF_LOG

테라폼의 stderr 로그에 대한 레벨을 정의한다. trace, debug, info, warn, error, off를 설정할 수 있고 관련 환경 변수가 없는 경우 off와 동일하다.

2. TF_INPUT

값을 false 또는 0으로 설정하면 테라폼 실행 시에 인스룰 -input=false를 추가한 것과 동일하다. 입력받는 동작을 수행하지 않는다.

3. TF_VAR_name

입력 시 또는 default로 선언된 변수 값을 대체한다.

4. TF_CLI_ARGS

테라폼 실행 시 추가할 인수를 정의한다. TF_CLI_ARGS_apply로 인수를 정의하면 terraform apply 커맨드 수행 시에만 동작한다.

5. TF_DATA_DIR

state 저장 백엔드 설정과 같은 작업 디렉터리별 데이터를 보관하는 위치를 지정한다. .terraform 디렉터리 위치에 기록되지만 TF_DATA_DIR에 경로가 정의되면 기본 경로를 대체하여 사용된다. 실행 시마다 일관되게 설정될 수 있도록 설정하는 것이 중요하다.