Terraform 프로비저닝과 배포 전략
1️⃣ Terraform으로 EC2, VPC, RDS, Kubernetes 클러스터 생성
1 EC2 인스턴스 생성 예제
provider "aws" {
region = "ap-northeast-2"
}
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t2.micro"
tags = {
Name = "Terraform-Web"
}
}
2 VPC 생성 예제
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "main-vpc"
}
}
3 RDS 생성 예제
resource "aws_db_instance" "default" {
engine = "mysql"
instance_class = "db.t3.micro"
name = "mydb"
username = "admin"
password = "password"
allocated_storage = 20
skip_final_snapshot = true
}
4 Kubernetes 클러스터 (EKS) 생성 예제
Terraform 공식 모듈 사용:
module "eks" {
source = "terraform-aws-modules/eks/aws"
cluster_name = "my-eks-cluster"
cluster_version = "1.29"
subnets = ["subnet-abc", "subnet-def"]
vpc_id = "vpc-123456"
}
2️⃣ terraform apply의 원자적(Atomic) 실행 원리
1 계획 → 적용의 원자성
Terraform은 terraform plan
→ terraform apply
과정에서 예상된 변경만 실행하며,
중간에 실패하면 해당 단계에서 자동 롤백하지 않음. 따라서 실행 전 계획이 중요!
1. Plan 단계 → 무슨 일이 일어날지 예측
2. Apply 단계 → 계획된 작업만 순서대로 실행
🧠 Terraform은 변경 사항을 순차적으로 실행하며, 중간 실패 시 이전 상태를 유지하는 것이 아닌 중단됨
→ 복구는 수동 또는 모듈 단위 재적용 필요
3️⃣ 인프라 변경 사항 롤백 전략 (terraform destroy 활용)
1 롤백 방법
- 잘못된 리소스가 배포되었을 경우
terraform destroy
로 제거 - 또는 상태 파일 이전 버전으로 복원 (
.tfstate
백업)
terraform destroy
2 보다 안전한 전략
plan
파일 저장 및 검토
terraform plan -out=tfplan
terraform apply tfplan
- 단계적 배포 (workspace, module 기반)
🧩 terraform destroy
는 강력하지만 모든 인프라를 제거할 수 있으므로 주의!
4️⃣ Blue-Green Deployment & Canary Deployment
1 Blue-Green Deployment
- 두 개의 환경(Blue & Green)을 운영하고 트래픽을 새 환경(Green)으로 전환
- Terraform에서는 ALB나 Route53 레코드를 변경하여 배포 전환
resource "aws_lb_listener_rule" "green" {
# Green target group으로 전환
}
🟦 Blue: 현재 운영 중
🟩 Green: 새로운 버전
➡ 전환 시 장애 없이 배포 가능
2 Canary Deployment
- 신규 리소스를 소량만 배포 → 문제 없으면 점차 전체 배포
- Terraform 단독으론 어렵고, 스크립트 + Terraform을 병행 사용
# 처음엔 EC2 1대만 신규 배포 후 점진 확장
count = var.deploy_stage == "canary" ? 1 : 3
5️⃣ GitOps와 Terraform (ArgoCD, Flux와의 연계)
1 GitOps 개요
- Git이 단일 진실의 출처(Single Source of Truth)
- Git에 변경 사항을 Push → 자동으로 적용됨
2 Terraform과의 연결 구조
Terraform은 Terraform Apply
가 수동 작업이므로 아래와 같이 구성
Git Repo (Terraform 코드)
↓
CI (Terraform fmt, validate, plan)
↓
CD (apply 승인, 상태 저장 백엔드 연동)
🎯 ArgoCD나 Flux는 일반적으로 Kubernetes용 YAML에 적합
Terraform은 GitOps + CI/CD 조합으로 연동
6️⃣ Terraform과 CI/CD 파이프라인 구축
1 CI/CD 흐름
1. Git Push
2. GitHub Actions / GitLab CI:
- terraform fmt
- terraform validate
- terraform plan -out=plan.out
- manual approve step
- terraform apply plan.out
2 GitHub Actions 예시
name: Terraform CI/CD
on:
push:
branches: [ "main" ]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Terraform
uses: hashicorp/setup-terraform@v2
- name: Terraform Init
run: terraform init
- name: Terraform Plan
run: terraform plan -out=tfplan
- name: Terraform Apply
if: github.ref == 'refs/heads/main'
run: terraform apply -auto-approve tfplan
📌 정리
전략 요소 | 설명 |
---|---|
EC2/VPC/RDS/K8s | 다양한 인프라 리소스를 선언적으로 생성 |
Atomic 실행 | 예상된 변경만 실행하고 중간 실패 시 멈춤 |
롤백 전략 | destroy 또는 상태 복원으로 복구 |
배포 전략 | Blue-Green, Canary로 무중단 배포 |
GitOps | Git 기반 인프라 제어 (CI/CD + Git) |
CI/CD 연동 | 자동 포맷, 검증, 계획, 적용 가능 |
마지막 수정일자