[26] tfstate 개념

[0]

terraform.tfstate?

Terraform이 알고 있는 현실 인프라의 스냅샷

 

-

 

[1]

tfstate안에 들어 있는 정보

1. 실제 생성된 리소스 정보

-> Terraform 코드에는 없고, apply 이후에만 알 수 있는 현실값 (pointer)

👉 AWS 콘솔에서만 알 수 있는 값들

• EC2 instance ID
• ENI ID
• Subnet ID
• Security Group ID
• 실제 할당된 IP
• RDS endpoint
• ALB ARN

"resources": [
  {
    "type": "aws_instance",
    "name": "web",
    "instances": [
      {
        "attributes": {
          "id": "i-0abc1234",
          "private_ip": "10.0.1.15",
          "subnet_id": "subnet-aaa",
          ...
        }
      }
    ]
  }
]

 

2. Terraform 리소스 <-> 실제 리소스 매핑 정보

aws_instance.web -> i-0abc1234

이게 없으면 terraform은 이 EC2를 내가 만든건지

지워야 할지, 수정해야 할지를 판단 못함

 

3. 의존성 graph

이 리소스는 어떤 리소스 뒤에 만들어졌는지

어떤 값이 어떤 output을 참고했는지

 

-> 그래프 순서 보장 / 병렬 생성 / 안전한 destroy가 가능

 

4. 민감 정보

- DB password

- IAM role inline Policy

- 일부 Provider 토큰

- user_data 결과

 

-> 이 민감정보 때문에 Git에 올리면 안되고

-> S3 backend + 암호화 + 접근제어 필수

 

-

 

[2]

backend key?

S3 버킷 안에서 tfstate 파일이 저장되는 객체 경로

s3://my-terraform-state-bucket/
 ├── bootstrap/terraform.tfstate
 ├── main/terraform.tfstate
 ├── env/dev/terraform.tfstate
 └── env/prod/terraform.tfstate

 

-

[3]

key의 설계 의미 (아키텍쳐 관점)

 

1.

state isolation

- bootstrap vs main

- dev vs prod

- Network vs APP

key 하나 = Terraform state 하나

 

2.

협업 안정성

- 같은 key를 쓰는 사람 = 같은 인프라

- 실수로 Prod를 건드리는 사고 방지

 

3.

DynamoDB Lock과 1:1 매칭

- key 단위로 Lock

- 한 사람이 apply 중이면 -> 다른 사람 접근 차단

 

* URL 아님 / 디렉터리 개념도 아님 / 그냥 문자열 경로처럼 보이는 object key

 

-

 

[4]

요구사항

- 상태 파일 분실 / 충돌 방지

- 여러 명이 동시에 작업 가능

- env (prod / dev) 분리

- 민감 정보 보호

 

-

 

[5]

아키텍쳐 대응

상태 중앙 관리 : S3 backend

동시 작업 방지 : DynamoDB Lock

환경 분리 : KEY 분리

보안 : S3암호화 + IAM

변경 이력 : Git으로 코드 관리

 

-

 

[6]

그 후 backend

terraform {
	backend "s3" {
    	bucket = "my-tf-state-bucket"
        key = "envs/prod/terraform.tfstate"
        region = "ap-northeast-2"
        dynamodb_table = "my-tf-lock"
        encrypt = true
    }
}

락은 Terraform이 건다

둘 사이를 묶어 주는 것은 Terraform backend 구현 로직

AWS 입장에서는 S3와 DDB 서로 참조 X

Terraform이 같은 작업 세션 안에서 S3에 쓰고, DDB에 락 레코드도 쓰는 것

Terraform이 DDB를 락 서비스로 사용하는 것

 

 

-

 

[7]

실제로 Terraform이 apply에서 하는 일

 

1. DDB에 Lock 생성 (조건부 PutItem)

pre : 조건 / 이미 LockID가 있으면 실패 

- table : my-tf-lock

- key : LockID

- value : 보통 buckey + key 같은 이 state에 대한 고유 식별자를 Terraform이 만들어 쓴다

 

2.

S3에서 state 읽기 / 변경 반영

객체 : s3://my-tf-state-bucket/envs/prod/terraform.tfstate

 

3.

S3에 state 업데이트 저장

 

4.

DDB에서 Lock 삭제

(DeleteItem)

 

-

 

[8]

락의 단위

bucket + key 조합이 이 state를 대표

그래서 보통 Lock도 이 state 파일에 대한 락으로 잡힘

 

IAM권한이 둘 다 필요

Terraform을 실행하는 주체 = AWS CLI Profile / ROLE

-> S3 읽기 쓰기 권한 

-> DDB PutItem / GetItem / DeleteItem