请注意,这是一个关于自定义构建提供程序如何处理错误流的可能性的设计问题。无论这种流程是否良好......这是另一个问题。
假设有2个资源(A& B),其中B依赖于A.
当我运行terraform apply时,会创建资源A(意味着后端创建了一个带有ID的对象),但在创建任务之后处于错误(错误)状态。我想构建的是一个能够识别这种不良状态的提供者,并在它继续尝试创建资源B之前就停在那里。但是,我也想要一种让Terraform能够清理的方法。处于错误状态的资源(通过破坏或污染),甚至在我手动修复后端问题后不再重新创建它。
也许还有其他流动的可能性,但这里有两个我能想到的:
由于后端给了我们一个ID,我们也在Terraform资源中设置了ID,但是从Create方法返回时出错了。但是,我不确定Terraform接下来会做什么。它可以:
一个。继续尝试创建资源B,因为A有ID(不需要)
B中。拒绝尝试创建资源B,因为从创建A(所需)
返回了错误据我所知,Terraform的默认行为似乎是做选项A(如果我错了,请纠正我)。 我可以让它做选项B吗?
另一个选项是不设置Terraform ID,即使后端有一个对象,但确实有ID。好消息是Terraform不会转向资源B,但重要的是资源A实际上变成了孤儿;它存在于后端,但是Terraform无法清理它。
我猜这不是一个独特的用例,但没有任何运气找出基于文档的解决方案。任何指导都将非常感谢!
答案 0 :(得分:2)
我想构建的是能够识别这种不良状态的提供者,并在继续尝试创建资源B之前停止。
这是HashiCorp,供应商和社区维护的大多数(如果不是全部)提供商的工作方式。
资源ID的存在(或缺少)在错误处理方面没有任何区别。
即使资源处于挂起/失败状态,资源也必须具有ID。资源代码应始终尽可能地设置ID(通常在API首次成功响应之后,之前任何重试逻辑)。资源实际上与其ID一起生存和死亡。删除其ID意味着从状态中删除资源,并且只有在资源实际消失时才会发生(例如,API返回404)。
Terraform将始终尽力在任何apply
或destroy
操作期间获取。它将遍历配置中所有资源的图表,如果发生错误(即从C / R / U / D方法返回),它将继续创建/更新/销毁那些未受影响的资源 < / strong>错误 - 基本上所有资源都不依赖于失败的资源。您可以通过terraform graph
检查Terraform做出决策的完整依赖关系图。
例如,如果您aws_s3_bucket_object
依赖depends_on
(通过插值语法或通过aws_s3_bucket
),aws_s3_bucket
的创建/更新/销毁因任何原因失败那么aws_s3_bucket_object
将保持不变。
但是,我还想要Terraform能够在糟糕的状态下清理资源(通过破坏或污染),甚至可以在我修复问题后继续前进而不重新创建它后端手动。
在发生故障的情况下,或多或少地执行任何自动回滚(例如在&#34;失败&#34;状态中销毁资源)的设计选择不。有许多方法可以使任何操作失败,并且根据上下文对最佳回滚策略的看法有所不同,因此Terraform故意将其留给操作员/用户。
然而,污染是一个不同的故事,因为它不会直接影响资源,仍然会对用户做出最终决定。
当前无法从CRUD /架构界面自动taint
资源,但至少one Github issue讨论了这个想法。
可能相关:有时资源操作需要多次API调用,其中任何一项都可能失败。 Terraform有一个名为&#34; Partial State&#34;解决https://www.terraform.io/docs/plugins/provider.html#resource-data
中描述的部分失败问题基本上,它总是确保在返回错误之前存储部分状态。