테라폼 상태 및 백엔드 이해

코드형 인프라 (IaC) 의 가장 중요한 개념 중 하나는 상태 개념입니다. IaC 서비스는 상태를 유지하므로 배포할 때마다 리소스를 다시 만들지 않고도 IaC 파일에서 리소스를 선언할 수 있습니다. IAC 파일은 배포 종료 시점의 모든 리소스 상태를 문서화하므로 다음 배포에서 선언되는 대상 상태와 해당 상태를 비교할 수 있습니다. 따라서 현재 상태에 my-s3-bucket 이름이 지정된 Amazon Simple Storage Service (Amazon S3) 버킷이 있고 들어오는 변경 내용에도 동일한 버킷이 포함되어 있는 경우, 새 프로세스는 완전히 새 버킷을 만들려고 하지 않고 기존 버킷에 발견된 모든 변경 사항을 적용합니다.

다음 표에는 일반적인 IaC 상태 프로세스의 예가 나와 있습니다.

현재 상태	대상 상태	작업
이름이 지정된 S3 버킷 없음 my-s3-bucket	S3 버킷 이름이 지정되었습니다 my-s3-bucket	라는 S3 버킷을 생성합니다. my-s3-bucket
my-s3-bucket버킷 버전 관리가 구성되지 않은 상태	my-s3-bucket버킷 버전 관리가 구성되지 않은 상태	조치 없음
my-s3-bucket버킷 버전 관리가 구성되어 있지 않은 경우	my-s3-bucket버킷 버전 관리가 구성된 상태	버킷 my-s3-bucket 버전 관리를 포함하도록 구성
my-s3-bucket버킷 버전 관리가 구성된 상태	이름이 지정된 S3 버킷 없음 my-s3-bucket	삭제 시도 my-s3-bucket

Terraform이 상태를 추적하는 AWS CloudFormation 다양한 방식을 이해하려면 두 도구의 첫 번째 기본 차이점을 기억하는 것이 중요합니다. CloudFormation Terraform은 내부에서 호스팅되고 Terraform은 기본적으로 원격이라는 것입니다. AWS 클라우드이 사실을 통해 CloudFormation 내부적으로 상태를 유지할 수 있습니다. CloudFormation 콘솔에서 특정 스택의 이벤트 기록을 볼 수 있지만 CloudFormation 서비스 자체에서 상태 규칙을 적용합니다.

특정 리소스에 대해 CloudFormation 작동하는 세 가지 모드는Create,Update, Delete 입니다. 현재 모드는 마지막 배포에서 발생한 상황을 기반으로 결정되며, 다른 방식으로는 영향을 받을 수 없습니다. 결정되는 모드에 영향을 주기 위해 CloudFormation 리소스를 수동으로 업데이트할 수도 있지만 “이 리소스의 경우 Create 모드에서 작업하십시오”라는 명령을 전달할 수는 없습니다. CloudFormation

Terraform은 에서 호스팅되지 않으므로 상태 유지 프로세스를 더 쉽게 구성할 수 있어야 합니다. AWS 클라우드이러한 이유로 Terraform 상태는 자동으로 생성된 상태 파일 내에서 유지됩니다. Terraform 개발자는 상태를 다루는 것보다 훨씬 더 직접적으로 상태를 다루어야 합니다. CloudFormation 기억해야 할 중요한 점은 두 도구 모두에서 상태 추적이 똑같이 중요하다는 것입니다.

기본적으로 Terraform 상태 파일은 Terraform 스택을 실행하는 기본 디렉토리의 최상위 수준에 로컬로 저장됩니다. 로컬 개발 환경에서 terraform apply 명령을 실행하면 Terraform이 실시간으로 상태를 유지하는 데 사용하는 terraform.tfstate 파일을 생성하는 것을 볼 수 있습니다. 좋든 나쁘든 이렇게 하면 Terraform에서 이전보다 훨씬 더 많은 상태를 제어할 수 있습니다. CloudFormation 상태 파일을 직접 업데이트해서는 안 되지만 배포 간에 상태를 업데이트하는 몇 가지 Terraform CLI 명령을 실행할 수 있습니다. 예를 들어 terraform 가져오기를 사용하면 Terraform 외부에서 생성된 리소스를 배포 스택에 추가할 수 있습니다. 반대로 terraform state rm을 실행하여 상태에서 리소스를 제거할 수 있습니다.

Terraform이 상태를 어딘가에 저장해야 한다는 사실은 적용되지 않는 또 다른 개념인 백엔드로 이어집니다. CloudFormation Terraform 백엔드는 Terraform 스택이 배포 후 상태 파일을 저장하는 장소입니다. 또한 새 배포가 시작될 때 상태 파일을 찾을 것으로 예상되는 위치이기도 합니다. 위에서 설명한 것처럼 스택을 로컬에서 실행하면 Terraform 상태의 사본을 최상위 로컬 디렉토리에 보관할 수 있습니다. 이를 로컬 백엔드라고 합니다.

지속적 통합 및 지속적 배포 (CI/CD) 환경을 위해 개발하는 경우 일반적으로 로컬 상태 파일은.gitignore 파일에 포함되어 버전 제어에서 제외됩니다. 그러면 파이프라인 내에 로컬 상태 파일이 없습니다. 제대로 작동하려면 해당 파이프라인 스테이지가 어딘가에서 올바른 상태 파일을 찾아야 합니다. 이것이 Terraform 구성 파일에 종종 백엔드 블록이 포함되는 이유입니다. 백엔드 블록은 Terraform 스택에 상태 파일을 찾으려면 최상위 디렉토리가 아닌 다른 곳을 찾아야 한다는 것을 알려줍니다.

Terraform 백엔드는 Amazon S3 버킷, API 엔드포인트 또는 원격 Terraform 작업 공간 등 거의 모든 곳에 위치할 수 있습니다. 다음은 Amazon S3 버킷에 저장된 Terraform 백엔드의 예입니다.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

민감한 정보가 Terraform 구성 파일 내에 저장되지 않도록 백엔드는 부분 구성도 지원합니다. 이전 예에서는 버킷에 액세스하는 데 필요한 자격 증명이 구성에 없습니다. 자격 증명은 환경 변수에서 또는 다른 방법 (예:) 을 사용하여 얻을 수 AWS Secrets Manager있습니다. 자세한 내용은 AWS Secrets Manager HashiCorp Terraform을 사용하여 민감한 데이터 보안을 참조하십시오.

일반적인 백엔드 시나리오는 로컬 환경에서 테스트 목적으로 사용되는 로컬 백엔드입니다. terraform.tfstate 파일은 원격 리포지토리로 푸시되지 않도록 .gitignore 파일에 포함되어 있습니다. 그러면 CI/CD 파이프라인 내의 각 환경이 자체 백엔드를 유지하게 됩니다. 이 시나리오에서는 여러 개발자가 이 원격 상태에 액세스할 수 있으므로 상태 파일의 무결성을 보호하는 것이 좋습니다. 여러 배포가 실행 중이고 동시에 상태를 업데이트하는 경우 상태 파일이 손상될 수 있습니다. 이러한 이유로 로컬이 아닌 백엔드가 있는 상황에서는 일반적으로 배포 중에 상태 파일이 잠깁니다.