[Terraform] 기본 사용법#6 (프로비저너, null_resource와 terraform_data, moved 블록, CLI 시스템 환경 변수)

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

 

1. 프로비저너

프로비저너는 프로바이더와 비슷하게 ‘제공자’로 해석되나, 프로바이더로 실행되지 않는 커맨드와 파일 복사 같은 역할을 수행한다. 예를 들어 클라우드에 리눅스 VM을 생성하는 것에 더해 특정 패키지를 설치해야 하거나 파일을 생성해야 하는 경우, 이것들은 테라폼의 구성과 별개로 동작해야 한다.

 

프로비저너로 실행된 결과는 테라폼의 상태 파일과 동기화도지 않으므로 프로비저닝에 대한 결과가 항상 같다고 보장할 수 없다.

따라서 프로비저너 사용을 최소화 하는 것이 좋다.

 

프로비저너 종류에는 파일 복사와 명령어 실행을 위한 file, local-exec, remote-exec가 있다.

 

1.1 프로비지너 사용 방법

프로비저너의 경우 리소스 프로비저닝 이후 동작하도록 구성할 수 있다. 예를 들어 AWS의 EC2 인스턴스를 생성하고 난 후 CLI를 통해 별도 작업을 수행하는 상황이 있다.

 

실습을 통해 프로비저너의 기본적인 사용 방식을 확인해보겠다.

# main.tf
variable "sensitive_content" {
  default   = "secret"
  sensitive = true
}

resource "**local**_**file**" "foo" {
  content  = upper(var.sensitive_content)
  filename = "${path.module}/foo.bar"

  **provisioner "local-exec" {
    command = "echo The content is ${self.content}"
  }

  provisioner "local-exec" {
    command    = "abc"
    on_failure = continue
  }

  provisioner "local-exec" {
    when    = destroy
    command = "echo The deleting filename is ${self.filename}"
  }**
}

local_file의 content에 지정한 var.sensitive_content 변수의 속성이 민감하다고 선언 되었기 때문에 화면에 출력되지 않는다.

 

두 번째 프로바이더에서는 abc라는 커맨드를 수행한다. 아마 이런 커맨드는 없을 것이므로, apply 동작이 실패해야 한다.

하지만 on_failure = continue 선언이 있으므로 실패 시에도 다음 단계로 넘어간다.

사진-1

사진-2

 

 

on_failure = continue 선언을 주석처리하고 진행해보겠다.

# main.tf
variable "sensitive_content" {
  default   = "secret"
  **sensitive = true**
}

resource "local_file" "foo" {
  content  = upper(var.sensitive_content)
  filename = "${path.module}/foo.bar"

  provisioner "local-exec" {
    command = "echo The content is ${self.content}"
  }

  provisioner "local-exec" {
    command    = "abc"
    **#on_failure = continue**
  }

  provisioner "local-exec" {
    when    = destroy
    command = "echo The deleting filename is ${self.filename}"
  }
}

사진-3

실행 실패 시 에러가 발생하고 종료된다.

 

1.2 local-exec 프로비저너

local-exec는 테라폼이 실행되는 환경에서 수행할 커맨드를 정의한다. 이때 리눅스나 윈도우 등 테라폼을 실행하는 환경에 맞게 설정 커맨드를 정의해야 한다.

사용하는 인수 값은 다음과 같다.

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

 

예시 코드

Unix/Linux/macOS	Windows
resource "null_resource" "example1" { provisioner "local-exec" { command = <<EOF echo Hello!! > file.txt echo $ENV >> file.txt EOF interpreter = [ "bash" , "-c" ] working_dir = "/tmp" environment = { ENV = "world!!" } } }	resource "null_resource" "example1" { provisioner "local-exec" { command = <<EOF Hello!! > file.txt Get-ChildItem Env:ENV >> file.txt EOF interpreter = [ "PowerShell" , "-Command" ] working_dir = "C:\\windows\temp" environment = { ENV = "world!!" } } }

 

