클라우드 콘솔을 클릭하는 것은 하나의 서버에 적합합니다. 스테이징 및 프로덕션에서 동일한 설정이 필요하거나 누군가 지난 3월에 방화벽 규칙을 변경한 사람이 누구인지 묻는 경우에는 문제가 발생합니다. 이 초보자를 위한 Terraform 튜토리얼에서는 인프라를 코드로 설명하고 도구를 사용하여 이를 현실화하는 더 나은 방법을 보여줍니다.

대부분의 튜토리얼은 클라우드 계정으로 시작하므로, 아무것도 배우기도 전에 청구 위험이 추가됩니다. 컴퓨터에 파일을 생성만 하므로 실수에 따른 비용이 전혀 발생하지 않는 Terraform의 local 공급자부터 시작하겠습니다. 이러한 예제와 샘플 출력은 이 기사에서 실행하지 않은 표준 그림이며 정확한 표현은 버전에 따라 다릅니다.

테라폼이란 무엇입니까?

Terraform은 HashiCorp의 IaC(Infrastructure as Code) 도구입니다. HashiCorp 구성 언어인 HCL로 구성 파일을 작성하여 원하는 최종 결과를 설명합니다. 그런 다음 Terraform은 거기에 도달하기 위해 무엇을 생성, 변경 또는 삭제할지 알아냅니다.

공급자라는 플러그인을 통해 플랫폼과 통신합니다. AWS, Azure, Google Cloud, Kubernetes, GitHub, Cloudflare 등을 위한 공급자가 있으므로 모든 공급자에서 하나의 워크플로를 사용할 수 있습니다.

한 가지 알아야 할 사항: 2023년에 HashiCorp는 Terraform을 비즈니스 소스 라이선스로 전환했습니다. 그런 다음 커뮤니티에서는 매우 유사한 명령과 구성을 사용하는 오픈 소스 포크인 OpenTofu를 만들었습니다. 여기서 배우는 내용은 대체로 두 가지 모두에 적용됩니다.

왜 코드형 인프라인가?

Terraform은 또한 선언적입니다. “서버를 세 번 만듭니다”가 아니라 “서버가 세 개 있어야 합니다”라고 말합니다. 이미 2개가 있으면 1개를 추가합니다. 단순히 단계를 반복하는 스크립트는 결국 세 개를 더 생성하게 될 수 있습니다.

Terraform 설치

운영 체제에 대한 공식 HashiCorp 지침을 사용하여 설치한 후 작동하는지 확인합니다.

terraform -version

프로젝트에 대한 빈 폴더를 만듭니다. Terraform은 현재 폴더의 모든 .tf개 파일을 읽으므로 폴더 하나는 구성 하나와 같습니다.

첫 번째 구성

main.tf이라는 파일을 만듭니다.

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

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

resource 블록을 보세요. 작성하는 거의 모든 것이 이 모양을 따릅니다. local_file는 리소스 유형이고, greeting은 구성 내에서 이에 대한 사용자 고유 이름입니다. 이들은 함께 주소를 형성합니다: local_file.greeting. 내부 인수는 원하는 것을 설명합니다.

워크플로: 초기화, 계획, 적용

테라폼 초기화

그러면 폴더가 준비되고 요청한 공급자가 다운로드됩니다. 시작할 때 한 번 실행하고 공급자나 모듈을 추가할 때마다 다시 실행하세요. 또한 정확한 공급자 버전을 기록하는 .terraform.lock.hcl 파일도 생성됩니다. 해당 파일을 Git에 커밋합니다.

terraform init

테라폼 계획

이는 코드를 기존 코드와 비교하고 아무것도 건드리지 않고도 계획된 변경 사항을 표시합니다.

terraform plan

# local_file.greeting will be created
+ resource "local_file" "greeting" {
    + content  = "Hello from Terraform\n"
    + filename = "./hello.txt"
  }

Plan: 1 to add, 0 to change, 0 to destroy.

많은 계획을 읽을 것이므로 기호를 배우십시오.

테라폼 적용

그러면 계획이 다시 표시되고 확인을 요청한 후 변경됩니다.

terraform apply

yes을 입력하면 hello.txt가 나타납니다. 이제 terraform plan을 다시 실행하세요. 현실이 이미 코드와 일치하므로 변경 사항이 보고되지 않습니다. 반복적으로 실행해도 더 이상 변경되지 않는 이 속성을 멱등성이라고 합니다.

변화와 파괴

content 줄을 편집하고 terraform plan를 실행합니다. Terraform은 차이점을 발견하고 변경을 제안합니다. 이 리소스의 경우 파일을 대체합니다. 데이터베이스를 다시 만들면 데이터가 손실될 수 있으므로 실제 인프라의 교체에 주의하세요.

다음으로 hello.txt을 직접 삭제하고 다시 계획하세요. Terraform은 해당 항목이 누락되었음을 확인하고 이를 다시 만들 것을 제안합니다. 코드와 현실의 차이를 드리프트라고 하며, 이를 감지하는 것이 도구의 주요 이점 중 하나입니다.

이 구성에서 관리하는 모든 항목을 제거하려면 다음을 실행하세요.

terraform destroy

변수 및 출력

하드 코딩된 값은 코드 재사용을 방지합니다. 입력 변수는 구성을 유연하게 만들고 출력은 유용한 값을 다시 보고합니다.

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment environment"
  default     = "dev"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Use dev, staging or prod."
  }
}

