Terraform 101 Study - 1주차(1) 내용정리

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

CH1. IaC와 테라폼

---

• 코드로 인프라를 관리한다는 것
  → ‘자유롭게 변경’하고, ‘환경을 이해’하고, ‘반복적으로 동일한 상태’를 만들수 있다는 의미
  → 명세를 별도의 문서로 정리하지 않아도 인프라가 명확하게 정의되어 남는다는 의미

• IaC는 컴퓨터에서 읽을 수 있는 형태의 파일을 사용해 인프라나 서비스를 프로비저닝하는 프로세스

• terraform은 하시코프에서 공개한 IaC 도구

• Terraform은 Provider라고 하는 플러그인을 통해 클라우드 제공자(AWS, GCP, …)나 기타 서비스와 상호 작용합니다.

  

• 테라폼 제공 유형 3가지

  • On-Premise(오픈소스 사용) → 별도로 테라폼 실행환경과 state 관리 방법을 마련해야합니다
  • Terraform Cloud(SaaS) → 테라폼 실행환경과 state관리를 지원
  • Terraform Enterprise(Private Install) → 사내 컴퓨팅 자원에 설치

• Immutable과 Mutable

  • Immutable Infrastructure는 originally provisioned된 이후로 수정할 수 없는 인프라 스트럭쳐입니다.
  • Mutable infrastructure는 originally provisioned 된 이후로 수정되거나 업데이트 할 수 있는 인프라 스트럭쳐입니다.
  • Immutable은 수정이나 업데이트하는 것이 아니라 새로운 인프라를 생성하고 이전 상태의 인프라를 교체하는 방식
  • Immutable Infrastructure는 인프라를 버전으로 관리할 수 있게 해줍니다. 이를 통해 인프라를 롤백하거나 업데이트 할 수 있게 해줍니다.
  • 테라폼은 immutable하게 인프라를 관리합니다.
  • 테라폼으로 구성한 인프라를 수동으로 수정하거나 업데이트 할 수 있지만, 이는 IaC의 이점인 인프라 일관성을 약화시킵니다.

CH3. 기본 사용법 - 1

---

3-1. 주요 커맨드

---

terraform init

• 테라폼 configuration 파일이 있는 작업 디렉처리를 초기화
• init을 실행하는 디렉터리를 루트모듈이라고 한다.
• 테라폼에서 사용되는 프로바이더, 모듈 등의 지정된 버전에 맞춰 루트모듈을 구성하는 역할
• -upgrade
  • 모든 provider를 configuration에 지정된 버전 제약 조건 내에서(the version constraints sepcified within) 최신 버전으로 업그레이드합니다.
  • 구성 내에 버전 제약 조건이 현재 공급자 버전보다 더 낮은 버전인 경우 다운그레이드도 가능합니다.

terraform validate

• 테라폼 configuration 파일의 유효성을 확인하는 역할 → 코드적인 유효성만을 검토

terraform plan

• 인프라를 변경하기 위한 실행 계획을 생성하는 역할 → 변경사항을 실제 적용하지는 않는다.
• apply 전에 의도한대로 인프라가 변경되는지 검토하는데 이용
• (+)는 create, (-)는 delete, (~)는 update, (-)(+)는 replace를 의미합니다.
• -detailed-exitcode
  • plan의 결과를 종료 코드로 반환하는 옵션 → 파이프라인 설계에서 활용 가능
  • 0: 변경 없이 성공(Succeeded with empty diff) / 1: 오류 / 2: 변경 있는 성공(Succeeded with non-empty diff)

terraform apply

• 인프라의 변경 사항을 적용하는 역할
• apply는 plan으로 생성되는 실행 계획이 필요하지만, 실행 계획이 없다면 자동으로 생성하고 승인할 것인지 묻는 메세지가 생성됩니다.
• -replace
  • configuration을 편집하지 않고 지정한 리소스를 recreate하는데 사용합니다.
  • plan과 apply에 모두 적용 가능
• -auto-approve
  • 실행 계획을 자동 승인하는 옵션입니다.
  • apply와 destroy에 모두 적용 가능

terraform destroy

