本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

后端最佳实践

使用适当的远程后端存储状态文件对于实现协作、通过锁定确保状态文件的完整性、提供可靠的备份和恢复、与 CI/CD 工作流程集成以及利用 HCP Terraform 等托管服务提供的高级安全、治理和管理功能至关重要。

Terraform 支持各种后端类型，例如 Kubernetes、 HashiCorp Consul 和 HTTP。但是，本指南重点介绍了 Amazon S3，它是大多数 AWS 用户的最佳后端解决方案。

作为一项具有高持久性和可用性的完全托管的对象存储服务，Amazon S3 为管理 Terraform 状态提供了安全、可扩展且低成本的后端。 AWS Amazon S3 的全球足迹和弹性超过了大多数团队通过自我管理状态存储所能达到的水平。此外，Amazon S3 与 AWS 访问控制、加密选项、版本控制功能和其他服务原生集成使得 Amazon S3 成为便捷的后端选择。

本指南不为其他解决方案（例如 Kubernetes 或 Consul）提供后端指导，因为主要目标受众是客户。 AWS 对于完全加入的团队来说，Amazon S3 通常是理想的选择 AWS 云，而不是 Kubernetes 或 HashiCorp Consul 集群。Amazon S3 状态存储的简单性、弹性和紧密 AWS 集成性为大多数遵循最佳实践的用户提供了 AWS 最佳基础。团队可以利用 AWS 服务的耐久性、备份保护和可用性来保持远程 Terraform 状态的高弹性。

遵循本节中的后端建议将提高Terraform代码库的协作性，同时限制错误或未经授权的修改的影响。通过实施架构良好的远程后端，团队可以优化 Terraform 工作流程。

使用 Amazon S3 进行远程存储

与本地文件存储相比，在 Amazon S3 中远程存储 Terraform 状态以及使用 Amazon DynamoDB 实现状态锁定和一致性检查具有重大优势。远程状态支持团队协作、变更跟踪、备份保护和远程锁定，从而提高安全性。

使用具有 S3 标准存储类别（默认）的 Amazon S3，而不是临时的本地存储或自我管理解决方案，可提供 99.999999999% 的持久性和 99.99% 的可用性保护，以防止状态数据意外丢失。 AWS 诸如 Amazon S3 和 DynamoDB 之类的托管服务提供的服务级别协议 (SLA) 超过了大多数组织在自行管理存储时所能达到的水平。依靠这些保护来保持远程后端的可访问性。

启用远程状态锁定

DynamoDB 锁定会限制状态访问以防止并发写入操作。这样可以防止多个用户同时进行修改并减少错误。

带有状态锁定的后端配置示例：

terraform {
  backend "s3" {
    bucket         = "myorg-terraform-states"
    key            = "myapp/production/tfstate"
    region         = "us-east-1"
    dynamodb_table = "TerraformStateLocking"
  }
}

启用版本控制和自动备份

为了获得更多保护，请在 Amazon S3 后端 AWS Backup 上使用启用自动版本控制和备份。每当进行更改时，版本控制都会保留状态的所有先前版本。它还允许您在需要时恢复以前的工作状态快照，以回滚不需要的更改或从意外中恢复。

如果需要，还原以前的版本

受版本控制的 Amazon S3 状态存储桶可通过恢复先前已知的良好状态快照来轻松恢复更改。这有助于防止意外更改，并提供额外的备份功能。

使用 HCP Terraform

HCP Terraform 为配置自己的状态存储提供了一种完全托管的后端替代方案。HCP Terraform 可自动处理状态和加密的安全存储，同时解锁其他功能。

当您使用 HCP Terraform 时，默认情况下状态是远程存储的，这样就可以在整个组织中共享和锁定状态。详细的策略控制可帮助您限制州访问权限和更改。

其他功能包括版本控制集成、策略护栏、工作流程自动化、变量管理以及与 SAML 的单点登录集成。您也可以使用 Sentinel 策略作为代码来实施治理控制。

尽管HCP Terraform需要使用软件即服务 (SaaS) 平台，但对于许多团队来说，安全、访问控制、自动策略检查和协作功能方面的优势使其成为使用Amazon S3或DynamoDB进行自我管理状态存储的最佳选择。

与诸如 GitHub 次要配置之类 GitLab 的服务轻松集成也吸引了那些完全采用云和SaaS工具以改善团队工作流程的用户。

促进团队协作

使用远程后端在 Terraform 团队的所有成员之间共享状态数据。这便于协作，因为它使整个团队都能了解基础架构的变化。共享后端协议与状态历史透明度相结合，简化了内部变更管理。所有基础架构变更都要经过既定管道，从而提高了整个企业的业务灵活性。

通过使用来改善问责制 AWS CloudTrail

与 AWS CloudTrail Amazon S3 存储桶集成，以捕获对状态存储桶进行的 API 调用。筛选要跟踪CloudTrail 的事件PutObjectDeleteObject,以及其他相关呼叫。

CloudTrail 日志显示了每次 API 调用以更改状态的委托人的 AWS 身份。用户的身份可以与计算机帐户或与后端存储进行交互的团队成员进行匹配。

将 CloudTrail 日志与 Amazon S3 状态版本控制相结合，将基础设施变更与应用这些变更的委托人联系起来。通过分析多个版本，您可以将任何更新归因于计算机帐户或负责的团队成员。

如果发生意外或破坏性更改，状态版本控制将提供回滚功能。 CloudTrail 将更改追踪到用户，以便您可以讨论预防性改进。

我们还建议您强制执行 IAM 权限以限制状态存储桶的访问权限。总体而言，S3 版本控制和 CloudTrail 监控支持对基础设施变更进行审计。团队在 Terraform 状态历史中提高了问责制、透明度和审计能力。

将每个环境的后端分开

为每个应用程序环境使用不同的 Terraform 后端。单独的后端将开发、测试和生产之间的状态隔离开来。

缩小影响范围

隔离状态有助于确保较低环境中的变化不会影响生产基础架构。开发和测试环境中的事故或实验影响有限。

限制生产访问权限

将生产状态后端的权限锁定为大多数用户的只读访问权限。将谁可以修改生产基础架构限制为 CI/CD 管道和破碎玻璃角色。

简化访问控制

在后端级别管理权限可简化环境之间的访问控制。为每个应用程序和环境使用不同的 S3 存储桶意味着可以对整个后端存储桶授予广泛的读取或写入权限。

避免共享工作空间

尽管你可以使用 Terraform 工作区来区分环境之间的状态，但不同的后端可以提供更强的隔离。如果您共享工作空间，则事故仍可能影响多个环境。

保持环境后端完全隔离可以最大限度地减少任何单一故障或漏洞的影响。单独的后端还可以使访问控制与环境的敏感度级别保持一致。例如，您可以为生产环境提供写入保护，为开发和测试环境提供更广泛的访问权限。

主动监控远程状态活动

持续监控远程状态活动对于及早发现潜在问题至关重要。查找异常解锁、更改或访问尝试。

获取有关可疑解锁的警报

大多数状态更改都应通过 CI/CD 管道进行。如果状态解锁直接通过开发者工作站发生，则生成警报，这可能表示未经授权或未经测试的更改。

监控访问尝试

状态存储桶上的身份验证失败可能表示有侦测活动。请注意，如果有多个账户正在尝试访问状态，或者出现异常的 IP 地址，这表明凭据已被泄露。