# main.tf
resource "local_file" "config" {
  filename = "${path.module}/${var.environment}.txt"
  content  = "environment=${var.environment}\n"
}

# outputs.tf
output "config_path" {
  value = local_file.config.filename
}

명령줄에서 값을 설정하거나 자동으로 로드되는 terraform.tfvars이라는 파일에 값을 유지합니다.

terraform apply -var="environment=staging"

출력에서 local_file.config.filename을 사용하는 것도 리소스가 서로를 참조하는 방식입니다. Terraform은 이러한 참조를 읽고 항목을 생성하는 올바른 순서를 결정합니다.

Terraform 상태

신청하시면 terraform.tfstate이라는 파일을 찾으실 수 있습니다. 이는 Terraform이 관리하는 내용에 대한 기록으로, 코드를 실제 객체에 매핑합니다. 이것이 없으면 Terraform은 local_file.greeting가 해당 특정 파일인지 알 수 없습니다.

여기서는 세 가지 규칙이 중요합니다.

1. Git에 상태를 커밋하지 마세요. 일반 텍스트로 비밀번호와 기타 비밀을 포함할 수 있습니다.
2. 손으로 편집하지 마십시오. terraform state list, terraform state mv과 같은 명령을 사용하십시오.
3. 팀 프로젝트에는 원격 백엔드를 사용하세요. 공유 백엔드는 상태를 중앙에 저장하고 잠그므로 두 사람이 동시에 신청할 수 없습니다.

다음은 미리 생성한 버킷과 함께 Amazon S3를 사용하는 일반적인 백엔드입니다.

terraform {
  backend "s3" {
    bucket       = "my-company-terraform-state"
    key          = "shop/prod/terraform.tfstate"
    region       = "ap-south-1"
    encrypt      = true
    use_lockfile = true
  }
}

실제 클라우드 리소스

클라우드로 이동해도 워크플로는 변경되지 않습니다. 다음은 AWS의 S3 버킷입니다. 먼저 가격을 확인하고 연습하는 동안 만든 모든 것을 폐기하세요.

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "reports" {
  bucket = "my-unique-reports-bucket-2026"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

Terraform은 AWS CLI 설정 또는 환경 변수에서 자격 증명을 가져옵니다. .tf 파일에 액세스 키를 쓰지 마십시오.

모듈

모듈은 단순히 다양한 입력으로 호출할 수 있는 Terraform 파일의 폴더입니다. 이는 함수와 매우 유사하게 작동하므로 패턴을 한 번 정의하고 재사용할 수 있습니다.

project/
  main.tf
  modules/
    reports_bucket/
      main.tf
      variables.tf
      outputs.tf

module "staging_reports" {
  source      = "./modules/reports_bucket"
  environment = "staging"
}

module "prod_reports" {
  source      = "./modules/reports_bucket"
  environment = "prod"
}

공용 Terraform 레지스트리에도 기성 모듈이 있지만 사용하기 전에 먼저 읽어보고 버전을 고정하세요. 모듈을 너무 일찍 구축하지 마십시오. 패턴을 최소한 두 번 반복할 때까지 기다리십시오.

안전한 팀 작업흐름

1. 브랜치를 생성하고 .tf 파일을 변경합니다. 복습이 필요한 경우 초보자를 위한 Git 튜토리얼을 참조하세요.
2. terraform fmt과 terraform validate를 실행합니다.
3. 검토를 위해 terraform plan의 출력을 첨부하여 풀 요청을 엽니다.
4. 승인 후에는 통제된 단일 장소(이상적으로는 파이프라인)에서 저장된 계획을 적용하세요.

계획을 저장하면 검토한 내용을 정확하게 적용할 수 있습니다.

terraform plan -out=tfplan
terraform apply tfplan

이는 CI/CD 및 GitHub Actions에 자연스럽게 들어맞습니다. Terraform은 일반적으로 클러스터를 프로비저닝하고 Kubernetes와 같은 도구를 사용하여 그 위에서 애플리케이션을 실행합니다.

일반적인 실수

• 계획서를 읽지 않고 신청합니다. 데이터베이스에 하나 -/+를 두는 것은 매우 비용이 많이 드는 놀라움일 수 있습니다.
• 한 대의 노트북에 상태를 유지합니다. 노트북을 잃어버리면 Terraform이 인프라를 추적할 수 없게 됩니다.
• 콘솔을 수동으로 변경합니다. 드리프트가 발생하고 다음 적용 시 실행 취소될 수 있습니다.
• 고정되지 않은 버전 사용. 의도적으로 업그레이드가 이루어지도록 공급자 및 모듈 버전을 고정합니다.
• 하나의 거대한 구성을 사용합니다. 환경이나 시스템별로 분할하면 실수로 인한 피해가 제한됩니다.

마무리

이제 거의 모든 Terraform 작업의 기본 아이디어인 리소스 선언, 계획 검토, 적용 및 국가 보호를 확인했습니다. 워크플로가 자연스럽게 느껴질 때까지 local 공급자와 연습한 다음 무료 계층 계정에서 하나의 작은 실제 리소스를 관리하세요. 두 명 이상의 사람 또는 두 개 이상의 환경이 관련되면 원격 상태 및 모듈을 가져옵니다.

자주 묻는 질문

계속 학습하세요