Terraform工作空间与孤立目录？

Question

我正在阅读"Terraform: Up &著，第二版“Yevgeniy著，作者正在经历大量的工作而不使用工作区？这是声音吗？看起来真的很深奥。他的理由如下：

“所有工作区的状态文件都存储在相同的后端...工作区中，在代码中或终端上是不可见的，除非运行terraform workspace ...将前两项放在一起，否则工作区可能会相当容易出错。”

至于第二点，如果存在问题，为什么不直接将工作区添加到您的PS1中呢？使用类似于ZSH/PowerLevel10k的工具，我的提示符显示了Terraform工作区信息。

就第一点而言，我将其分解为单独问题。

在这个工作区和目录中还有什么是我遗漏的，用于隔离吗？

Answer 1

工作区是一种不必要的复杂性，它会导致破坏您的prod环境(或泄漏秘密)的可能性。切换后端是一种更好的做法，这一点在docs中得到了注意：

https://www.terraform.io/language/state/workspaces

特别是，组织通常希望在为不同开发阶段(例如阶段与生产)或不同内部团队服务的同一基础设施的多个部署之间创建一个强有力的分离。在这种情况下，用于每个部署的后端通常属于该部署，具有不同的凭据和访问控制。命名工作区不是此场景的合适隔离机制。相反，使用一个或多个可重用的模块来表示公共元素，然后将每个实例表示为在不同后端的上下文中实例化这些公共元素的单独配置。在这种情况下，每个配置的根模块将仅由后端配置和少量模块块组成，这些模块块的参数描述了部署之间的任何微小差异。

新的hotness是一个后端文件，您可以在init中选择该文件：

https://www.terraform.io/language/settings/backends/configuration#file

Answer 2

作者进一步深入研究了这本书，并在第304页中找到了这一点。

...a 1:1表示.如果我浏览您的活动存储库，我应该能够通过快速扫描看到在哪些环境中部署了哪些资源。也就是说，每个资源都应该有一个1:1匹配的一些代码行签入实时回购。乍一看，这是显而易见的，但却令人惊讶地容易出错。...一个更微妙的错误方法是使用Terraform工作区来管理环境，这样就有了活动的基础设施，但是代码就不在了。也就是说，如果您使用工作区，那么live将只有一个代码副本，即使您可能部署了3或30个环境。仅仅看代码，就无法知道实际部署了什么，这将导致错误并使维护变得复杂。因此，正如在第88页的“通过工作区隔离”中所描述的那样，您不需要使用工作区来管理环境，而是希望使用单独的文件在单独的文件夹中定义每个环境，这样您就可以通过浏览活动存储库来准确地看到部署了哪些环境。

因此，作者的顾虑之一--尽管被描述为“在代码或终端上不可见”--似乎更为普遍，并扩展到不支持Terraform工作区的工具(如web浏览器，例如，GitHub)。作者想知道代码是在哪里部署的，而不需要删除它。这样，他就可以在不使用“工作区”的情况下看到正在开发和生产的内容。

后来，他将其扩展到Git分支的整个部分，这有点奇怪，因为他的问题甚至更小(pg 304)，

不幸的是，分枝只解决了部分问题。尽管Terraform后端为Terraform状态提供了锁定，但它们无法帮助您在Terraform代码本身的级别进行锁定。特别是，如果两个团队成员将相同的代码部署到相同的环境中，但是来自不同的分支，则会遇到锁定无法阻止的冲突。

但是，当然，“将相同的代码部署到相同的环境，但来自不同的分支”听起来确实是个糟糕的想法。