关于设置 Terraform 的 5 个技巧

这些是我使用 Terraform 五年后的经验教训。
42 位读者喜欢这篇文章。
Puzzle pieces coming together to form a computer screen

Opensource.com

使用 Terraform 超过五年,我学到了一些关键的经验教训。无论团队规模或项目性质如何,以下五个实践对于拥有逻辑清晰且可用的 Terraform 设置至关重要。

1. 了解你的目标受众。

这一点似乎显而易见,但我已经多次看到它出错。在组织 Terraform 代码时,无论是标准化目录结构还是定义命名约定,考虑目标受众至关重要。你的团队会使用这些 Terraform 脚本和模块吗?你是要将工作移交给另一个团队吗?是否会有新人加入你的团队?你是单独进行这个项目吗?你会在六个月或一年后使用这个设置,还是会将其分配给其他人?

诸如此类的问题会影响多个决策。理想情况下,无论现在或将来团队规模如何,你都应该部署 远程状态状态锁定。远程状态将确保你的笔记本电脑不是 Terraform 工作的唯一场所,而状态锁定将确保一次只有一个人在更改基础设施。

命名约定应该对项目的最终所有者有意义,而不仅仅是编写代码的团队。如果项目是为另一个团队准备的,请确保他们对命名约定有发言权。如果非技术利益相关者或内部安全/GCR 团队审查代码,请确保他们检查命名约定。除了资源名称之外,你还应该利用资源标签来突出显示任何数据分类/隐私要求(高、中、低),以便审查人员更仔细地检查。

2. 重用、重用、再重用。

Terraform Registry 提供了最常见用例的现成模块库。我曾写过 VPC 模块和安全组中可用的广泛参数化。只需使用不同的参数调用模块就足以处理大多数(即使不是全部)潜在的用例。尽可能多地重用这些共享模块,以避免无休止的键入、测试、检查、修复和重构。

我还发现,根据使用或更改的频率来分隔模块和资源是有益的。例如,基础设施支架通常只使用一次,例如设置 VPC、安全组、路由表、VPC 终端节点等等。但是,诸如私有托管区域条目、自动伸缩组、目标组、负载均衡器等,可能会在每次部署时发生变化,因此将这些与一次性支架分开将使代码审查更容易,调试更快。

3. 显式优于隐式。

我见过 Terraform 代码中存在一些常见模式,这些模式会导致设计中存在不正确的假设。团队可能会假设今天用于编写代码的 Terraform 版本永远不会改变,或者外部模块不会改变,或者他们正在使用的提供商不会改变。当这些外部依赖项不可避免地更新时,这些会导致几周后出现隐性问题。

确保在所有可能的地方显式定义版本:在主 Terraform 块中、在 provider 块中、在模块块中等等。定义版本可确保你的依赖库保持冻结状态,以便你可以在充分的讨论、审查和测试后,在需要时显式更新依赖项。

4. 在任何地方自动化。你的笔记本电脑。你的共享 VM。你的 CI/CD。

在部署过程的每个阶段利用自动化可以避免未来问题的发生。

使用 Git pre-commit hooks 在你提交代码之前运行 terraform fmt terraform validate。Pre-commit hooks 确保代码至少格式正确且语法正确。将此 pre-commit 文件检入到 repo,你的团队中的每个人都可以从相同的自动化中受益。在流程的第一步进行这种小而至关重要的质量控制可以节省大量时间,随着项目的进展。

所有现代部署工具都具有 CI 流程。你可以使用这些流程在将代码推送到 origin 时运行 SAST 和单元测试工具。我曾在我的博客中写过 Checkov 如何测试 Terraform 代码的安全性与合规性并创建组织特定约定的自定义检查。将这些单元测试工具添加到你的 CI 管道中,以提高代码质量和健壮性。

5. 拥有一个出色的 README.md。

我们都喜欢认为 Terraform 代码是自我记录的。当然是,但前提是你的未来团队已经了解你公司的命名约定和指南以及秘密握手和内部笑话以及你的 repo 中除了有效的 Terraform 代码之外的其他内容。养成编写良好 README.md 的习惯可以节省大量时间,并且它通过让他们对 README 中明确提交的所有内容负责,从而保持团队的诚信。

至少,你的 README 应该包含在你的工作站(Linux、Windows、Mac 等)上初始化正确的 Terraform 环境的步骤,包括要安装的 Terraform 版本。它应该指定所需的依赖项(Checkov、TerraGrunt 和其他项)及其版本,以及你的团队使用的任何方便的 Linux 别名(有些人喜欢将 tff 定义为 terraform fmt 的简写)。最重要的是,应指定分支和 PR 审查策略和流程、命名约定和资源标记标准。

README 应该通过一个简单的测试:如果明天有新成员加入你的团队,README 是否足以教他们做什么以及如何正确地做?如果不是,你可能会发现自己在接下来的几个月里不断地主持永无止境的标准和流程会议。

总结

在与 Terraform 合作多年之后,这些是我要传递的五个最佳智慧。欢迎在下方分享你自己的最佳实践。

接下来阅读什么

开始使用 Argo CD

Argo CD 是一个简单的基于拉取的 GitOps 部署工具,可将 Kubernetes 清单文件与集群同步,以实现简单、务实的部署。

标签
https://ayushsharma.in
我是一名作家和 AWS 解决方案架构师。我与初创公司和企业在软件工程、DevOps、SRE 和云架构方面合作。我在 https://ayushsharma.in 上写下我的经验。

评论已关闭。

© . All rights reserved.