当我们尝试通过远程状态处理运行terraform脚本时,出现以下问题, 错误刷新状态:S3中的状态数据没有预期的内容。 这可能是由于S3处理先前状态时异常长的延迟引起的 更新。请等待一两分钟,然后重试。如果这个问题 持续存在,并且S3和DynamoDB均未发生中断,您可能需要 手动验证远程状态并更新存储在 DynamoDB表更改为以下值:
答案 0 :(得分:1)
有3种可能的解决方法,具体取决于您的具体情况以解决该问题:
如果您具有AWS S3 terrform.tfstate
文件的备份,则可以将状态后端"s3" {key = "path/to/terraform.tfstate"}
恢复到旧版本。重新尝试terraform init
并验证其是否运作良好。
移除AWS DynamoDB表中的不同步条目。该表中将包含一个LockID
条目,其中包含您应删除的状态和预期校验和,并在重新运行make init
之后将重新生成。
重要注意事项:
terraform refresh
命令(https://www.terraform.io/docs/commands/refresh.html),该命令用于协调Terraform知道的状态(通过其状态文件)与实际基础结构。可以用来检测自最后一个已知状态的任何漂移,并更新状态文件。如果在terraform destroy
之后您手动删除了AWS S3 terraform.tfstate
文件,然后可能试图启动所有tfstate声明的资源的新实例,这意味着您从头开始工作,那么您只需将您的AWS S3 terrform.tfstate
状态后端密钥"s3" {key = "path/to/terraform.tfstate"}
更新为新的"s3" {key = "new-path/to/terraform.tfstate"}
。重新尝试terraform init
并验证它是否可以正常工作。该解决方法的局限性在于您尚未真正解决根本原因,只是使用S3 tfstate的新密钥绕过了问题。
答案 1 :(得分:1)
今天遇到了同样的问题,但尽管 Exequiel Barrierero 提出了很好的建议,但没有明显错误 - 直到我发现它。
在我们的例子中,我们有一个较旧的 Terragrunt 堆栈 (v0.23.30 / terraform v0.12.31),并且 CloudWatch 的一个组件模块抛出了同样的错误:
<块引用>错误:S3 中的状态数据没有预期的内容。
这可能是由于 S3 处理 a 之前的状态更新。请等待一两分钟,然后重试。 如果此问题仍然存在,并且 S3 和 DynamoDB 均未遇到 中断,您可能需要手动验证远程状态并更新 将存储在 DynamoDB 表中的 Digest 值改为以下值:
... 没有提供实际的 Digest 值。然而,我最近重构了我们的一些组件模块文件以降低我们堆栈的复杂性,并发现一个不再存在的元素的悬空 data.terraform_remote_state
- 我合并了模块并且没有不再是该特定数据元素的远程状态。
一旦我删除了无效的 data.terraform_remote_state
引用,plan
和 apply
都完成了,没有任何故障或错误。
答案 2 :(得分:0)
当我尝试从新机器执行“terraform init”时发生了这种情况。
所以我删除了 DynamoDB 锁并尝试了该线程中的大部分内容,但没有成功。 删除锁时的一个重点是,我在那里看到了多条记录,并记得我们也在使用 terraform 工作区。所以当我在新机器中创建并切换到正确的工作区时,问题得到了解决。
我想这背后的原因是我的 terraform 文件具有与运行 init 命令时默认工作区的 S3 上的状态不同的资源。所以我切换到新资源:
terraform workspace new'dev'
(or)
terraform workspace select 'dev'
(and then)
terraform init
在那之后,一切又顺利了。
答案 3 :(得分:0)
您也可以尝试从 dynamodb 中删除 -md5 项
答案 4 :(得分:-2)
问题出在terraform状态文件上。当您使用s3作为后端进行远程状态处理时,我们会收到此错误,因为s3文件位置和dynamodb记录不匹配 请尝试以下步骤。
1)删除该特定状态条目的dyanmodb记录。 2)删除s3位置中的状态文件。 3)现在从头开始初始化并应用Terraform。
这将在dynamodb中创建一个新的状态信息条目,并在s3中添加新的状态文件,从而解决了问题。
快乐的编码...