使用Terraform的五年让我学到了一些重要的经验教训。无论团队规模或项目性质如何，五点对于配置逻辑可用的Terraform平台至关重要。1.了解你的目标受众这似乎是显而易见的，但我见过一些人弄错的案例。在组织和规划Terraform相关代码时，无论是标准化目录结构还是确定命名约定，重要的是要考虑目标受众。例如：您的团队会使用这些Terraform脚本和模块吗？你会把工作交给其他团队吗？有新成员加入你们的团队吗？你是一个人做项目开发吗？从现在起六个月或一年后，您是否仍会使用该配置，还是将其分配给其他人？这些问题会影响某些决定。理想情况下，无论如何都应该有远程状态和状态锁定。命名约定应该对项目的最终所有者有意义，而不仅仅是对开发团队有意义。如果项目将移交给其他团队，请确保他们在命名约定中有发言权。如果代码由非技术利益相关者或内部安全/GCR团队审查，请确保他们检查命名约定。另外，对于资源名称，为了让代码审查者更仔细地审查它们，您应该使用资源标签来指示相关的数据分类/隐私要求（高、中、低）。2.重用、重用、重用TerraformRegistry为最常见的用例提供了一个现成的模块库。我在VPC模块和安全模块中使用了很多功能，这些功能只需要提供相关参数即可使用。对于大多数用例，只需使用不同的参数调用这些模块就足够了。尽可能重用这些公共模块可以避免大量和重复的编码、测试、检查、修复、重构等。我还发现根据使用或更改的频率划分模块和资源是有益的。例如，只用一次的基础设施脚手架，如VPC相关设置、安全模块、路由表、VPC端点等，可以放在一起。但是私有托管域条目、自动缩放模块、目标模块、负载平衡器等东西会改变每个部署，因此将这些与一次性基础设施脚手架分开可以使代码检查更容易，调试也更容易。快速地。3.明确而非隐含Terraform代码中有一些常见的模式会导致设计中出现错误的假设。团队可以假设用于编写代码的Terraform版本将永远保持不变，外部模块不会改变，或者他们使用的提供者不会改变。当这些外部依赖不可避免地发生变化时，就会导致一些难以发现的问题。确保定义在任何地方都清晰（包括主要的Terraform组、提供者组、功能模块组）。提前定义好版本，保证依赖库是固定的，经过讨论、审查、测试后，可以清楚地更新依赖。4.自动化一切，包括笔记本电脑、共享虚拟机、CI/CD。通过在部署的所有阶段使用自动化方法，您可以避免潜在的问题。在提交代码之前，使用Git预提交挂钩运行terraformfmt和terraformvalidate。预提交挂钩的作用是确保您的代码满足格式良好和语法正确的最低级别。将此预提交检查到存储库中将使您的团队成员受益。该项目的第一步是进行质量控制相关操作。虽然表面上是一件小事，但也很重要，可以为项目节省很多时间。所有现代部署工具都有一个CI过程。当您将代码推送到原始存储库时，您可以使用它来运行SAST和单元测试工具。我在博客中介绍了使用Checkov测试Terraform代码的安全性和合规性，并为特定于组织的约定创建自定义检查。将这些单元测试工具添加到您的CI管道可以提高代码质量和健壮性。5.写一个好的README.md文件我们都认为Terraform代码是自文档化的。是的，但前提是未来的团队已经知道贵公司的命名约定、开发指南、机密通信、内部笑话，以及除有效的Terraform代码之外的所有其他内容。维护一个README.md文件是一个好习惯，它可以节省很多时间，并且团队成员对他们提交到README文件的任何内容负责，这确保了团队成员的忠诚度。您的README文件至少应包含在您的工作环境（Linux、Windows、Mac等）中初始化Terraform环境的步骤，包括Terraform版本信息。它应该确定所需的依赖库（Checkov、TerraGrunt等）及其版本，以及团队使用的方便的Linux别名（例如，有些人喜欢将terraformfmt缩写为tff）。最重要的是，需要确定分支和PR审查政策和流程、命名约定和资源标签的标准。README文件需要通过这个测试：如果有新的团队成员加入，你能告诉他们该做什么以及如何正确地做吗？如果做不到，您将在接下来的几个月中面临无休止的标准和流程讨论会议。结论这是使用Terraform多年后我认为需要传递给您的五条有用的建议。
