TF 101 Study 3주차 정리 - 조건식, 함수, 프로비저너, 환경 변수, 프로바이더

• CloudNeta의 가시다님이 진행하시는 Terraform 101 Study에 참가하며 작성한 내용입니다.
• 스터디 교재 → 테라폼으로 시작하는 IaC

CH3. 기본 사용법 - 3

---

3-10. 조건식

---

• 테라폼의 조건식은 3항 연산자 형태 → <조건 정의> ? <true인 경우> : <false인 경우>

• 조건식에서 타입이 다른 경우 테라폼은 조건 비교를 위해 형태를 추론하여 자동으로 변환 → 조건식을 명시적인 형태로 작성

• 입력 변수로 배포 환경(dev, prod)를 구분하여 EC2 인스턴스의 사이즈 조정하기

3-11. 함수

---

• 테라폼은 값의 유형을 변경하거나 조함할 수 있는 내장 함수를 제공합니다.

• 내장함수 외에 사용자 정의 함수는 지원하지 않습니다.

• terraform console 커맨드를 사용해 테라폼에서 함수를 사용하고 결과를 확인할 수 있다.

• cidrhost(내장 함수)와 count를 이용하여 2개의 ENI를 생성하고 EC2에 attach 시키기

3-12. 프로비저너

---

• 프로비저너 → 프로바이더로 실행되지 않는 커맨드와 파일 복사 같은 역할을 수행
• 프로비저너로 실행된 결과는 테라폼의 상태 파일과 동기화되지 않으므로 프로비저닝에 대한 결과가 항상 같다고 보장할 수 없다.
  → 따라서 프로비저너 사용을 최소화하는 것이 좋다.

프로비저너 사용 방법

• 프로비저너의 경우 리소스 프로비저닝 이후 동작하도록 구성할 수 있다.
• 프로비저너는 선언된 리소스 블록의 작업이 종료되고 나서 지정한 동작을 수행한다.
• 다수의 프로비저너를 반복적으로 선언도 가능하며 이런 경우 순서대로 처리된다.
• 프로비저너는 self를 통해 프로비저닝 리소스를 해당 속성을 참조할 수 있다.

local-exec 프로비저너

• local-exec → 테라폼이 실행되는 환경에서 수행할 커맨드를 정의

resource "local_file" "provisioner_test" {
  content  = "for provisioner test"
  filename = "provisioner_test.txt"

  # local-exec 프로비저너 -> 테라폼이 실행되는 환경에서 수행
  provisioner "local-exec" {
    command = "echo The content is ${self.content}"
  }
}

# 실행 결과
# 1. terraform apply 단계에서 로컬 머신에 "echo The content is ${self.content}" 라는 커맨드가 전달된다.
# 2. provisioner_test.txt라는 파일이 프로비저닝 된다.

원격지 연결

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

file 프로비저너

• file → 테라폼을 실행하는 시스템에서 연결 대상으로 파일 또는 디렉터리를 복사하는데 사용
• 로컬에서 테라폼을 실행하여 EC2 인스턴스를 생성하고, 원격지 연결을 통해 로컬의 파일을 EC2로 업로드하는 경우에 사용

remote-exec 프로비저너

• remote-exec → 원격지 환경에서 실행할 커맨드와 스크립트를 정의
• EC2 인스턴스를 생성하고 VM에서 실행할 명령 등을 정의

resource "aws_instance" "file_ec2" {
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"

  # 원격지 연결
  # 1.2.3.4의 IP를 가지는 EC2 인스턴스에 ssh로 연결
  connection {
    type     = "ssh"
    user     = "root"
    password = "Password"
    host     = "1.2.3.4"
  }

  # file 프로비저너
  # 테라폼 실행 환경에 있는 'install_script.sh'를 EC2 인스턴스에 업로드
  provisioner "file" {
    source      = "install_script.sh"
    destination = "/etc/install_script.sh"
  }

  # remote-exec 프로비저너
  # EC2에서 inline에 있는 커맨드를 수행하도록 지시
  provisioner "remote-exec" {
    inline = [
      "chmod +x /ect/install_script.sh",
      "/bin/bash /etc/install_script.sh"
    ]
  }
}

3-13. null_resources와 terraform_data

---

• 테라폼 1.4 버전이 릴리스 되면서 기존 null_resource 리소스를 대체하는 terraform_data 리소스가 추가

null_resource

• 아무 작업도 수행하지 않는 리소스를 구현
• 사용자가 의도적으로 프로비저닝하는 동작을 조율해야 하는 상황에서
  → 프로바이더가 제공하는 리소스 수명주기 관리로만은 해결하기 어렵기 때문

terraform_data

• 기존 null_resource의 기능적인 요소를 대체하기 위해 추가 → null_resource는 별도의 프로바이더구성이 필요
• terraform_data와 null_resource의 사용 시나리오는 같다.
• 강제 재실행 → triggers_replace
• 상태 저장 → input 인수
• input에 저장된 값을 출력 → output 속성

3-14. moved 블록

---