command의 << 연산자를 통해다중 라인의 명령을 수행하며 각 환경에 맞는 인터프리터를 지정해 해당 명령을 수행한다. Apply 수행 시 이 명령의 실행 위치를 working_dir를 사용해 지정하고 command에서 사용하는 환경 변수에 대해 environment에서 지정한다.

(apply를 수행하면 working_dir 위치의 file.txt에 기록된 내용을 확인할 수 있다.)

 

 

# main.tf
resource "**null**_resource" "example1" {

  provisioner "local-exec" {
    command = <<EOF
      echo Hello!! > file.txt
      echo $ENV >> file.txt
      EOF

    **interpreter** = [ "bash" , "-c" ]

    **working_dir** = "/tmp"

    **environment** = {
      ENV = "world!!"
    }

  }
}

사진-4

 

1.3 원격지 연결

remote-exec와 file 프로비저너를 사용하기 위해서는 원격지에 연결할 SSH, WinRM 연결 정의가 필요하다.

 

connection 블록 리소스 선언 시, 해당 리소스 내에 구성된 프로비저너에 대해 공통으로 선언되고, 프로비저너 내에 선언되는 경우, 해당 프로비저너에서만 적용된다.

# main.tf
resource "null_resource" "example1" {

  **connection {
    type     = "ssh"
    user     = "root"
    password = var.root_password
    host     = var.host
  }**

  provisioner "file" {
    source      = "conf/myapp.conf"
    destination = "/etc/myapp.conf"
  }

  provisioner "file" {
    source      = "conf/myapp.conf"
    destination = "C:/App/myapp.conf"

    **connection {
        type     = "winrm"
        user     = "Administrator"
        password = var.admin_password
        host     = var.host
    }**
  }
}

• connection 적용 인수와 설명 - 링크

Provisioner Connection Settings | Terraform | HashiCorp Developer

 

 

원격연결이 요구되는 프로비저너의 경우 스크립트 파일을 원격 시스템에 업로드해 해당 시스템에 기본 쉘에서실행하도록 하므로 script_path의 경우 적절한 위치를 지정하도록 한다. 경로는 난수인 %RAND% 경로가 포함되어 생성된다.

• Unix/Linux/macOS : /tmp/terraform_%RAND%.sh
• Windows(cmd) : C:/windows/temp/terraform_%RAND%.cmd
• Windows(PowerShell) : C:/windows/temp/terraform_%RAND%.ps1

베스천 호스트를 통해 연결하는 경우 관련 인수를 지원한다 - 링크

 

1.4 file 프로비저너

file 프로비저너는 테라폼을 실행하는 시스템에서 연결 대상으로 파일 또는 디렉터리를 복사하는데 사용된다. 사용되는 인수는 다음과 같다.

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

 

destination 지정 시 주의해야 할 점은 ssh 연결의 경우 대상 디렉터리가 존재해야 하며 winrm 연결은 디렉터리가 없는 경우 자동으로 생성한다는 것이다.

 

디렉터리를 대상으로 하는 경우에는 source 경로 형태에 따라 동작에 차이가 생긴다. destination이 /tmp 인 경우 source가 디렉터리로 /foo 처럼 마지막에 / 가 없는 경우 대상 디렉터리에 지정한 디렉터리가 업로드되어 연결된 시스템에 /tmp/foo 디렉터리가 업로드된다.

 

source가 디렉터리로 /foo/ 처럼 마지막에 /가 포함되는 경우 source 디렉터리 내의 파일만 /tmp 디렉터리에 업로드된다.

 

 

file 프로비저너 예시는 다음과 같다.

