关于性能 的五条倡导 Terraform
经常使用 Terraform 五年的阅历让我吸取到一些关键阅历。无论团队大小、名目性质，有五条要点关于性能契合逻辑且可用的 Terraform 平台至关关键。
1、了解你的指标受众
这一点仿佛显而易见，但我也见过一些在这方面犯错的案例。当组织和布局 Terraform的相关代码时，无论是将目录结构规范化还是确定命名规范，思考指标受众是十分关键的。例如：你的团队能否会经常使用这些 Terraform脚本和模块？你能否会向其余团队交接上班？你的团队能否会有新成员添加？你能否正在独自启动名目开发？你能否会半年或一年后依然经常使用这些性能，还是会将它布置给他人？
这类疑问会影响某些决策。现实状况下，无论如何都应该有 远程形态 Remote State和 形态锁定 State Locking
命名规范应该对名目的最终领有者无心义，而不是只对开发团队无心义。假设名目会转交给其余团队，应该确保他们对命名规范有发言权。假设代码由非技术的利益相关者或外部安保/ GCR团队担任审查，应该确保他们会审核命名规范。另外，关于资源称号，为了让代码审查人员更细心肠启动审核，你应该经常使用资源标签，把无关的数据分类/隐衷需求（高、中、低）标示进去。
2、重用，重用，重用
Terraform 注册表 为大少数一般用例提供了现成模块类库。我曾经经常使用过 VPC模块和安保模块中的少量性能，这些性能只须要提供相关的参数就能经常使用。经常使用不同的参数，简干燥用这些模块关于解决大局部用例曾经足够了。尽或许多地重用这些公共模块，可以防止少量且重复的编码、测试、审核、修复、重构等操作。
我也发现，基于经常使用或变卦的频率划分模块和资源大无好处。例如，只经常使用一次性的基础设备手脚架，例如 VPC 相关设置、安保模块、路由表、VPC端点等，可以放在一同。然而像私有托管域条目、智能伸缩模块、指标模块、负载平衡器等，每次部署时都会变动，所以把这些与一次性性的基础设备手脚架分分开来，会令代码审核更繁难，调试更极速。
3、要明白，而非隐含
Terraform 代码中有一些经常出现的形式，它会造成设计中出现失误的假定。团队可以假定用来写代码的 Terraform 版本永远坚持不变，外部模块不会变动，或它们经常使用的提供者不会变卦。当这些外部依赖无法防止地出现变动时，就会造成一些难以发现的疑问。
无论何处（包括关键的 Terraform 组、提供者组、性能模块组）都要确保定义是明白的。事前定义版本，可以确保依赖库是固定的，因此你可以在探讨、审查、测试后，明明白白地降级依赖相关。
4、智能化每一处，包括笔记本电脑、共享虚构机、CI/CD。
在部署的各个阶段经常使用智能化方法，可以防止或许出现的疑问。
在你提交代码前，经常使用
Git 预提交钩子
运转
terraform fmt
和
terraform validate
。预提交钩子的作用是确保你的代码满足最低水平的格局和语法正确。把这个预提交文件检入到仓库，对你的团队成员都无好处。名目的第一步就启动品质控制相关的操作，它只管外表上是大事一桩，但也很关键，能为名目节俭少量期间。
一切现代化部署工具都有 CI 流程。当你向原始仓库推送代码时，可以经常使用它来运转 SAST 和单元测试工具。我写过一篇 博客 ，是关于经常使用 Checkov 测试 Terraform 代码的安保性和合规性，并为组织特定的惯例创立自定义审核。把这些单元测试工具添加到你的 CI 管道，可以改良代码品质和强健性。
5、写个好的README.md文件
咱们都以为 Terraform 代码是自文档化的。确实如此，然而只要当未来的团队曾经了解你的公司的命名规范、开发指南、秘密通讯、圈内笑话，以及你的仓库内除有效的 Terraform 代码之外其余一切物品，才会如此。保养
README.md
文件是个好习气，它能节俭少量期间，而且团队成员要为自己向 README 文件提交的任何内容担任，这样也就确保团队成员的忠实度。
你的 README 文件至少应该蕴含在你的上班环境下（Linux、 Windows、Mac 等等）初始化 Terraform环境的步骤，包括 Terraform 的版本消息。它应当确定须要的依赖库（Checkov、 TerraGrunt及其余依赖）和其版本，以及团队经常使用的繁难的 Linux 别名（例如有人青睐将
terraform fmt
简写为）。最关键的是，须要确定分支和 PR 审核战略和流程、命名规范和资源标签的相关规范。
README 文件须要经过这样的测验：假设团队有新成员添加，能否通知他们做什么以及如何正确地实现上班？假设不能，在后续的几个月内，你将面对的是无休止的规范和流程探讨会议。
完结语
这些就是我经常使用 Terraform 多年后，以为须要教授给大家的五条有用的倡导。
