关于状态锁定和“http”后端的几个问题

Question

我是 Terraform 新手，想问几个与状态锁定相关的问题。我正在阅读“http”后端文档（https://developer.hashicorp.com/terraform/language/settings/backends/http#unlock_method）并有几个问题。

1. 首先，我不清楚lock_address和unlock_address端点的目的是什么？我是否正确理解，当向 lock_address 端点发出请求时，状态被锁定，并且在对状态应用更改后，需要向unlock_address 发出请求以解锁状态？

2. 其次，存在lock_method和unlock_method参数，这些方法默认为LOCK和UNLOCK。这些方法是请求锁定和解锁地址时的HTTP请求方法吗？为什么它们不是来自传统的 HTTP 请求方法（如 GET、PUT、POST、DELETE 等）？

3. 如果lock_address和unlock_address用于状态锁定和解锁，那么只要unlock_address端点未被调用，状态就会保持锁定状态？

Answer 1

与其他后端相比，“http”后端很不寻常，因为它自己的意见很少，而是尝试灵活地能够与各种不同的服务器实现一起工作。

为了充分了解它如何与指定的 URL 和方法交互，您可能希望参考 后端的远程状态客户端实现，其中显示了 Terraform 的每个状态管理器操作如何与后端配置相关。

与您的问题相关的一些要点：

• 当Terraform想要锁定状态时，客户端使用lock方法向锁定URL发送请求。

  例如，如果您将锁定方法配置为

  LOCK

  （默认），锁定 URL 为

  https://example.com/

  ，则客户端将向 HTTPS 服务器发送

  LOCK /

  请求以获取

  example.com

  。

• 类似地，当 Terraform 想要稍后解锁状态时客户端使用解锁设置执行类似的请求。

  例如，如果您将锁定方法配置为

  UNLOCK

  （默认），锁定 URL 为

  https://example.com/

  ，则客户端将向 HTTPS 服务器发送

  UNLOCK /

  请求以获取

  example.com

  。

Terraform 在发出这些请求时期望的行为是服务器会记住已经有锁定请求但尚未有解锁请求。如果另一个客户端在该情况下发出锁定请求，则服务器必须以错误响应第二个锁定请求。

返回此类错误时，后端客户端期望响应错误代码为 409 Conflict 或 423 Locked，客户端将其视为这种情况的同义词。

---

后端为锁定所做的默认方法名称和错误响应假设旨在与RFC 4918：Web 分布式创作和版本控制 (WebDAV) 的 HTTP 扩展兼容，尽管这不是该标准的完整客户端实现，相反，只是借用与锁定相关的子集，以避免指定完全自定义的 Terraform 内容。

但是，后端允许您重新配置锁定和解锁方法，以便您可以根据需要使用其他约定。例如，您可以选择将

lock_method

和

unlock_method

都设置为

POST

并使用不同的 URL 来区分它们（如果这更适合您用来实现服务器的技术）。

423 Locked

响应状态也是 WebDAV 规范的一部分，因此 Terraform 还支持仅基于 HTTP 的

409 Conflict

作为同义词，以支持实现不使用任何 WebDAV 扩展的服务器。