• 테라폼 State에 기록되는 리소스 이름이 변경되면 기존 리소스는 삭제되고 새로운 리소스가 생성된다.

  → 리소스 이름은 변경되지만 테라폼으로 프로비저닝한 환경을 그대로 유지하고자 하는 경우 moved를 사용하면 된다.

• 테라폼 1.1 버전부터 moved를 사용할 수 있으며, 이전에는 terraform state mv 명령으로 State를 조작해야하는 부담이 있었다.

• A라는 리소스의 이름을 B로 변경하고자 하는 경우 moved 블록을 작성하고 apply 하고 moved 블록을 삭제하면 된다.

# A라는 이름의 local_file 리소스를 B라는 이름으로 변경
moved {
  from = local_file.A
  to   = local_file.B
}

3-15. CLI를 위한 시스템 환경 변수

---

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

TF_LOG

• stderr 로그 레벨 정의 → trace, debug, info, warn, error, off
• TF_LOG : 로깅 레벨 지정
• TF_LOG_PATH : 로그 파일 위치 지정
• TF_LOG_CORE : 테라폼 코어의 로깅 레벨 지정
• TF_LOG_PROVIDER : 프로바이더의 로깅 레벨 지정

TF_INPUT

• TF_INPUT으로 0 또는 false를 설정하는 경우 → 입력받는 동작을 수행하지 않음

TF_VAR_name

• default로 선언된 변수를 대체하는 환경 변수

TF_CLI_ARGS / TF_CLI_ARGS_subcommand

• 테라폼 실행 시 추가할 인수를 정의

TF_DATA_DIR

• 작업 디렉터리별 데이터(state 저장 백엔드, 모듈, 아티팩트 등)를 보관하는 위치를 지정
  → init 이후에 TF_DATA_DIR 경로를 재지정하는 경우 플러그인 설치가 필요하다는 메세지가 출력

CH4. 프로바이더

---

• 테라폼은 코드로 관리하고자 하는 대상을 호출 하는 방식으로 실행
• 관리하고자 하는 대상들의 호출하는 방식은 모두 다르지만 일관되게 호출 할 수 있는 이유 → 프로바이더
• 프로바이더는 테라폼이 관리하는 리소스 유형과 데이터 소스를 사용할 수 있도록 연결
• 테라폼은 프로바이더 없이는 어떤 종류의 인프라와 서비스도 관리할 수 없다

4-1. 프로바이더 구성

---

• 프로바이더에는 Tier가 존재
  → Official (hashicorp가 관리) / Partner (파트너가 관리) / Community (개인) / Archived (관리되지 않음)

단일 프로바이더의 다중 정의

• 단일 프로바이더를 다중 정의하고자 하는 경우 → 프로바이더에 alias를 선언`

provider "aws" {
  region = "us-west-1"
}

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

resource "aws_instance" "app_server" {
  provider      = aws.seoul
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"
}

• provider alias로 2개의 리전(seoul, tokyo)에 S3 배포하기

프로바이더 설치 및 요구사항 정의

• terraform init 명령을 통해 정의된 프로바이더를 설치하게 된다.
• 코드로 작성한 인프라를 항상 동일한 프로바이더로 배포하는 방법
  → terraform 블럭에 프로바이더 버전을 명시
  → .terraform.lock.hcl을 코드와 함께 공유
• terraform 블럭의 required_providers 블럭에 여러 개의 프로바이더를 정의할 수 있다.
• required_providers 블럭의 source에는 프로바이더 다운로드 경로를 지정하고, version에는 버전 제약을 명시한다.

4-2. 프로바이더 에코시스템

---

• 에코시스템을 위한 테라폼 통합 → 워크플로 파트너와 인프라 파트너
• 워크플로 파트너 → 테라폼 실행과 연계하여 동작하는 기능을 제공
• 인프라 파트너 → 사용자가 대상 플랫폼의 API로 리소스 관리

4-3. 프로바이더 경험해보기

---

AWS

• 회원 가입 → IAM 콘솔 → 액세스 키 발급 → 테라폼 코드 작성

Azure

• UI(콘솔)로 ID와 시크릿 취득하는 방법
• 회원 가입 → Azure Active Directory → 애플리케이션 등록 → client_id와 tenant_id 확인
  → 클라이언트 암호 설정 → client_secret 확인 → subscription_id 확인 → 액세스 제어(IAM)에서 역할 할당 → 구성원을 애플리케이션에 등록
  → 테라폼 코드 작성

GCP

• UI(콘솔)로 ID와 시크릿 취득하는 방법
• 회원가입 → IAM 및 관리자에서 프로젝트 선택 또는 생성 → JSON 유형의 키를 다운로드 → 테라폼 코드 작성

Alibaba Cloud

• UI(콘솔)로 ID와 시크릿 취득하는 방법
• 회원가입 → RAM(Resource Access Management)에서 서브 User 생성 → 서브 User에 리소스 관련 권한 부여
  → RAM에서 AccessKey ID와 AccessKey Secret 확인 → 테라폼 코드 작성