resource "null_resource" "foo" {

  # myapp.conf 파일이 /etc/myapp.conf 로 업로드
  provisioner "file" {
    source      = "conf/myapp.conf"
    destination = "/etc/myapp.conf"
  }

  # content의 내용이 /tmp/file.log 파일로 생성
  provisioner "file" {
    content     = "ami used: ${self.ami}"
    destination = "/tmp/file.log"
  }

  # configs.d 디렉터리가 /etc/configs.d 로 업로드
  provisioner "file" {
    source      = "conf/configs.d"
    destination = "/etc"
  }

  # apps/app1 디렉터리 내의 파일들만 D:/IIS/webapp1 디렉터리 내에 업로드
  provisioner "file" {
    source      = "apps/app1/"
    destination = "D:/IIS/webapp1"
  }

}

 

 

1.5 remote-exec 프로비저너

remote-exec는 원격지 환경에서 실행할 커맨드와 스크립트를 정의한다. 예를 들면 AWS의 EC2 인스턴스를 생성하고 해당 VM 에서 명령을 실행하고 패키지를 설치하는 등의 동작을 의미한다

인수는 서로 배타적이며, 사용되는 인수는 다음과 같다.

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

 

script 또는 scripts의 대상 스크립트 실행에 필요한 인수는 관련 구성에서 선언할 수 없으므로 필요할 때 file 프로바이더로 해당 스크립트를 업로드하고 inline 인수를 활용해 스크립트에 인수를 추가한다.

 

 

file 프로비저너 구성의 예시는 다음과 같다.

resource "aws_instance" "web" {
  # ...

  # Establishes connection to be used by all
  # generic remote provisioners (i.e. file/remote-exec)
  connection {
    type     = "ssh"
    user     = "root"
    password = var.root_password
    host     = self.public_ip
  }

  provisioner "file" {
    source      = "script.sh"
    destination = "/tmp/script.sh"
  }

  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/script.sh",
      "/tmp/script.sh args",
    ]
  }
}

 

 

2. null_resource와 terraform_data

테라폼 1.4 버전이 릴리스되면서 기존 null_resource 리소스를 대체하는 terraform_data 리소스가 추가되었다. 두 리소스의 의미와 사용 방식을 확인해 보겠다.

 

2.1 null_resource

null_resource는 이름처럼 아무 작업도 수행하지 않는 리소스를 구현한다.

이런 리소스가 필요한 이유는 테라폼 프로비저닝 동작을 설계하면서 사용자가 의도적으로 프로비저닝하는 동작을 조율해야 하는 상황이 발생하며 프로바이더가 제공하는 수명주기 관리만으로는 이를 해결하기 어렵기 때문이다.

 

주로 사용되는 시나리오는 다음과 같다.

• 프로비저닝 수행 과정에서 명령어 실행
• 프로비저너와 함께 사용
• 모듈, 반복문, 데이터 소스, 로컬 변수와 함께 사용
• 출력을 위한 데이터 가공

 

예를 들어 다음과 같은 상황을 가정해보겠다.

• AWS EC2 인스턴스를 프로비저닝하면서 웹서비스를 실행시키고 싶다
• 웹서비스 설정에는 노출되어야 하는 고정된 외부 IP가 포함된 구성이 필요하다. 따라서 aws_eip 리소스를 생성해야 한다.

 

AWS EC2 인스턴스를 프로비저닝하기 위해 aws_instance 리소스 구성 시 앞서 확인한 프로비저너를 활요하여 웹서비스를 실행하고자 한다면 다음과 같은 코드 구성이 작성된다.

 

 

다음은 aws_instance에서 aws_eip의 public ip를 사용하려는 예시이다.

# main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_security_group" "instance" {
  name = "t101sg"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

}

resource "aws_instance" "example" {
  ami                    = "ami-0c9c942bd7bf113a2"
  instance_type          = "t2.micro"
  subnet_id              = "subnet-dbc571b0"  # 각자 default VPC에 subnet ID 아무거나
  private_ip             = "172.31.1.100"
  vpc_security_group_ids = [aws_security_group.instance.id]

  user_data = <<-EOF
              #!/bin/bash
              echo "Hello, T101 Study" > index.html
              nohup busybox httpd -f -p 80 &
              EOF

  tags = {
    Name = "Single-WebSrv"
  }

  provisioner "remote-exec" {
    inline = [
      "echo ${aws_eip.myeip.public_ip}"
     ]
  }
}

