在复杂的体系结构中管理Terraform状态文件
抱歉，如果我需要一个冗长的解释，然后才能提出实际问题……
我们正在尝试将基础架构的配置转移到Terraform，但如何使用/管理状态文件遇到挑战。谁能提出如何使以下措施工作或提出一种将面临这一挑战的不同方法？
基本设置
我们的环境很大（1000个对象），因此我们假设
- 如果有人不同意此陈述，我们每个环境都不能拥有一个状态文件，请您解释为什么要有一个巨大的状态文件不是问题吗？
因此，当前的计划是每个对象类型具有状态文件，并且由于我们每个对象类型也有一个模块，因此应合理地实现这一点。因此，例如，我们将拥有一个用于实现数据库（使用数据库状态文件）的标准模块和一个用于部署模式的标准模块（该模块将使用架构状态文件）。
该结构是由中央团队构建的，但将由多个构建团队使用（并且可能通过API访问其他系统）。因此，构建团队不需要知道如何提供数据库，他们只需要调用数据库模块并传递适当的变量集
挑战
以及能够提供单个对象类型，也是模式，其中需要将多个对象作为“捆绑包”的一部分进行配置（因为缺乏更好的术语）。例如，在配置特定类型的数据库时，我们始终需要在该数据库中提供2个模式。
为了做到这一点，我们将创建一个新的模块，该模块一次调用数据库模块两次。我们不能将实际的代码用于在此新模块中配置数据库和模式，因为这意味着我们在多个位置中具有相同的代码，而这些代码是无法支持的。
但是，如果我们构建这样的捆绑模块，我的理解是它只能将信息存储在一个状态文件中，即状态文件已绑定到主模块，而不是与它正在调用的单个模块相关 - 因此我们需要每个捆绑包具有状态文件。这不一定是创建对象时的问题，而是随后维护对象的问题 - 因为可以隔离单个对象，而不是作为捆绑包的一部分更改。
因此，一个数据库和两个模式可以由构建团队提供，然后移交给数据分析团队。六个月后，数据分析团队希望重命名其中一个模式。他们对原始配置过程不了解，这是作为捆绑包的一部分或所使用的代码完成的事实 - 他们要做的就是调用架构模块并通过完全合格的模式名称（以识别对象要更改）和他们想要更改为新名称。但是，为了更改该架构名称，该过程需要知道在哪里可以找到相关状态文件 - 也就是说，可以链接到他们不知道的某些捆绑包名称/标识符。
关于如何工作的任何想法？
更新
给出了下面的评论，让我尝试并澄清...
“ DB Analytics团队不了解如何创建DB并提取识别相关状态文件所需的信息 - 但这是非常不友好的。此过程的重点是使Terraform成为“黑匣子”，用户不需要知道其工作原理。如果用户希望更改架构名称，则他们应该提供的唯一信息是当前名称（以确定要更改的对象）以及他们希望将其更改为的新名称。
含糊，非特异性的“挑战”：具体的挑战是，如果将对象作为较大过程的一部分（覆盖多个对象）提供，那么该对象将在该较大过程的状态文件中。如果我们随后想孤立地维护该对象（不是作为更广泛的过程的一部分），我们如何找到持有该特定对象的状态文件？
apologies if this requires a lengthy explanation before I get to the actually question...
we are trying to move the provisioning of our infrastructure to Terraform but are running into challenges with how to use/manage state files. Can anyone suggest how the following might be made to work or suggest a different approach that would get round this challenge?
Basic Set Up
Our environment is large (1000s of objects) so we've assumed that we cannot have a single state file per environment
- If anyone disagrees with this statement, please can you explain why having a huge state file would not be an issue?
Therefore, the current plan is to have a state file per object type and, as we also have a module per object type, this should be reasonably straightforward to implement. So, for example, we would have a standard module for implementing databases (which would use the database state file) and a standard module for deploying schemas (which would use the schema state file).
This structure is being built out by a central team but will be used by multiple build teams (and potentially will be accessed by other systems via APIs). So a build team doesn't need to know how to provision a database, they just need to call the database module and pass in the appropriate variable set
Challenge
As well being able to provision individual object types, there are also patterns where multiple objects need to be provisioned as part of a "bundle" (for want of a better term). For example, when provisioning a particular type of database we would always also need to provision 2 schemas within that database.
In order to do this we would create a new module that calls the database module once and then the schema module twice. We can't put the actual code for provisioning databases and schemas in this new module - as that would mean we had the same code in multiple places which would be unsupportable.
However, if we build a bundle module like this, my understanding is that it can only store information in a single state file i.e. the state file is tied to the main module and not to the individual modules it is calling - and so we would need to have a state file per bundle. This is not necessarily an issue when creating an object but is an issue when subsequently maintaining an object - because the the individual objects can be changed in isolation, not as part of a bundle.
So a database and two schemas could be provisioned by a build team and then handed over to a data analytics team. Six months later, the data analytics team wants to rename one of the schemas. They have no knowledge of the original provisioning process, the fact that it was done as part of a bundle or the code that was used - all they want do is call the schema module and pass in the fully qualified schema name (to identify the object to be changed) and the new name they want it changed to. But in order to change that schema name, somehow the process needs to know where to find the relevant state file - that is, presumably, linked to some bundle name/identifier that they have no knowledge of.
Any thoughts on how this could work?
UPDATE
Given the comments below, let me try and clarify...
"DB analytics team having no knowledge of how the DB was created": obviously there are ways that this team could discover how this DB was created and extract the information needed to identify the relevant state file - but this is extremely user-unfriendly. The main point of this process is to make Terraform a "black box" that users don't need to know how it works. If a user wants a schema name to be changed the only information they should have to provide is the current name (to identify the object to be changed) and the new name they want it changed to.
vague, non-specific "challenges": The specific challenge is that if an object has been provisioned as part of a larger process (covering multiple objects) then that object will be in the state file for that larger process. If we subsequently want to maintain that object in isolation (not as part of that wider process), how do we find the state file that holds that specific object?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论