• 테라폼으로 관리하는 모든 리소스를 삭제하며 테라폼으로 관리하지 않는 리소스는 삭제하지 않습니다.

terraform fmt

• configuration 파일에 테라폼 컨벤션과 스타일을 적용하는데 사용 → 주로 코드의 가독성을 높이기 위해 사용
• 코딩 스타일(빈칸, 정렬 등)에 의한 커밋을 줄이고 업데이트를 최소화할 수 있습니다.

3-2. HCL(HashiCorp configuration Language)

---

• 하시코프에서 개발한 오픈소스 도구 → 테라폼에서는 HCL이 코드 영역을 담당
• JSON의 단점 → 구문이 길어지고 주석이 지원되지 않음
• YAML의 단점 → 관리대상이 많아지고 구성이 복잡해질 경우 리소스 구성을 파악하기 어려움
• HCL은 JSON에 비해 동일한 내용을 50~70% 간결하게 작성 가능
• HCL은 주석과 변수, function도 제공

3-3. 테라폼 블록

---

• 테라폼 블록은 테라폼 자체의 구성(테라폼 버전, 프로바이더 버전 등)을 명시하는데 사용 → 버전을 명시적으로 선언하여 실행 오류를 최소화할 것을 권장
• 버전 체계는 시맨틱 버전 관리(Semantic Versioning)를 사용 → Major.Minor.Patch
• required_version → 테라폼 버전 지정
• required_version → 프로바이더 버전 지정

terraform {
  required_version = ">= 1.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.2.0"
    }
  }
}

• cloud 블록 → TF Cloud 또는 TF Enterprise를 선언
• backend 블록 → 테라폼 실행 시 저장되는 State의 저장 위치를 선언
  • 테라폼은 State의 데이터를 사용해 코드로 관리된 리소스를 탐색하고 추적한다.
  • 테라폼은 실행되는 동안 .terraform.tfstate.lock.info라는 파일로 State를 동시에 사용하지 못하도록 잠금 처리합니다.
    → -lock=false라는 옵션으로 잠금을 무시할 수도 있지만 정상적인 경우라면 다른 작업이 수행 중일수 있으므로 주의해야한다.
• 백엔드는 다중으로 선택할 수 없습니다.

3-4. 리소스(resource)

---

• 리소스 블록 → 선언된 항목 생성을 수행하고 resource로 시작한다.

  • name은 동일한 유형에 대해 식별자 역할을 하기 때문에 유형이 같은 경우에는 같은 이름을 사용할 수 없다.

    resource "<provider>_<resource_type>" "<name>" {
      <인수> = <값>
    }

• 종속성 → 테라폼은 종속성을 고려하여 리소스를 프로비저닝합니다.

  • 종속성에는 암시적 종속성과 명시적 종속성이 있습니다.
    • 암시적 종속성은 테라폼에 의해 자동으로 부여됩니다.
    • 명시적 종속성은 depends_on으로 부여할 수 있습니다.
  • 종속성이 없는 동일 수준의 리소스를 생성하는 경우 병렬적으로 프로비저닝됩니다.

• 리소스 argument와 attribute

  • argument는 리소스를 생성할 때 지정하는 값(사용자가 지정 가능)

  • attribute는 생성된 리소스가 가진 속성(사용자가 지정 불가능)

  • argument와 attribute는 참조가 가능하다.

  • 아래의 예시에서 ami와 instance_type는 argument이고, 생성된 EC2 인스턴스의 arn, private ip는 attribute이다.

    resource "aws_instance" "example" {
      ami = "ami-01234567890abcde"
      instance_type = "t2.micro"
    }

• lifecycle → 리소스의 수명주기를 컨트롤하는 메타인수
  • create_before_destroy → 리소스 replace하는 경우 생성 후 삭제하도록 합니다. 기본적으로 replace는 삭제 후 생성입니다.
  • pervent_destroy → 리소스 삭제(Destroy)를 명시적으로 거부
  • ignore_changes → 변경 사항을 추적하지 않고자 하는 리소스를 선언
  • precondition → 리소스 생성 전 argument를 검증
  • postcondition → 리소스 생성 후 결과를 검증