本文档提供了有关 Terraform 操作的准则和建议。
本指南未介绍 Terraform。如需了解如何将 Terraform 与 Google Cloud 搭配使用，请参阅 Terraform 使用入门。
始终先规划
始终先为 Terraform 执行生成计划。将计划保存到输出文件中。获得基础架构所有者的批准后，执行计划。即使开发者在本地对更改进行原型设计，也应该生成计划并查看应用添加、修改和销毁的资源。
实现自动化流水线
为了确保一致的执行上下文，通过自动化工具执行 Terraform。如果构建系统（如 Jenkins）已被使用并广泛采用，请使用它自动运行 terraform plan 和 terraform apply 命令。如果没有现有系统，请采用 Cloud Build 或 Terraform Cloud。
使用服务账号凭据实现持续集成
从 CI/CD 流水线中的机器执行 Terraform 时，Terraform 应从执行该流水线的服务沿用服务账号凭据。请尽可能在 Google Cloud 上运行 CI 流水线，因为 Cloud Build、Google Kubernetes Engine 或 Compute Engine 可注入凭据，而无需下载服务账号密钥。
对于在 Google Cloud 外部运行的流水线，首选工作负载身份联合来获取凭据，而无需下载服务账号密钥。
避免导入现有资源
请尽可能避免导入现有资源（使用 terraform import），因为这样做可能会很难完全了解手动创建的资源的来源和配置。应通过 Terraform 创建新资源并删除旧资源。
如果删除旧资源会带来大量重复劳动，请使用 terraform import 命令并明确批准。将资源导入 Terraform 后，只能使用 Terraform 对其进行管理。
Google 提供了一条工具，可用于将 Google Cloud 资源导入 Terraform 状态。如需了解详情，请参阅将 Google Cloud 资源导入 Terraform 状态。
不要手动修改 Terraform 状态
Terraform 状态文件对于维护 Terraform 配置与 Google Cloud 资源之间的映射至关重要。中断可能会导致严重的基础架构问题。如果需要修改 Terraform 状态，请使用 terraform state 命令。
定期审核版本固定
固定版本可确保稳定性，但会阻止问题修复和其他改进整合到您的配置中。因此，请定期审核 Terraform、Terraform 提供商和模块的版本固定。
如需自动执行此过程，请使用 Dependabot 等工具。
在本地运行时使用应用默认凭据
当开发者在本地迭代 Terraform 配置时，他们应通过运行 gcloud auth application-default login 生成应用默认凭据来进行身份验证。请勿下载服务账号密钥，因为下载的密钥更难管理和确保安全。
将别名设置为 Terraform
为了简化本地开发，您可以在命令 shell 配置文件中添加别名：
alias tf="terraform"alias terrafrom="terraform"