Terraform 작업 권장사항

이 문서에서는 Terraform 작업에 대한 가이드라인과 권장사항을 제공합니다.

이 가이드는 Terraform 소개 내용이 아닙니다. Google Cloud에서 Terraform 사용에 대한 소개는 정보는 Terraform 시작하기를 참조하세요.

항상 먼저 계획

Terraform 실행을 위해 항상 먼저 계획을 생성합니다. 출력 파일에 계획을 저장합니다. 인프라 소유자가 승인한 다음 계획을 실행합니다. 개발자가 변경사항에 대해 로컬 프로토타입을 만들 때도 계획을 생성하고 계획을 적용하기 전 추가, 수정, 삭제할 리소스를 검토해야 합니다.

자동화된 파이프라인 구현

일관적인 실행 컨텍스트를 보장하기 위해 자동화된 도구 사용을 통해 Terraform을 실행합니다. Jenkins와 같은 빌드 시스템을 이미 사용 중이고 넓게 채택된 경우에는 이를 사용해서 terraform plan 및 terraform apply 명령어를 자동으로 실행합니다. 기존 시스템을 사용할 수 없으면 Cloud Build 또는 Terraform Cloud를 채택합니다.

지속적 통합을 위한 서비스 계정 사용자 인증 정보 사용

CI/CD 파이프라인의 한 머신에서 Terraform을 실행할 때는 파이프라인을 실행하는 서비스로부터 서비스 계정 사용자 인증 정보가 상속됩니다. 가능한 모든 경우에 Google Cloud에서 CI 파이프라인을 실행합니다. Cloud Build, Google Kubernetes Engine, Compute Engine이 서비스 계정 키를 다운로드하지 않아도 사용자 인증 정보를 삽입하기 때문입니다.

Google Cloud 외부에서 실행되는 파이프라인의 경우 서비스 계정 키를 다운로드하지 않고 워크로드 아이덴티티 제휴를 사용하여 사용자 인증 정보를 가져오는 것이 좋습니다.

기존 리소스 가져오기 방지

가능한 경우 기존 리소스 가져오기를 방지합니다(terraform import 사용). 이렇게 하면 수동으로 생성된 리소스의 출처 및 구성을 완전히 이해하는 것이 어려울 수 있습니다. 대신 Terraform을 통해 새 리소스를 만들고 이전 리소스를 삭제하는 것이 좋습니다.

이전 리소스 삭제로 인해 반복 업무가 크게 증가할 경우에는 명시적 승인과 함께 terraform import 명령어를 사용합니다. 리소스를 Terraform으로 가져온 후에는 Terraform을 사용해서 명시적으로 관리합니다.

Google은 Google Cloud 리소스를 Terraform 상태로 가져오기 위해 사용할 수 있는 도구를 제공합니다. 자세한 내용은 Terraform 상태로 Google Cloud 리소스 가져오기를 참조하세요.

Terraform 상태를 수동으로 수정 안 함

Terraform 상태 파일은 Terraform 구성과 Google Cloud 리소스 사이의 매핑을 유지관리하는 데 중요합니다. 파일이 손상되면 중요한 인프라 문제로 이어질 수 있습니다. Terraform 상태 수정이 필요할 때는 terraform state 명령어를 사용합니다.

정기적으로 버전 고정 검토

버전 고정은 안정성을 보장하지만 버그 수정 및 기타 향상 기능을 구성에 도입하는 데 방해가 됩니다. 따라서 Terraform, Terraform 제공업체, 모듈에 대해 버전 고정을 정기적으로 검토합니다.

이 프로세스를 자동화하려면 Dependabot과 같은 도구를 사용합니다.

로컬 실행 시 애플리케이션 기본 사용자 인증 정보 사용

개발자는 Terraform 구성에 따라 로컬 반복을 수행할 때 애플리케이션 기본 사용자 인증 정보 생성을 위해 gcloud auth application-default login을 실행하여 인증해야 합니다. 다운로드한 키는 관리 및 보안이 더 어려우므로, 서비스 계정 키를 다운로드하지 마세요.

Terraform에 별칭 설정

로컬 개발을 쉽게 할 수 있도록 명령어 셸 프로필에 별칭을 추가할 수 있습니다.

  • alias tf="terraform"
  • alias terrafrom="terraform"

다음 단계