amazon-s3 - Terraform 共享状态

Question

地形 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 表上。创建了一个自定义凭据文件并添加了默认配置文件，其中包含分配给该新用户的访问和 key 。使用了类似的后端配置

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"
    }
}

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

Answer 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。这可以只是一个运行 terraform init 的简单 shell 脚本。有合适的论据。

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

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

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