【问题标题】:Terraform Shared StateTerraform 共享状态
【发布时间】:2023-03-22 21:33:01
【问题描述】:

地形 0.9.5。

我正在整理一组模块,我们的基础架构团队和自动化团队将使用这些模块以标准方式创建资源,然后创建堆栈以提供不同的环境。一切运作良好。

像所有使用terraform 共享状态的团队一样,成为一个问题。我已将 terraform 配置为使用 s3 后端,即版本化和加密,通过 dynamo db 表添加锁。完美的。一切都适用于本地帐户...好的问题...

我们有多个 aws 帐户,1 个用于 IAM,1 个用于计费,1 个用于生产,1 个用于非生产,1 个用于共享服务等等……你知道我要去哪里。我的问题如下。

我以 IAM 账户中的用户身份进行身份验证并担任所需角色。在我引入 terraform 后端配置以利用 s3 共享状态之前,这一直像梦一样工作。看起来 terraform 中的后端配置需要在 ~/.aws/credentials 中设置默认凭据。看起来这些用户必须是创建 s3 存储桶的帐户的本地用户。

有没有办法让后端配置设置使用在提供程序中配置的凭据和角色?有没有更好的方法来配置共享状态和锁定?欢迎任何建议:)

更新:搞定了。我在创建 s3 存储桶的帐户中创建了一个新用户。创建了一个策略,只允许新用户 s3:DeleteObject、GetObject、PutObject、ListBucket 和 dynamodb:* 在特定的 s3 存储桶和 dynamodb 表上。创建了一个自定义凭据文件并添加了默认配置文件,其中包含分配给该新用户的访问和密钥。使用类似于

的后端配置
terraform {
   required_version = ">= 0.9.5"

   backend "s3" {
      bucket                  = "remote_state"
      key                     = "/NAME_OF_STACK/terraform.tfstate"
      region                  = "us-east-1"
      encrypt                 = "true"
      shared_credentials_file = "PATH_TO_CUSTOM_CREDENTAILS_FILE"
      lock_table              = "MY_LOCK_TABLE"
    }
}

它可以工作,但需要在您的个人资料中进行初始配置才能使其正常工作。如果有人知道更好的设置或可以识别我的后端配置的问题,请告诉我。

【问题讨论】:

  • 从你的描述来看,很多主要观点都是基于的。 Terraform 从不要求您共享状态文件。
  • 它似乎按预期工作。我为每个堆栈使用不同的键,并使用一个 dynamodb 表。
  • @BMW 这是推荐的。 “在团队中使用 Terraform 时,使用本地文件会使 Terraform 的使用变得复杂,因为每个用户在运行 Terraform 之前必须确保他们始终拥有最新的状态数据,并确保没有其他人同时运行 Terraform”terraform.io/docs/state/remote.html

标签: amazon-s3 amazon-dynamodb terraform


【解决方案1】:

Terraform 期望后端配置是静态的,并且由于需要在完成任何其他工作之前初始化后端,因此不允许它在配置中的其他地方包含插值变量。

因此,使用不同的 AWS 账户多次应用相同的配置可能会很棘手,但可以通过以下两种方式之一来实现。


摩擦最小的方法是创建一个 S3 存储桶和 DynamoDB 表,专门用于跨所有环境的状态存储,并使用 S3 权限和/或 IAM 策略来实施精细的访问控制。

采用此策略的组织有时会在单独的“管理”AWS 账户中创建 S3 存储桶,然后将对该存储桶中各个状态对象的限制性访问权限授予将在其他每个账户中运行 Terraform 的特定角色。

该解决方案的优势在于,一旦在 S3 中正确设置,Terraform 就可以常规使用,无需任何异常工作流程:在后端配置单个 S3 存储桶,并通过环境变量提供适当的凭据以允许它们变化。初始化后端后,使用 workspaces(在 Terraform 0.10 之前称为“状态环境”)为单个配置的每个目标环境创建单独的状态。

缺点是需要围绕 S3 管理更复杂的访问配置,而不是简单地依赖整个 AWS 账户的粗略访问控制。混合使用 DynamoDB 也更具挑战性,因为 DynamoDB 上的访问控制没有那么灵活。

Terraform s3 提供者文档Multi-account AWS Architecture 中对此选项有更完整的描述。


如果不需要复杂的 S3 配置,则可以使用 partial configuration 将复杂性转移到 Terraform 工作流中。在此模式下,config 中仅提供后端设置的子集,而在运行terraform init 时在命令行中提供其他设置。

这允许选项在运行之间有所不同,但由于它需要提供额外的参数,因此大多数采用这种方法的组织将使用 包装脚本 根据当地惯例适当地配置 Terraform。这可以只是一个简单的 shell 脚本,使用合适的参数运行 terraform init

然后,这允许通过在命令行上提供自定义凭据文件来改变它。在这种情况下,不使用状态环境,而是在环境之间切换需要针对新的后端配置重新初始化工作目录。

此解决方案的优点是它不会对 S3 和 DynamoDB 的使用施加任何特定限制,只要可以将差异表示为 CLI 选项即可。

缺点是需要不寻常的工作流或包装脚本来配置 Terraform。

【讨论】:

  • 在使用选项 #1 时,terraform 如何知道我在预生产帐户和生产帐户中运行的内容之间的区别?我担心状态会被彼此的数据破坏。这一切都由工作区处理吗?
  • 每个工作区都有一个完全独立的状态,所以只要您确保在运行terraform planterraform apply 时选择了正确的工作区,它就无法访问任何状态信息其他工作区。由于我写了这个答案,现在 Terraform 网站上有第一个选项的完整指南:terraform.io/docs/backends/types/…
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2022-09-24
  • 2021-10-10
  • 2021-05-27
  • 2019-10-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多