이 가이드는 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을 사용해서 명시적으로 관리합니다.
Terraform 상태 파일은 Terraform 구성과 Google Cloud 리소스 사이의 매핑을 유지관리하는 데 중요합니다. 파일이 손상되면 중요한 인프라 문제로 이어질 수 있습니다. Terraform 상태 수정이 필요할 때는 terraform state 명령어를 사용합니다.
정기적으로 버전 고정 검토
버전 고정은 안정성을 보장하지만 버그 수정 및 기타 향상 기능을 구성에 도입하는 데 방해가 됩니다. 따라서 Terraform, Terraform 제공업체, 모듈에 대해 버전 고정을 정기적으로 검토합니다.
개발자는 Terraform 구성에 따라 로컬 반복을 수행할 때 애플리케이션 기본 사용자 인증 정보 생성을 위해 gcloud auth application-default login을 실행하여 인증해야 합니다. 다운로드한 키는 관리 및 보안이 더 어려우므로, 서비스 계정 키를 다운로드하지 마세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eAlways generate and review a Terraform plan before applying it, even during local development, and automate the execution of plans through a CI/CD pipeline.\u003c/p\u003e\n"],["\u003cp\u003eUtilize service account credentials through workload identity federation for CI/CD pipelines running outside of Google Cloud, and avoid downloading service account keys.\u003c/p\u003e\n"],["\u003cp\u003eAvoid importing existing resources whenever possible; instead, create new resources through Terraform to maintain clear resource management, and use the \u003ccode\u003eterraform import\u003c/code\u003e command with explicit approval if deletion of resources is not feasible.\u003c/p\u003e\n"],["\u003cp\u003eRefrain from manually modifying the Terraform state file, instead using the \u003ccode\u003eterraform state\u003c/code\u003e command for any necessary state adjustments.\u003c/p\u003e\n"],["\u003cp\u003eRegularly review version pins for Terraform, its providers, and modules, and consider automating this with a tool such as Dependabot.\u003c/p\u003e\n"]]],[],null,["# Best practices for Terraform operations\n\nThis document provides guidelines and recommendations for Terraform operations.\n\nThis guide is not an introduction to Terraform. For an introduction to using\nTerraform with Google Cloud, see\n[Get started with Terraform](/docs/terraform/get-started-with-terraform).\n\nAlways plan first\n-----------------\n\nAlways generate a plan first for Terraform executions.\n[Save the plan to an output file](https://learn.hashicorp.com/tutorials/terraform/automate-terraform).\nAfter an infrastructure owner approves it, execute the plan. Even when\ndevelopers are locally prototyping changes, they should generate a plan and\nreview the resources to be added, modified, and destroyed before applying the\nplan.\n\nImplement an automated pipeline\n-------------------------------\n\nTo ensure consistent execution context, execute Terraform through automated\ntooling. If a build system (like Jenkins) is already in use and widely adopted,\nuse it to run the `terraform plan` and `terraform apply` commands automatically.\nIf no existing system is available, adopt either\n[Cloud Build](/docs/terraform/resource-management/managing-infrastructure-as-code)\nor\n[Terraform Cloud](https://cloud.hashicorp.com/products/terraform).\n\nUse service account credentials for continuous integration\n----------------------------------------------------------\n\nWhen Terraform is executed from a machine in a CI/CD pipeline, it should\ninherit the service account credentials from the service executing the pipeline.\nWherever possible, run CI pipelines on Google Cloud because\nCloud Build, Google Kubernetes Engine, or Compute Engine inject credentials\nwithout downloading service account keys.\n\nFor pipelines that run outside of Google Cloud, prefer\n[workload identity federation](/iam/docs/using-workload-identity-federation)\nto obtain credentials without downloading service account keys.\n| **Note:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](/docs/authentication#auth-decision-tree) whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by [Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys). If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see [Managing secure-by-default organization resources](/resource-manager/docs/secure-by-default-organizations).\n|\n|\n| If you acquired the service account key from an external source, you must validate it before use.\n| For more information, see [Security requirements for externally sourced credentials](/docs/authentication/external/externally-sourced-credentials).\n\nAvoid importing existing resources\n----------------------------------\n\nWhere possible, avoid importing existing resources\n(using [`terraform import`](https://www.terraform.io/cli/import)), because doing\nso can make it challenging to fully understand the provenance and configuration\nof manually created resources. Instead, create new resources through Terraform\nand delete the old resources.\n\nIn cases where deleting old resources would create significant toil,\nuse the `terraform import` command with explicit approval. After a resource is\nimported into Terraform, manage it exclusively with Terraform.\n\nGoogle provides a tool that you can use to import your\nGoogle Cloud resources into Terraform state. For more information,\nsee [Import your Google Cloud resources into Terraform\nstate](/docs/terraform/resource-management/import).\n\nDon't modify Terraform state manually\n-------------------------------------\n\nThe Terraform state file is critical for maintaining the mapping between\nTerraform configuration and Google Cloud resources. Corruption can lead\nto major infrastructure problems. When modifications to the Terraform state are\nnecessary, use the [`terraform state`](https://www.terraform.io/cli/state)\ncommand.\n\nRegularly review version pins\n-----------------------------\n\nPinning versions ensures stability but prevents bug fixes and other\nimprovements from being incorporated into your configuration. Therefore,\nregularly review version pins for Terraform, Terraform providers, and modules.\n\nTo automate this process, use a tool such as\n[Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates#supported-repositories-and-ecosystems).\n\nUse application default credentials when running locally\n--------------------------------------------------------\n\nWhen developers are locally iterating on Terraform configuration, they should\nauthenticate by running\n[`gcloud auth application-default login`](https://cloud.google.com/sdk/gcloud/reference/auth/application-default/login)\nto generate application default credentials. Don't download service account\nkeys, because downloaded keys are harder to manage and secure.\n\nSet aliases to Terraform\n------------------------\n\nTo make local development easier, you can add aliases to your command shell\nprofile:\n\n- `alias tf=\"terraform\"`\n- `alias terrafrom=\"terraform\"`\n\nWhat's next\n-----------\n\n- Learn about [best practices to securely use Terraform](/docs/terraform/best-practices/security).\n- Learn about [best practices for testing Terraform modules and configurations](/docs/terraform/best-practices/testing)."]]
