跳至主要内容

管理工作区

OpenTofu CLI 中的工作区指的是同一个 OpenTofu 工作目录中的 状态数据 的独立实例。它们与云后端中的工作区有明显区别，后者各自具有自己的 OpenTofu 配置，并作为独立的工作目录运行。

OpenTofu 依赖状态将资源与现实世界对象关联起来。当您使用不同的状态数据多次运行相同的配置时，OpenTofu 可以管理多组不重叠的资源。

工作区可能对特定的 用例 有所帮助，但使用 OpenTofu CLI 时并不强制使用它们。对于需要单独凭据和访问控制的复杂部署，我们建议使用 其他方法。

管理 CLI 工作区​

每个 已初始化的工作目录 从一个名为 default 的工作区开始。

使用 tofu workspace list、tofu workspace new 和 tofu workspace delete 命令来管理当前工作目录中的可用工作区。

使用 tofu workspace select 命令 来更改当前选定的工作区。对于给定的工作目录，您一次只能选择一个工作区。大多数 OpenTofu 命令只与当前选定的工作区交互。这包括 配置 和 状态操作。

当您在每个工作区中配置基础设施时，通常需要手动指定不同的 输入变量 来区分每个集合。例如，您可能将测试基础设施部署到不同的区域。

用例​

您可以创建多个 工作目录 来维护具有完全独立状态数据的配置的多个实例。但是，OpenTofu 为每个工作目录安装单独的插件和模块缓存，因此维护多个目录会浪费带宽和磁盘空间。这种方法还需要额外的任务，例如分别从版本控制更新每个目录中的配置，以及在您更改配置时重新初始化每个目录。工作区很方便，因为它们让您使用相同的配置工作副本以及相同的插件和模块缓存来创建不同的基础设施集。

多个工作区的常见用途是创建一组基础设施的并行、独立副本，以便在修改生产基础设施之前测试一组更改。

非默认工作区通常与版本控制中的功能分支相关。默认工作区可能对应于 main 或 trunk 分支，它描述了生产基础设施的预期状态。当开发人员为更改创建功能分支时，他们也可能创建相应的工作区，并在其中部署主基础设施的临时副本。然后，他们可以在副本上测试更改，而不会影响生产基础设施。一旦更改合并并部署到默认工作区，他们就会销毁测试基础设施并删除临时工作区。

何时不应使用多个工作区​

工作区让您可以在其单个后端内快速切换单个配置的多个实例。它们并非旨在解决所有问题。

在使用 OpenTofu 管理大型系统时，您应该创建单独的 OpenTofu 配置，这些配置对应于系统内的架构边界。这使团队能够分别管理不同的组件。工作区本身不适合系统分解，因为每个子系统都应该有自己的单独配置和后端。

特别是，组织通常希望在为不同的开发阶段或不同的内部团队提供服务的相同基础设施的多个部署之间创建严格的隔离。在这种情况下，每个部署的后端通常具有不同的凭据和访问控制。工作目录内的 CLI 工作区使用相同的后端，因此它们不适合此场景的隔离机制。

工作区的替代方案​

您可以使用一个或多个 可重用模块 来表示公共元素，然后将每个实例表示为单独的配置，并在不同的 后端 上下文中实例化这些公共元素，而不是创建 CLI 工作区。每个配置的根模块仅包含后端配置和少量 module 块，其参数描述了部署之间任何微小的差异。

当多个配置表示不同的系统组件而不是多个部署时，您可以使用成对的资源类型和数据源将数据从一个组件传递到另一个组件。

  • 如果您有一个可从所有配置访问的配置管理系统，那么可以使用 resource 来导出变量，而另一个配置可以使用 datasource 来导入它们。

  • 在支持用户定义标签或标记的系统中，使用标记约定使资源自动可发现。例如，使用 aws_vpc 资源类型 来分配适当的标签，然后使用 aws_vpc 数据源 在其他配置中按这些标签查询。

  • 对于服务器地址，使用特定于提供商的资源来创建具有可预测名称的 DNS 记录。然后，您可以直接使用该名称，或者使用 dns 提供商 在其他配置中检索已发布的地址。

  • 如果您将一个配置的 OpenTofu 状态存储在其他配置可以访问的远程后端中，那么其他配置可以使用 terraform_remote_state 直接使用其根模块输出。此设置在配置之间创建更紧密的耦合，并且根配置不需要在单独的系统中发布其结果。

工作区内部机制​

工作区在技术上等同于重命名您的状态文件。OpenTofu 然后包含一组针对远程状态的保护和支持。

工作区也旨在作为共享资源。它们不是私有的，除非您使用纯本地状态并且没有将您的状态提交到版本控制。

对于本地状态，OpenTofu 将工作区状态存储在名为 terraform.tfstate.d 的目录中。此目录应与仅本地 terraform.tfstate 相似对待。一些团队会将这些文件提交到版本控制，但我们建议在有多个协作者时使用远程后端。

对于 远程状态，工作区直接存储在配置的 后端 中。例如，如果您使用 Consul，则工作区通过将工作区名称附加到状态路径来存储。为了确保工作区名称在所有后端中正确且安全地存储，该名称必须在不转义的情况下用于 URL 路径段中有效。

OpenTofu 在被忽略的 .terraform 目录中本地存储当前工作区名称。这允许多个团队成员同时处理不同的工作区。工作区名称还附加到云后端中关联的远程工作区。有关云后端中工作区名称的更多详细信息，请参阅 CLI 集成（推荐） 和 远程后端 文档。