테라폼 상태란?

테라폼을 실행할 때마다 테라폼은 생성한 인프라에대한 정보를 테라폼 상태파일에 기록합니다.
기본적으로 /foo/bar 폴더에서 테라폼을 실행하면 테라폼은 /foo/bar/terraform.tfstate 파일을 생성합니다.
이 파일에는 구성 파일의 테라폼 리소스가 실제 리소스의 표현으로 매핑되는 내용을 기록하는 사용자 정의 JSON 형식이 포함되어있습니다.

resource "aws_instance" "wgpark_ec2" {
	ami		= "SOMETING-AMI"
  	instance_type	= "t2.micro"
}

$ terraform apply # 명령어를 실행하면 나타나는 terraform.tfstate 파일

{
  "version": 4,
  "terraform_version": "1.0.8",
  "serial": 5,
  "lineage": "75ce598d-b6fd-feb4-3846-12e156b90023",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "aws_instance",
      "name": "ubuntu",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "schema_version": 1,
          "attributes": {
            "ami": "ami-04876f29fd3a5e8ba",
            "arn": "arn:aws:ec2:ap-northeast-2:701558900840:instance/i-0af95c7cbf7f7be0d",
            "associate_public_ip_address": true,
            "availability_zone": "ap-northeast-2a",
            .
            .
            .
        }
      ]
    }
  ]
}

테라폼은 이 JSON 형식을 통해 AWS 계저의 EC2 인스턴스와 일치하는것을 알고 있습니다.
테라폼을 실행할 대마다 AWS 에서 이 EC2 인스턴스의 최신 상태를 가져와서 테라폼의 구성과 비교하여 어느 변경 사항을 적용해야 하는지 결정 할 수 있습니다.
즉, plan 명령의 출력은 상태 파일의 ID를 통해 발견된 컴퓨터의 코드와 실제 세계에 배포된 인프라 간의 차이입니다.

참고

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

상태파일을 조작해야 하는ㄱ ㅕㅇ우 terraform import 또는 terraform state 명령을 사용해야합니다.

테라폼을 팀 단위로의 문제

1. 상태파일을 저장하는 공유 스토리지
   테라폼을 사용하여 인프라르 업데이트하려면 각 팀원이 동일한 테라폼 상태 파일에 액세스 해야합니다. 상태 파일을 공유 위치에 저장해야합니다.

2. 상태 파일 잠금
   상태 데이터가 공유되자마자 '잠금'이라는 새로운 문제가 발생합니다. 잠금 기능 없이 두 팀원이 동시에 테라폼을 실행하는 경우 테라폼 프로세스가 상태 파일을 동시에 업데이트하여 충돌을 일으킬 수 있습니다. 이러한 경쟁 상태에 처하면 데이터가 손실되거나 상태 파일이 손상될 수 있습니다.

3. 상태 파일 격기
   인프라를 변경할 때는 다른 환경을 격리하는 것이 가장 좋습니다.

상태파일 공유하기

깃이나 섭버전등 버전 관리시스템이 테라폼 상태 파일을 저장하는 것은 부적절합니다.

• 수동 오류
  테라폼을 실행하기 전에 최신 변경 사항을 가져오거나 실행하고 나서 푸쉬하는 것을 잊기 쉽습니다. 팀의 누군가가 이전 버전의 상태 파일로 테라폼을 실행하고, 그 결과 실수로 이전 버전으로 롤백하거나 이전에 배포된 인프라를 복제하는 문제가 발행할 수 있습니다.
• 잠금
  대부분의 버전 관리 시스템은 여러 명의 팀 구성원이 동시에 하나의 상태 파일에 terraform apply 명령을 실행하지 못하게 하는 잠금 기능을 제고하지 않습니다.
• 시크릿
  테라폼 상태 파일의 모든 데이터는 평문으로 저장되는데 특정 테라폼 리소스에 중요한 데이터를 저장해야 할 때 문제가 발생합니다.
  

해결책 ?

버전 관리 시스템을 사용하는 대신 테라폼에 내장된 원격 백엔드 기능을 사용하는것이 좋은 방법입니다.

테라폼 백엔드는 테라폼이 상태를 로드하고 저장하는 방법을 결정합니다. 기본 백엔드는 로컬 백엔드로써 로컬 디스크에 상태 파일을 저장합니다. 원격 백엔드를 사용하면 상태 파일을 원격 공유 저장소에 저장할 수 있습니다.

아마존 S3,애저 스토리지, 구글 클라우드 스토리지,해시코르의 테라폼 클라우드,테라폼 프로,테라폼 엔터프라이즈 등 다양한 원격 백엔드가 지원됩니다.

백엔드를 쓰면서 해결되는 것

• 수동 오류
  원격 백엔드를 구성하면 테파롬은 plan이나 apply 명령을 실행할 때마다 해당 백엔드에서 상태파일을 자동으로 로드합니다. 또한 appluy 명령을 실행한 후에는 상태 파일을 백엔드에 자동 저장하므로 수동 오류가 발생하지 않습니다.
• 잠금
  대부분의 원격 백엔드는 기본적으로 잠금기능을 지원합니다. terraform apply 명령을 실행하면 테라폼은 자동으로 잠금을 활성화합니다. 다른 사람이 apply 명령을 실행 중인 경우 이미 잠금이 활성화되어 있어 잠금이 해제될 때 까지 기다려야합니다.
• 시크릿
  대부분의 원격 백엔드는 기본적으로 데이터를 보내거나 상태 파일을 저장할 때 암호화하는 기능을 지우너합니다. 또한 이러한 백엔드는 아마존 S3버킷과 IAM 정책을 사용하는 것 같이 일반적으로 액세스 제한을 구성하는 방법을 노출하므로 상태 파일에 액세스할 수 있는 사용자와 파일에 포함될 수 있는 시크릿을 제어할 수 있습니다. 테라폼이 상태 파일 내에서 시크릿 암호화를 기본적으로 지원하면 더 좋겠지만 최소한 상태 파일이 디스크 어디에도평문으로 저장되지는 않으므로 이러한 백엔드로 대부분의 보안 문제를 해결할 수 있습니다.

테라폼 백엔드의 단점

1. 테라폼 상태를 관리할 백엔드를 만드는게 우선인지 상태를 먼저 만든것이 우선인지를 정해야합니다.
2. 테파롬의 백엔드 블록에서는 변수나 참조를 사용 할 수 없다는 점

출처

Terraform Up & Running 테라폼 Writing Infrastructure as code 업앤 러닝 - 예브게닝 브릭만