[T101]4주차 - State & 모듈 & 협업 1/2 -1편 : 상태파일

 

테라폼에서 중요한 상태파일에 대해 배웠습니다.

1편은 상태파일에 대해서

2편은 문제상황으로 풀어봅니다

3편 모듈에 대해 작성합니다.

[상태파일]

• 상태 파일은 배포할 때마다 변경되는 프라이빗 API private API로, 오직 테라폼 내부에서 사용하기 위한 것입니다.
• 테라폼 상태 파일을 직접 편집하거나 직접 읽는 코드로 작성해서는 안됩니다.

 

개인적으로 사용하는 것은 문제가 안되지만 팀끼리 리소스를 사용할 때 문제가 될 수 있습니다.

[팀 단위에서 테라폼 운영 시 문제점]

1. 상태 파일을 저장하는 공유 스토리지 Shared storage for state files
   • 각 팀원이 동일한 테라폼 상태 파일 사용을 위해서, 공유 위치에 저장이 필요
2. 상태 파일 잠금 Locking state files
   • 잠금 기능 없이 두 팀원이 동시에 테라폼 실행 시 여러 테라폼 프로세스가 상태 파일을 동시에 업데이트하여 충돌 가능(경쟁 상태 race condition)
3. 상태 파일 격리 Isolating state files
   • 예를 들면 테스트 dev 와 검증 stage 과 상용 prodction 각 환경에 대한 격리가 필요

 

만약에 상태 파일을 공유해서 버전을 관리한다면? 비 추천합니다!

[why? 상태 파일 공유로 버전 관리 시스템 비추천]

1. 수동 오류 Manual error
   • 테라폼을 실행하기 전에 최신 변경 사항을 가져오거나 실행하고 나서 push 하는 것을 잊기 쉽습니다(?).
   • 팀의 누군가가 이전 버전의 상태 파일로 테라폼을 실행하고, 그 결과 실수로 이전 버전으로 롤백하거나 이전에 배포된 인프라를 복제하는 문제가 발생 할 수 있음.
2. 잠금 Locking
   • 대부분의 버전 관리 시스템(VCS)은 여러 명의 팀 구성원이 동시에 하나의 상태 파일에 terraform apply 명령을 실행하지 못하게 하는 잠금 기능이 제공되지 않음.
3. 시크릿 Secrets
   • 테라폼 상태 파일의 모든 데이터는 평문으로 저장됨. 민감 정보가 노출될 위험.
   • 실제로 시크릿키 등이 노출되어서 리소스가 털릴 위험이 매우 높음(나도 알고싶지않았음)

 

그렇다면 원격으로 지원해주는 백엔드는 없을까?

[지원되는 원격 백엔드]

AWS S3, Azure Blob Storage, Google Cloud Storage, Consul, Postgres database 등 

링크 → 위 제약사항에 대한 해결방안!

1. 수동 오류 해결 : plan/apply 실행 시 마다 해당 백엔드에서 파일을 자동을 로드, apply 후 상태 파일을 백엔드에 자동 저장
2. 잠금(Lock) : apply 실행 시 테라폼은 자동으로 잠금을 활성화, -lock-timout=<TIME> 로 대기 시간 설정 지정 가능
3. 시크릿 : 대부분 원격 백엔드는 기본적으로 데이터를 보내거나 상태 파일을 저장할 때 암호화(Encryption)하는 기능을 지원

 

예를 든다면 S3 + DynamaDB를 동작하는 방식으로 이해할 수 있겠습니다.

https://developer.hashicorp.com/terraform/language/settings/backends/configuration

Backend Configuration - Configuration Language | Terraform | HashiCorp Developer

Terraform — Remote States Overview의 좋은 블로그 글이 있습니다.

 

Terraform — Remote States Overview

 

그렇다면 어떻게 사용하면 좋을까?

• 테라폼은 Stateful 애플리케이션. 프로비저닝 결과 State를 저장하고 추적에 활용
  • 개인 1인 : 로컬 환경으로 terraform.tfstate 파일에 JSON 형태로 저장
  • 팀이나 조직 : 공동 관리를 위해 원격 저장소에 저장해 공유 - 링크
  • State에는 작업자가 정의한 코드와 실제 반영된 프로비저닝 결과를 저장하고, 이 정보를 토대로 이후의 리소스 생성, 수정, 삭제에 대한 동작 판단 작업을 수행하는 것이 필요하다.

State 역할

State에는 테라폼 구성과 실제를 동기화하고 각 리소스에 고유한 아이디(리소스 주소)로 맵핑 리소스 종속성과 같은 메타데이터를 저장하고 추적 테라폼 구성으로 프로비저닝 결과를 캐싱하는 역할을 수행

 

[실습하기]

#main.tf
mkdir 5.1 && cd 5.1

#random_password
resource "random_password" "mypw" {
  length           = 16
  special          = true
  override_special = "!#$%"
}

 

[실행하기]

랜덤 프로바이더는 테라폼 구성 내에서 무작위로 기입해야 되는 숫자, 패스워드, 문자열 등의 값을 생성하는 데 사용합니다.

# 
terraform init && terraform plan

#
terraform apply -auto-approve

# State List 및 생성된 Password 확인
terraform state list
terraform state show random_password.mypw

# State에 저장된 result를 확인해보자! -> 어떻게 관리해야할까요?
ls *.tfstate
cat terraform.tfstate | jq
cat terraform.tfstate | jq | grep result
DHJFgy341EFDfgRs

# (참고) sensitive value 내용은 테라폼 콘솔에서 보일까요? (생각해보세용)
echo "random_password.mypw" | terraform console echo "random_password.mypw.result" | terraform console

• 테라폼에서는 JSON 형태로 작성된 State를 통해 속성과 인수를 읽고 확인할 수 있다. 테라폼에서는 type과 name으로 고유한 리소스를 분류하며, 해당 리소스의 속성과 인수를 구성과 비교해 대상 리소스를 생성, 수정, 삭제한다.
• State는 테라폼만을 위한 API로 정의할 수도 있다. Plan을 실행하면 암묵적으로 refresh 동작을 수행하면서 리소스 생성의 대상(클라우드 등)과 State를 기준으로 비교하는 과정을 거친다. 이 작업은 프로비저닝 대상의 응답 속도와 기존 작성된 State의 리소스 양에 따라 속도 차이가 발생한다. 대량의 리소스를 관리해야 하는 경우 Plan 명령에서 -refresh=false 플래그를 사용해 State를 기준으로 실행 계획을 생성하고, 이를 실행에 활용해 대상 환경과의 동기화 과정을 생략할 수 있습니다.

 

# 실행 계획 생성 시 저장되어 있는 State와 실제 형상을 비교하는 기본 실행
time terraform plan

# 실행 계획 생성 시 실제 형상과 비교하지 않고 실행 계획을 생성하는 -refresh=false 옵션
time terraform plan -refresh=fa

 

다음은 상황에 따른 상태파일을 만들어보겠습니다.