使用 OpenTofu
OpenTofu 的核心工作流程包含三个步骤
- 编写 - 以代码形式编写基础设施。
- 计划 - 在应用更改之前预览更改。
- 应用 - 配置可复现的基础设施。
本指南将逐步介绍这三个步骤如何在个人从业者工作环境中发挥作用，以及当团队协作处理基础设施时它们如何演变，以及云后端如何使此工作流程能够为整个组织顺利运行。
作为个人从业者工作
首先，让我们了解一下这些部分作为一个在基础设施即代码方面工作的个人是如何协同工作的。
编写
您就像编写代码一样编写 OpenTofu 配置：在您选择的编辑器中。即使您只是作为个人操作，将您的工作存储在版本控制存储库中也是一种常见的做法。
# Create repository
$ git init my-infra && cd my-infra
Initialized empty Git repository in /.../my-infra/.git/
# Write initial config
$ vim main.tf
# Initialize OpenTofu
$ tofu init
Initializing provider plugins...
# ...
OpenTofu has been successfully initialized!
在您编写配置的过程中，重复运行计划可以帮助您找出语法错误，并确保您的配置按预期组合在一起。
# Make edits to config
$ vim main.tf
# Review plan
$ tofu plan
# Make additional edits, and repeat
$ vim main.tf
这与作为个人处理应用程序代码类似，在应用程序代码中，编辑代码和运行测试命令之间的紧密反馈循环非常有用。
计划
当“编写”步骤的反馈循环产生了看起来不错的更改时，就该提交您的工作并查看最终计划了。
$ git add main.tf
$ git commit -m 'Managing infrastructure as code!'
[main (root-commit) f735520] Managing infrastructure as code!
1 file changed, 1 insertion(+)
因为 tofu apply 会在继续更改任何基础设施之前显示一个计划以供确认，所以这是您用于最终审查的命令。
$ tofu apply
An execution plan has been generated and is shown below.
# ...
应用
经过最后一次检查后，您就可以告诉 OpenTofu 配置真实的基礎設施了。
Do you want to perform these actions?
OpenTofu will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
# ...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
此时，通常会将您的版本控制存储库推送到远程位置以进行安全保存。
$ git remote add origin https://github.com/*user*/*repo*.git
$ git push origin main
此核心工作流程是一个循环；下次您想进行更改时，您可以从头开始该过程。
注意此工作流程与作为个人编写应用程序代码或脚本的过程有多么相似？这就是我们所说的 OpenTofu 支持基础设施即代码的原因。
团队协作
一旦多人协作处理 OpenTofu 配置，就必须在核心工作流程的每个部分添加新的步骤，以确保每个人都能顺利地一起工作。您会发现，许多这些步骤与我们在团队而不是个人协作处理应用程序代码时所做的工作流程更改相似。
编写
虽然团队中的每个人仍然在其选择的编辑器中对 OpenTofu 配置进行更改，但他们会将更改保存到版本控制的分支中，以避免与彼此的工作发生冲突。在分支中工作使团队成员能够使用其正常的合并冲突工作流程解决相互不兼容的基础设施更改。
$ git checkout -b add-load-balancer
Switched to a new branch 'add-load-balancer'
在编写配置时，运行迭代计划仍然作为反馈循环很有用，尽管随着时间的推移，让每个团队成员的计算机都能运行它们变得越来越困难。随着团队和基础设施的增长，运行计划所需的敏感输入变量（例如 API 密钥、SSL 证书对）的数量也在增加。
为了避免每个团队成员在本地安排所有敏感输入的负担和安全风险，团队通常会迁移到在共享的持续集成 (CI) 环境中执行 OpenTofu 操作的模型。创建此类 CI 环境所需的工作并非微不足道，并且超出了此核心工作流程概述的范围。
将更改提交到版本控制然后等待 CI 管道执行的这个较长的迭代周期通常足够长，以至于禁止在编写单个 OpenTofu 配置更改时使用推测性计划作为反馈循环。但是，正如我们将在下一分钟看到的，在应用新的 OpenTofu 更改甚至合并到主要开发分支之前，推测性计划仍然有用。
计划
对于协作处理基础设施的团队，OpenTofu 的计划输出为团队成员提供了审查彼此工作的机会。这允许团队在进行任何可能造成危害的更改之前提出问题、评估风险并发现错误。
这些审查自然发生在版本控制中的拉取请求旁边——个人提出将其工作分支合并到共享团队分支的请求时。如果团队成员在推测性计划输出旁边审查提议的配置更改，他们可以评估更改的意图是否通过计划实现。
问题变成了为团队审查生成该推测性计划输出。一些仍然在本地运行 OpenTofu 的团队的做法是，拉取请求应包含更改作者生成的推测性计划输出的附加副本。其他团队则安排其 CI 系统自动将推测性计划输出发布到拉取请求中。
除了审查计划以确保其作者意图的正确表达外，团队还可以评估他们是否希望现在进行此更改。例如，如果团队注意到某个更改可能导致服务中断，他们可能会决定延迟合并其拉取请求，直到他们能够安排维护窗口。
应用
一旦拉取请求被批准并合并，团队务必审查针对共享团队分支和最新版本的状态文件运行的最终具体计划。
由于合并顺序或最近的基础设施更改等问题，此计划可能与拉取请求中审查的计划不同。例如，如果自审查计划以来对您的基础设施进行了手动更改，则合并时的计划可能会有所不同。
此时，团队会询问有关应用更改的潜在影响的问题。我们是否预计此更改会造成任何服务中断？此更改的任何部分风险都很高吗？在我们应用此更改时，我们系统中是否有任何需要关注的部分？我们需要通知任何人此更改正在发生吗？
根据更改的不同，有时团队成员希望在更改应用过程中观察应用输出。对于本地运行 OpenTofu 的团队，这可能涉及与团队进行屏幕共享。对于在 CI 中运行 OpenTofu 的团队，这可能涉及查看构建日志。
与个人工作流程一样，团队的核心工作流程也是一个循环，每次更改都会执行此循环。对于一些团队，这个循环每周发生几次，而对于其他团队，则每天发生很多次。
结论
OpenTofu 的使用方法多种多样：可以作为个人用户、单个团队或整个组织大规模使用。选择最适合所需协作密度的方案，将为您在 OpenTofu 核心工作流程上的投入带来最大的回报。对于大规模使用 OpenTofu 的组织，TACOS（TF 自动化与协作软件）引入了基于此核心工作流程的新层，以解决团队和组织独有的问题。