Terraform 소개

Terraform은 인프라를 코드(IaC, Infrastructure as Code)로 관리할 수 있게 해주는 오픈소스 도구

코드형 인프라 IaC(Infrastructure as Code)

• 인프라가 코드로 표현되고, 코드가 인프라를 설명한다는 의미로 사용자 인터페이스나 커맨드를 이용한 수동 조작이 아닌 코드로 대상을 관리한다는 것
• 컴퓨터에서 읽을 수 있는 정의 파일을 사용해 인프라나 서비스를 관리하고 프로비저닝하는 프로세스이다.

작업 흐름

Terraform 구성 파일에는 원하는 리소스와 공급자 설정을 선언한다. 현재 상태를 읽은 뒤 원하는 상태와 비교해 변경 계획을 보여주고, 사용자가 적용하면 실제 인프라를 바꾼다.

flowchart LR
  구성[.tf 구성 작성] --> 초기화[terraform init]
  초기화 --> 계획[terraform plan]
  계획 --> 검토[변경 계획 검토]
  검토 --> 적용[terraform apply]
  적용 --> 상태[상태 파일 갱신]

plan에는 생성뿐 아니라 교체나 삭제도 나타날 수 있다. 적용 전에 대상 환경과 변경 대상을 확인한다. 상태 파일에는 민감한 속성이 포함될 수 있으므로 팀에서 쓰는 원격 상태 저장소의 접근 권한과 잠금 정책을 정해야 한다. .tfstate를 공개 저장소에 올려서는 안 된다.

IaC의 이점은 설정을 버전 관리하고 변경 이유를 코드 리뷰할 수 있다는 점이다. 반면 콘솔에서 수동으로 바꾼 값과 코드가 달라지는 드리프트가 생길 수 있으므로 정기적으로 계획을 확인한다.

적용 전 점검 순서

terraform fmt -check
terraform validate
terraform plan

fmt -check는 서식이 맞는지, validate는 구성의 기본 문법과 참조가 타당한지 확인한다. plan은 현재 상태를 읽어 실제 변경 후보를 계산한다. 따라서 앞의 두 검사가 통과해도 plan에서 권한 오류나 대상 환경의 상태 차이가 드러날 수 있다. 변경 계획에서 +는 생성, ~는 수정, -는 삭제를 의미한다.

예를 들어 서버 인스턴스의 이름만 바꾸려 했는데 계획에 리소스 교체가 나타나면, 공급자에서 해당 속성을 현장 수정할 수 없어 다시 만드는 것일 수 있다. 데이터나 서비스 중단 영향이 있는지 검토하고 적용 여부를 결정한다. 팀에서는 동일한 구성에 여러 사람이 동시에 apply하지 않도록 상태 잠금을 사용한다. 구성 파일에는 비밀 값을 직접 쓰지 않고, 변수를 통해 안전한 저장소에서 주입한다. 단, 변수로 받았다는 이유만으로 상태 파일에서 비밀 값이 사라지는 것은 아니다.

참고: Terraform 계획 명령, 민감한 데이터 관리

작은 구성으로 흐름 확인하기

클라우드 계정 없이 동작을 익히려면 local 공급자로 로컬 파일 하나를 관리할 수 있다. 다음 예시는 실습용 디렉터리에서만 실행한다. Terraform이 만든 파일을 사람이 다시 고치면 다음 계획에 드리프트가 나타난다.

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "greeting" {
  filename = "${path.module}/hello.txt"
  content  = "hello from Terraform\n"
}

output "created_file" {
  value = local_file.greeting.filename
}

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan
cat hello.txt
terraform state list

init은 선언한 공급자 플러그인을 내려받고 작업 디렉터리를 초기화한다. 처음 계획에는 local_file.greeting 생성이 표시된다. apply 후 파일 내용을 보면 선언한 문자열이 기록돼 있어야 한다. terraform state list는 상태가 추적하는 리소스 주소를 보여 준다. .terraform.lock.hcl은 선택한 공급자 버전을 재현하는 데 도움이 되므로 팀 저장소에 포함하는 편이 일반적이다. 로컬 .terraform/ 디렉터리와 상태 파일은 보통 버전 관리에서 제외한다.

이 실습의 파일을 손으로 수정한 뒤 terraform plan을 실행하면 Terraform은 실제 파일, 현재 구성, 마지막 상태를 비교한다. 공급자가 해당 변경을 어떻게 보고하는지에 따라 다시 쓰기 또는 교체가 계획될 수 있다. Terraform은 모든 인프라 속성을 실시간 감시하는 도구가 아니다. 계획을 실행할 때 공급자가 읽는 값과 상태를 바탕으로 차이를 계산한다. 따라서 콘솔 변경, 삭제 또는 권한 부족이 있으면 계획 결과를 직접 검토해야 한다.

flowchart LR
  C[구성: 원하는 상태] --> P[plan]
  S[상태: 마지막으로 추적한 정보] --> P
  R[공급자가 읽은 실제 대상] --> P
  P --> V[추가·수정·교체·삭제 검토]
  V --> A[apply]
  A --> S

계획에서 무엇을 판단할까

예를 들어 서버 이름을 바꿨을 뿐인데 -/+가 나오면 공급자가 해당 속성을 제자리에서 수정하지 못해 리소스를 교체한다는 뜻일 수 있다. 새 인스턴스로 바뀌면 IP나 연결, 데이터가 영향을 받을 수 있으므로 속성 하나만 보고 승인해서는 안 된다. plan -out=tfplan은 검토한 계획을 파일로 저장하고 apply tfplan은 그 계획을 적용한다. 계획 파일에도 민감한 값이 들어갈 수 있으므로 저장·공유 범위를 제한한다. 오래된 계획은 현재 인프라와 어긋날 수 있으므로 적용 직전에 다시 확인한다.

증상	확인할 내용
init에서 provider 다운로드 실패	네트워크, 레지스트리 접근, 버전 제약
validate 성공 후 plan 실패	실제 API 인증·권한, 공급자 설정, 상태 접근
예상 밖의 삭제·교체	변경된 리소스 주소와 속성, 수동 변경 여부
상태 잠금 오류	다른 실행이 끝났는지 확인하고 공유 백엔드의 잠금 정책 확인

팀에서는 같은 상태를 여러 사람이 각자 로컬 파일로 관리하면 각자 다른 현실을 바탕으로 계획한다. 공유 상태 저장소, 접근 제한, 잠금 정책을 갖춰야 한다. sensitive로 표시한 출력은 CLI 화면에서 가릴 수 있어도 상태와 계획 파일에 값이 남을 수 있다. 실습을 끝내고 만든 리소스를 제거하려면 terraform plan -destroy로 대상을 검토한 뒤 terraform destroy를 실행한다. 실제 인프라에서는 이 명령이 데이터를 지울 수 있으므로 대상 작업 공간과 백업을 먼저 확인한다.

참고: Terraform 구성·초기화 실습, terraform init, 계획과 적용, 상태의 민감 정보.