resource "aws_eip" "myeip" {
  #vpc = true
  instance = aws_instance.example.id
  associate_with_private_ip = "172.31.1.100"
}

output "public_ip" {
  value       = aws_instance.example.public_ip
  description = "The public IP of the Instance"
}

aws_eip가 생성하는 고정 IP를 할당하기 위해서는 대상인 aws_instance의 id값이 필요하다.

aws_instance의 프로비저너 동작에서는 aws_eip가 생성하는 속성 값인 public_ip가 필요하다.

 

테라폼 구성 정의에서 상호 참조가 발생하는 상황으로, 실제 실행되는 코드를 작성하여 terraform plan을 수행하면 다음과 같이 에러가 발생한다.

사진-5

 

상호 참조되는 종속성을 끊기 위해서는 둘 중 하나의 실행 시점을 한 단계 뒤로 미뤄야 한다.

이런 경우 실행에 간격을 추가하여 실제 리소스와는 무관한 동작을 수행하기 위해 null_resource를 활용한다.

 

 

다음과 같이 코드를 수정하고 실행해보겠다.

# main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_security_group" "instance" {
  name = "t101sg"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

}

resource "aws_instance" "example" {
  ami                    = "ami-0c9c942bd7bf113a2"
  instance_type          = "t2.micro"
  subnet_id              = "subnet-dbc571b0"
  private_ip             = "172.31.0.100"
  key_name               = "devwoos"
  vpc_security_group_ids = [aws_security_group.instance.id]

  user_data = <<-EOF
              #!/bin/bash
              echo "Hello, T101 Study" > index.html
              nohup busybox httpd -f -p 80 &
              EOF

  tags = {
    Name = "Single-WebSrv"
  }

}

resource "aws_eip" "myeip" {
  #vpc = true
  instance = aws_instance.example.id
  associate_with_private_ip = "172.31.0.100"
}

resource "null_resource" "echomyeip" {
  provisioner "remote-exec" {
    connection {
      host = aws_eip.myeip.public_ip
      type = "ssh"
      user = "ubuntu"
      private_key =  file("/Users/chanw/.ssh/devwoos.pem")
      #password = "qwe123"
    }
    inline = [
      "echo ${aws_eip.myeip.public_ip}"
      ]
  }
}

output "public_ip" {
  value       = aws_instance.example.public_ip
  description = "The public IP of the Instance"
}

output "eip" {
  value       = aws_eip.myeip.public_ip
  description = "The EIP of the Instance"
}

 

null_resource로 인해 SSH 접근을 계속 시도하다 정상적으로 check 되는 것을 확인할 수 있다.

사진-6

 

 

생성된 EC2에서 80port로 접근 가능한 html 내용도 정상적으로 나타난다.

사진-7

 

 

null_resource는 정의된 속성이 ‘id’가 전부이므로, 선언된 내부의 구성이 변경되더라도 새로운 plan 과정에서 실행 계획에 포함되지 못한다. 따라서 사용자가 null_resource에 정의된 내용을 강제로 다시 실행하기 위한 인수로 trigger가 제공된다.

 

trigger는 임의의 string 형태의 map 데이터를 정의하는데, 정의된 값이 변경되면 null_resource 내부에 정의된 행위를 다시 실행한다.

 

 

trigger 정의와 동작 예제를 확인해보겠다.

resource "null_resource" "foo" {
  triggers = {
    ec2_id = aws_instance.bar.id # instance의 id가 변경되는 경우 재실행
  }
  ...생략...
}

resource "null_resource" "bar" {
  triggers = {
    ec2_id = time() # 테라폼으로 실행 계획을 생성할 떄마다 재실행
  }
  ...생략...
}

 

 

2.2 terraform_data

테라폼 1.4 버전에서는 기존 null_resource의 기능적인 요소를 대체하기 위해 terraform_data 리소스가 추가되었다.(즉..null_resource는 잘 안쓴다..)

