Terraform 기초 실습 스터디를 진행하고 있으며, 커리큘럼 3주차에 해당하는 내용입니다.
* [테라폼으로 시작하는 IaC] 도서 참조
이전 포스팅에서 테라폼의 프로비저너 까지 알아보았다.
이번 포스팅에서는 테라폼의 기본 사용법에 대한 마무리를 짓고자 한다.
null_resource 와 terraform_data
테라폼 1.4버전이 릴리스되면서 기존 null_resource 리소스를 대체하는 terraform_data 리소스가 추가되었다.
두 리소스의 사용방식에 대해 알아보자.
null_resource 와 terraform_data 1. null_resource
null_resource 는 말 그대로 아무 작업도 수행하지 않는 리소스를 뜻한다.
이 리소스가 필요한 이유는 테라폼 프로비저닝 동작을 설계하면서, 사용자가 의도적으로 프로비저닝 동작을 조율해야하는 상황이 발생하기 때문이다. 이는 프로바이더가 제공하는 리소스 수명주기 관리만으로 해결하기 어렵기 때문이다.
다음과 같은 예시를 가정해보자.
- AWS EC2 인스턴스를 프로비저닝하면서 웹서비스를 실행시키자.
- 웹서비스 설정에는 외부 노출용 고정 IP 가 필요하다. 따라서 aws_eip 리소스 생성이 필요하다.
.
.
.
resource "aws_instance" "foo" {
ami = "ami-dkfjxmc94"
instance_type = "t2.micro"
private_ip = "10.0.0.12"
subnet_ip = aws_subnet.tf_test_subnet.id
provisioner "remote-exec" {
inline = [
"echo ${aws_eip.bar.public_ip}"
]
}
}
resource "aws_eip" "bar" {
vpc = true
instance = aws_instance.foo.id
associate_with_private_ip = "10.0.0.12"
depends_on = [aws_internet_gateway.gw]
}
코드 내용의 의미는 다음과 같다.
- aws_eip 가 고정IP 를 할당하기 위해서는 aws_instance 의 id 값이 필요하다.
- aws_instance 의 프로비저너 동작에서는 aws_eip 가 생성하는 속성값인 public_ip 가 필요하다.
테라폼 구성 정의에서 상호 참조가 발생하는 상황으로, terraform plan 을 수행하면 다음과 같은 에러를 확인할 수 있다.
$ terraform plan
Error: Cycle: aws_eip.bar, aws_instance.foo
상호 참조되는 종소성을 끊기 위해서는 둘 중 하나의 리소스 실행 시점을 한 단계 뒤로 미뤄야한다.
이러한 경우에 실행에 간격을 추가하여 실제 리소스와는 무관한 동작을 수행하기 위해 null_resource 를 활용한다.
null_resource 는 정의된 속성이 'id' 가 전부이므로, 리소스 생성에 변경되는 내용이 없다.
사용자가 null_resoucre 에 정의된 내용을 강제로 다시 실행하기 위한 인수로 trigger가제공된다.
null_resource 와 terraform_data 2. terraform_data
테라폼 1.4 버전 이후부터 기존 null_resource 의 기능적인 요소를 대체하기 위해 terraform_data 리소스가 추가되었다.
이 리소스 또한 자체적으로 아무것도 수행하지 않지만, null_resource 와 비교하여 추가 프로바이더 없이 테라폼 자체에 포함된 기본 수명주기 관리자가 제공되는 장점이 있다.
moved 블록
테라폼으로 리소스를 관리하다보면 이름을 변경해야하는 상황이나, 리소스 주소의 이름이 변경되는 상황이 발생하곤 한다.
리소스의 이름은 변경되지만 이미 테라폼으로 프로비저닝된 환경을 그대로 유지하고자 하는 경우, moved 블록을 사용할 수 있다.
CLI를 위한 시스템 환경 변수
테라폼은 환경변수를 통해 실행방식과 출력내용에 대한 옵션을 조정할 수 있다.
시스템 환경변수를 설정하면, 로컬 환경에 적용되는 옵션이나 별도 서버환경에서 실행하기 위한 옵션을 부여할 수 있다.
- Mac/리눅스/유닉스: export <환경변수 이름>=<값>
- Windows CMD: set <환경변수 이름>=<값>
- Windows PowerShell: $Env: <환경변수 이름>='<값>'
CLI를 위한 시스템 환경 변수 1. TF_LOG
테라폼의 stderr 로그에 대한 레벨을 정의한다.
trace, debug, info, warn, error, off 를 설정할 수 있고, 환경변수가 없는 경우 default 가 off 와 동일하다.
디버깅을 위한 로그 환경변수는 다음과 같다.
- TF_LOG
- TF_LOG_PATH
- TF_LOG_CORE
- TF_LOG_PROVIDER
CLI를 위한 시스템 환경 변수 2. TF_INPUT
값을 false 나 0 으로 설정하면 테라폼 실행시 -input = false 를 추가한 것과 동일한 수행결과를 확인할 수 있다.
입력 변수를 입력해야하는 경우 TF_INPUT=0 을 설정하고 plan 을 동작하면 에러를 확인할 수 있다.
CLI를 위한 시스템 환경 변수 3. TF_VAR_name
TF_VAR_<변수이름> 을 사용하면 입력 시 또는 default 로 선언된 변수 값을 대체한다.
CLI를 위한 시스템 환경 변수 4. TF_CLI_ARGS / TF_CLI_subcommand
테라폼 실행 시 추가할 인수를 정의한다.
TF_CLI_ARGS="-input=false" terraform apply -auto-approve
와
terraform apply -input=false -auto-approve
는 동일하다.
CLI를 위한 시스템 환경 변수 5. TF_DATA_DIR
State 저장 백엔드 설정과 같은 작업 디렉터리별 데이터를 보관하는 위치를 지정한다.
이 데이터는 .terraform 디렉터리 위치에 기록되지만 TF_DATA_DIR 에 경로가 정의되면, 기본 경로를 대체하여 사용할 수 있다.
이미 terraform init (.terraform 생성) 이 수행된 상태에서 TF_DATA_DIR 로 경로를 재지정하는 경우, 플러그인 설치가 필요하다는 메시지가 출력된다. (재 init 이 필요함)
여기까지 테라폼의 기본 사용법에 대해 알아보았다.
부족한 부분은 다시 복습과 실습이 추가로 필요할 것 같다.
다시 한번 더 다지면서 다음번에는 프로바이더에 대해 알아보도록 하겠다.
