.tfstate 파일을 Git에 커밋해야합니까?
.tfstateGit에 파일을 커밋할지 여부에 대한 질문에 약간 의아해합니다 . Terraform 문서 상태 :
Terraform은 또한
terraform.tfstate기본적 으로 일부 상태를 파일에 넣습니다 . 이 상태 파일은 매우 중요합니다. 다양한 리소스 메타 데이터를 실제 리소스 ID에 매핑하여 Terraform이 관리하는 내용을 알 수 있도록합니다. 이 파일은 Terraform을 실행할 수있는 모든 사람에게 저장 및 배포되어야합니다. 일반적으로 너무 크지 않으므로 단순히 버전 관리에 넣는 것이 좋습니다.
반면에 Terraform 상태를 사용할 때 모범 사례 에 대한 수락 및 찬성 답변은 다음과 같습니다.
Terraform 구성은 각기 다른 상태를 가질 수있는 서로 다른 인프라에 많은 상자를 프로비저닝하는 데 사용할 수 있습니다. 여러 사람이 실행할 수도 있으므로이 상태는 중앙 위치 (예 : S3)에 있어야하지만 git이 아니 어야합니다 .
(내가 아닌 원저자에 의한 강조)
누가 옳고, 그렇다면 그 이유는 무엇입니까?
TL; DR :
중대한! 소스 제어에 저장하면 잠재적으로 민감한 데이터 가 노출 되고 이전 버전의 상태에 대해 Terraform을 실행할 위험이 있습니다. 하지마.
Terraform은 더 이상 소스 제어에 상태를 저장하는 것을 권장하지 않습니다. '좋은'옵션은 원격 또는 로컬입니다.
원격 상태는 로컬 및 소스 제어 저장에 비해 상당한 이점을 제공합니다. 자세한 내용은 다음과 같습니다.
원래 답변 :
Yevgeniy의 대답은 좋은 것입니다. Terraform이 문서를 다음과 같이 업데이트했기 때문에이 문제는 이제 다소 덜 논쟁의 여지가 있습니다.
Terraform은 기본적으로 일부 상태를 terraform.tfstate 파일에 넣습니다. 이 상태 파일은 매우 중요합니다. 다양한 리소스 메타 데이터를 실제 리소스 ID에 매핑하여 Terraform이 관리하는 내용을 알 수 있도록합니다. 이 파일은 Terraform을 실행할 수있는 모든 사람에게 저장 및 배포되어야합니다. 일반적으로 Terraform으로 작업 할 때 원격 상태를 설정하는 것이 좋습니다. 이는 상태 파일에 저장된 잠재적 인 비밀이 버전 제어에 체크인되지 않음을 의미합니다.
따라서 더 이상 확립 된 모범 사례와 공식 권장 사항간에 불일치가 없습니다.
업데이트 2019-05-17
...이 상태는 기본적으로 "terraform.tfstate"라는 로컬 파일에 저장되지만 원격으로 저장할 수도 있으므로 팀 환경에서 더 잘 작동합니다. ...
나는 조언이 상태를 저장하는 선호되는 방법 인 소스 제어로 되돌아 갈 것이라고 기대하지 않는다.
위의 문서 인용에도 불구하고 원격 상태는 솔로 개발자로서 여전히 유익합니다.
원격 상태를 통해 단독 개발자는 다음을 수행 할 수 있습니다.
- 여러 장치에서 Terraform 코드 작업 / 실행
- 선택한 백엔드에 따라 쉽게 백업하고 상태 파일 손실 방지
- 출력을 통해 아키텍처 섹션 분리
- 선택한 백엔드에 따라 미사용 상태 파일 자동 암호화
.tfstateGit에 파일 을 저장하지 않는 데에는 몇 가지 이유가 있습니다 .
- 를 실행 한 후 변경 사항을 커밋하고 푸시하는 것을 잊을 수
terraform apply있으므로 팀원은 오래된.tfstate파일을 갖게됩니다 . 또한 이러한 상태 파일을 잠그지 않고 두 팀 구성원이 같은.tfstate파일 에서 동시에 Terraform을 실행 하면 서로의 변경 사항을 덮어 쓸 수 있습니다. a) Terraform 원격 상태를.tfstate사용하여 S3 버킷에 파일을 저장 하면 실행될 때마다 파일을 자동으로 푸시 / 풀링 하고 b) terragrunt 와 같은 도구를 사용 하여 파일 잠금을 제공 하여 두 가지 문제를 모두 해결할 수 있습니다 ..tfstateterraform apply.tfstate .tfstate파일은 비밀을 포함 할 수있다. 예를 들어 aws_db_instance 리소스를 사용하는 경우 데이터베이스 암호를 지정해야하며 Terraform은 해당 암호를 일반 텍스트로.tfstate파일에 저장합니다. 이것은 Terraform을 대신하여 시작하는 나쁜 습관이며 버전 제어에 암호화되지 않은 비밀을 저장하면 상황이 악화됩니다. 최소한.tfstateS3에 파일 을 저장하는 경우 유휴 암호화를 활성화하고 (SSL은 이동 중에 암호화 제공) IAM 정책을 구성하여 액세스 권한을 제한 할 수 있습니다. 이상과는 거리가 멀고이 문제를 논의하는 공개 된 문제가 해결 되었는지 확인해야합니다 .
자세한 내용은 Terraform 상태 관리 방법 및 Terraform : Up & Running을 확인하십시오 .
이것은 아마도 선호에 따라 내려갈 것이지만 git (또는 다른 소스 컨트롤)은 컴파일 된 바이너리 또는 심지어는 컴파일 된 바이너리와 매우 유사한 코드의 출력이기 때문에 상태 파일을 저장하는 데 특히 좋은 옵션이 아니라고 말합니다. CSS로 컴파일 된 최소화 된 JS 또는 LESS.
무엇보다 상태 파일에서 모든 것을 다소 어색하게 만드는 코드에서 실제로 변경되는 것보다 실행중인 것에 대한 출력으로 매우 빠르게 변경 될 수 있습니다.
그러나 다른 랩톱 / 컴퓨터에서 개발하는 경우 원격 팀 구성원 또는 다른 장치와 이러한 상태 파일을 공유 할 수있는 방법이 필요합니다. 또한 Terraform이 상태 파일을 사용하여 관리하고있는 작업을 파악하여 발을 밟지 않도록 상태 파일을 잃어 버리면 실제 고통을 겪게되므로 이러한 파일을 저장하고 백업하는 방법이 필요합니다. 다른 툴링.
S3는 아마도 지금 당장 배치 할 수있는 최고의 장소 일 것입니다. 거의 무료이고 내구성은 가용성이 뛰어나며 원격 상태 리소스를 사용하는 Terraform에 대한 기본 지원이 매우 우수 합니다. 그리고 아마도 가장 중요한 것은 시작하기 위해 S3 버킷을 생성하기 만하면된다는 것입니다. Terraform없이 먼저 Consul 또는 etcd 클러스터 를 구축 해야하는 경우 (그렇지 않으면이를 생성하기 위해 상태를 저장하는 닭고기와 계란 문제가 있습니까?) 이러한 제품 중 하나를 사용하려는 경우에도 약간의 고통이 있습니다.
분명히 OpenStack을 사용하고 있다면 Swift 는 좋은 대안이 될 것입니다 (사용하지는 않았지만). 나는 또한 Hashicorp의 Atlas를 사용하지 않았지만 그 서비스에 대해 기꺼이 지불한다면 똑같이 유용 할 것입니다.
Git이 아닌 다른 수단을 통해 terraform.tfstate 를 공유하는 이점이 있습니다 .
예 : S3, Dropbox 등 (버전 관리가 켜져 있음)
그런 다음 이전 인프라 상태로 롤백 할 수 있습니다.
예를 들어, 커밋 B에서 리포지토리를 롤백하고 커밋 A로 돌아갑니다. terraform.tfstate 가 변경되지 않은 경우 -terraform 은 커밋 B 중에 추가 한 모든 항목을 롤백하는 방법을 생각할 것입니다. 그리고 롤백은 쉽습니다.
In case terraform.tfstate was also rolled back to commit A - then terraform will think that terraform.tfstate is in sync with required configuration and will not apply the rollback to your infrastructure.
참고URL : https://stackoverflow.com/questions/38486335/should-i-commit-tfstate-files-to-git
'Nice programing' 카테고리의 다른 글
| Android Studio에서 기존 프로젝트를 라이브러리 프로젝트로 변환 (0) | 2020.12.01 |
|---|---|
| ffmpeg에서 특정 기간 동안 단일 이미지로 비디오 만들기 (0) | 2020.12.01 |
| 2 단계 커밋은 마지막 순간 실패를 어떻게 방지합니까? (0) | 2020.12.01 |
| 캐시 VS 세션 VS 쿠키? (0) | 2020.12.01 |
| boolean [] vs. BitSet : 어느 것이 더 효율적입니까? (0) | 2020.12.01 |