Windows 10 환경에서 Terraform을 이용한 AWS 자원 배포 - 5. Terraform 상태관리와 Backend
Terraform의 상태관리
이전 실습에서 Terraform을 수행할 때 terraform.tfstate 파일이 생성되는 것을 확인 할 수 있었다.
해당 파일을 열어보면 아래와 같은 내용을 보관하고 있다.
c:\terraform_study\git_repository\ersia_t101\week1>type terraform.tfstate
{
"version": 4,
"terraform_version": "1.3.2",
"serial": 49,
"lineage": "6a164758-73a9-95a6-8b80-cd32c4e12e13",
"outputs": {
"public_ip": {
"value": "3.39.251.108",
"type": "string"
}
},
"resources": [
{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"schema_version": 1,
"attributes": {
"ami": "ami-0e9bfdb247cc8de84",
"arn": "arn:aws:ec2:ap-northeast-2:411158671563:instance/i-04c3c39f42296c298",
"associate_public_ip_address": true,
"availability_zone": "ap-northeast-2a",
"capacity_reservation_specification": [
{
"capacity_reservation_preference": "open",
"capacity_reservation_target": []
}
...
...
...terraform.tfstate 파일의 내용을 보면 미루어 짐작해볼 수 있듯,
terraform은 명령 수행 시 실제 적용한 Resource에 대한 상태(자원 정보 및 기동 유무 등) 정보를 해당 파일에 저장해서 보관하고 있다.
terraform.tfstate 파일은 테스트 해본 결과 아래와 같은 특징을 지녔다.
- JSON 형식을 통해 파일을 기록한다.
- 작업 시 명령 수행 전 상태를 보관하는 terraform.tfstate.backup 파일까지 총 2개의 상태관리 파일을 유지한다.
(terraform apply를 여러번 수행해도 terraform.tfstate, terraform.tfstate.backup 파일 2개만 유지됨) - terraform 수행 시 상태파일의 serial 번호로 어떤 상태가 이전이고 나중인지 구분한다.
(명령 수행 시 마다 serial 번호가 증가함)
이와 같이 상태 파일은 실제 클라우드 플랫폼에서 제공하는 것이 아닌
Terraform 내부에서 사용하기 위한 일종의 내부 로직(Private API)이라고 볼 수 있다.
Terraform은 상태파일을 통해서 현재 클라우드 상에서 배포된 Resource와 상태파일에 보관된 Resource를 비교해
create, delete 등을 알려준다고 볼 수 있다.
따라서 Terraform 상태파일을 직접 편집하는 등의 행위를 하면 안된다.
(만약 상태파일 변경이 필요한 경우 terraform import와 같은 명령을 제공하나, 실제 실무에 적용해보시는 분들의 경험담에 의하면 terraform import을 완벽하게 사용하기 어렵다고 한다.(연관된 Resource가 너무 복잡하게 얽혀있기 때문에..))
Terraform을 팀 단위로 사용할 때의 상태관리
여러 사용자와 같은 Resource를 Terraform으로 관리할 경우 상태관리의 어려움은 더 커진다.
Terraform을 다루는 책에서는 아래와 같은 고려사항을 설명한다.
- 상태 파일을 저장하는 공유 스토리지의 문제 (Shared storage for state files)
- 각 팀원이 동일한 테라폼 상태 파일 사용을 하기 위해선 공유 저장소에 파일이 위치해야한다.
- 상태 파일 잠금의 문제 (Locking state files)
- 상태 파일을 공유해서 사용할 경우 잠금 기능 없이 두 팀원이 동시에 테라폼 수행 시
여러 테라폼 프로세스가 상태 파일을 동시에 업데이트하면서 충돌 가능성이 발생한다. (경쟁 상태 race condition)
- 상태 파일을 공유해서 사용할 경우 잠금 기능 없이 두 팀원이 동시에 테라폼 수행 시
- 상태 파일 격리의 문제 (Isolating state files)
- 예를 들면 테스트 dev와 검증 stage, 그리고 상용 prodction 같은 별도로 분리된 환경일 경우
각 환경에 대한 상태파일 격리가 필요하다.
- 예를 들면 테스트 dev와 검증 stage, 그리고 상용 prodction 같은 별도로 분리된 환경일 경우
따라서 위와 같은 팀 단위의 Terraform 사용 문제를 해결하기 위해서는 아래의 조건이 필요하다.
- 상태관리 파일을 자동으로 반영
- 상태관리 파일을 수동으로 관리할 경우 잘못된 버전으로 롤백하면서 Resource가 삭제되는 등의 Human Error가 발생하기 쉽다.
- 상태관리 파일 잠금 기능
- 상태관리 파일을 사용하고 있을 때는 apply를 하지 못하도록 상태관리 파일 Locking이 필요하다.
(이런 조건으로 인해 대부분의 버전관리 시스템은 상태관리 파일에 적용하는 것은 추천하지 않는다.)
- 상태관리 파일을 사용하고 있을 때는 apply를 하지 못하도록 상태관리 파일 Locking이 필요하다.
- 상태관리 파일의 암호화
- 상태관리 파일은 맨 첫 문단에서 확인한 것처럼, 평문으로 저장되므로 Resource 정보를 암호화해서 보관해야 한다.
이런 조건을 만족시키는 위해서 Terraform에 내장된 원격 Backend를 사용하는 것을 추천한다.
(Backend 외에 더 좋은 방안이 있는지는 아직 확인하지 못함, Terraform Cloud를 추천받았으나 아직 사용해보진 못함)
Terraform 원격 Backend
Terraform 원격 Backend는 상태파일을 지정한 원격 공유 저장소에 저장해서 관리하는 방법이다.
지원하는 원격 Backend는 AWS S3, Azure Blob Storage, Google Cloud Storage, Consul, Postgres database 등이 존재하며, 원격 Backend 지정 시 위의 언급한 3가지 문제점이 해소된다.
- 상태파일 관리 자동화
- plan/apply 실행 시 마다 해당 백엔드에서 파일을 자동을 로드, apply 후 상태 파일을 백엔드에 자동 저장 - 상태파일 Locking
- apply 실행 시 테라폼은 자동으로 잠금을 활성화, -lock-timout=<TIME> 로 대기 시간 설정 지정 가능 - 상태파일 암호화
- 대부분 원격 Backend는 기본적으로 데이터를 보내거나 상태 파일을 저장할 때 암호화하는 기능을 지원
참고자료
- 테라폼 공식 홈페이지 : https://developer.hashicorp.com/terraform/intro
- 테라폼 상태관리 개념 : https://velog.io/@miewone/Terraform-테라폼-상태-관리하기
- 테라폼 Backend 참고 : https://developer.hashicorp.com/terraform/language/settings/backends/configuration