이 리소스 또한 자체적으로 아무것도 수행하지 않지만 null_resource는 별도의 프로바이더 구성이 필요하다는 점과 비교하여 추가 프로바이더 없이 테라폼 자체의 포함된 기본 수명주기 관리자가 제공된다는 것이 장점이다.

 

사용 시나리오는 기존 null_resource와 동일하며 강제 재실행을 위한 triggers_replace의 상태 저장을 위한 input 인수와 input에 저장된 값을 출력하는 output 속성이 제공된다.

triggers_replace에 정의되는 값이 기존 map 형태에서 tuple로 변경되어 쓰임이 더 간단해졌다.

 

 

terraform_data 리소스의 trigget_replace 정의와 동작 예제를 확인해보겠다.

resource "aws_instance" "web" {
  # ...
}

resource "aws_instance" "database" {
  # ...
}

# A use-case for terraform_data is as a do-nothing container
# for arbitrary actions taken by a provisioner.
resource "**terraform_data**" "bootstrap" {
  **triggers_replace** = [
    aws_instance.web.id,
    aws_instance.database.id
  ]

  **provisioner** "local-exec" {
    command = "bootstrap-hosts.sh"
  }
}

resource "**terraform_data**" "foo" {
  **triggers_replace** = [
    aws_instance.foo.id,
    aws_instance.bar.id
  ]

  input = "world"
}

output "terraform_data_output" {
  value = **terraform_data.foo.output**  # 출력 결과는 "world"
}

 

3. moved 블록

테라폼의 state에 기록되는 리소스 주소의 이름이 변경되면 기존 리소스는 삭제되고 새로운 리소스가 생성됨을 앞서 설명에서 확인했다.

하지만 테라폼 리소스를 선언하다 보면 이름을 변경해야 하는 상황이 발생하기도 하는데, 예시를 들면 다음과 같은 상황이 있을 수 있다.

• 리소스 이름을 변경
• count로 처리하던 반복문을 for_each로 변경
• 리소스가 모듈로 이동하여 참조되는 주소가 변경

 

리소스의 이름은 변경되지만 이미 테라폼으로 프로비저닝 된 환경을 그대로 유지하고자 하는 경우 테라폼 1.1 버전부터 moved 블록을 사용할 수 있다.

‘moved’ 단어의 뜻처럼 테라폼 state에서 옮겨진 대상의 이전 주소와새 주소를 알리는 역할을 수행한다. moved 블록 이전에는 state를 직접 편집하는 terraform state mv 명령을 사용하여 state를 수정해야 하는 부담이 있었다면, moved 블록은 state에 접근 권한이 없는 사용자라도 변경되는 주소를 리소스 영향 없이 반영할 수 있다.

 

 

한번 다음 실습을 통해 예시들을 확인해보겠다.

# main.tf
resource "local_file" "**a**" {
  content  = "foo!"
  filename = "${path.module}/foo.bar"
}

output "file_content" {
  value = local_file.a.content
}

사진-8

 

 

local_file 의 이름을 a에서 b로 변경해보겠다.

resource "local_file" "**b**" {
  content  = "foo!"
  filename = "${path.module}/foo.bar"
}

output "file_content" {
  value = local_file.**b**.content
}

사진-9

terraform plan 결과 기존 리소스를 삭제하고 새로운 리소스를 생성하려 계획한다.

 

 

해당 local_file.a의 프로비저닝 결과를 유지한 채 이름만을 변경하기 위해 moved 블록을 생성해보겠다.

# main.tf
resource "local_file" "b" {
  content  = "foo!"
  filename = "${path.module}/foo.bar"
}

**moved {
  from = local_file.a
  to   = local_file.b
}**

output "file_content" {
  value = local_file.b.content
}

 

다음과 같이 제거나 생성이 없이 변경되는 것을 확인할 수 있다!

사진-10

사진-11

 

 

4. CLI를 위한 시스템 환경 변수

테라폼은 환경 변수를 통해 실행 방식과 출력 내용에 대한 옵션을 조절할 수 있다. 시스템 환경 변수를 설정하면, 영구적으로 로컬 환경에 적용되는 옵션이나 별도 서버 환경에서 실행하기 위한 옵션을 부여할 수 있다.

이를 통해 로컬 작업 환경과 다른 환경 구성에서만 사용될 특정 옵션을 적용한다.

• Mac/리눅스/유닉스: export <환경 변수 이름>=<값>
• Windows CMD: set <환경 변수 이름>=<값>
• Windows PowerShell: $Env:<환경 변수 이름>='<값>'

 

4.1 TF_LOG

테라폼의 stderr 로그에 대한 레벨을 정의한다.

trace, debug, info, warn, error, off를 설정할 수 있고 관련 환경 변수가 없는 경우 off와 동일하다.

디버깅을 위한 로그 관련 환경 변수 설명은 다음과 같다.

• TF_LOG: 로깅 레벨 지정 또는 해제
• TF_LOG_PATH: 로그 출력 파일 위치 지정
• TF_LOG_CORE: TF_LOG와 별도로 테라폼 자체 코어에 대한 로깅 레벨 지정 또는 해제
• TF_LOG_PROVIDER: TF_LOG와 별도로 테라폼에서 사용하는 프로바이더에 대한 로깅 레벨 지정 또는 해제

 

환경에 맞게 TF_LOG를 info로 설정하고, terraform plan 동작을 실행하면 테라폼 출력에 관련 로그가 출력되는 것을 확인할 수 있다.

사진-12

 

4.2 TF_INPUT

값을 false 또는 0으로 설정하면 테라폼 실행 시 인수에 -input=false를 추가한 것과 동일한 수행 결과를 확인할 수 있다.

환경에 맞게 TF_INPUT을 0으로 설정하고 terraform plan 동작을 실행하면 입력받는 동작을 수행하지 않으므로 입력 변수를 입력해야 하는 경우 에러가 발생할 수 있다.

**TF_INPUT=0 terraform plan**
Error : No value for required variable

 

4.3 TF_VAR_name

TF_VAR_<변수 이름>을 사용하면 입력 시 default로 선언된 변수 값을 대체한다.

(변수 입력 방식은 앞서 입력 변수 챕터에서 확인했다.)

 

 

4.4 TF_CLI_ARGS / TF_CLI_ARGS_subcommand

테라폼 실행 시 추가할 인수를 정의한다.

TF_CLI_ARGS=”-input=false” terraform apply -auto-approve는 terraform apply -input=false -auto-approve 와 같다.

**TF_CLI_ARGS="-input=false" terraform apply -auto-approve**
Error: No value for required variable

 

 

TF_CLI_ARGS_apply 로 인수를 정의하면 terraform apply 커맨드 수행 시에만 동작한다.

export TF_CLI_ARGS_apply="-input=false"
**terraform apply -auto-approve**
<에러>

 

4.5 TF_DATA_DIR

state 저장 백엔드 설정과 같은 작업 디렉터리별 데이터를 보관하는 위치를 지정한다.

 

이 데이터는 .terraform 디렉터리 위치에 기록되지만, TF_DATA_DIR에 경로가 정의되면 기본 경로를 대체하여 사용된다.

일관된 테라폼 사용을 위해서 해당 변수는 실행시마다 일관되게 적용될 수 있도록 설정하는 것이 중요하다.

 

 

설정 값이 이전 시에만 적용되는 경우 init 명령으로 수행된 모듈, 아티팩트 등의 파일을 찾지 못한다. 이미 terraform init이 수행된 상태에서는 TF_DATA_DIR로 경로를 재지정하고 실행하는 경우 플러그인 설치가 필요하다는 메시지 출력을 확인할 수 있다.

**TF_DATA_DIR=./.terraform_tmp terraform plan**
Error: Required plugins anr not installed