为什么通过 Terraform 销毁资源很糟糕？

为什么通过 Terraform 销毁资源很糟糕？
Why Does Destroying Resources via TF Suck?

原始链接: https://newsletter.masterpoint.io/p/why-does-destroying-resources-via-tf-suck

## Terraform 销毁资源可能很麻烦使用 Terraform（或任何 IaC 工具）删除云资源通常比创建它们更复杂。云环境会引入许多潜在的障碍——资源可能启用了删除保护，与其他资源链接，或正在积极处理数据。通常，这些“棘手的问题”最好通过云控制台进行一次性的手动操作处理。除非您的工作流程*需要*频繁销毁资源，否则通常不值得进行大量自动化。但是，如果您反复遇到特定资源的删除问题，请考虑自动化解决方案——例如在删除前清空存储桶，或在非生产环境中禁用删除保护（避免在生产环境中执行此操作！）。务必尽一切可能避免“误操作恢复灾难”（FRD）。最终，资源删除应该不频繁且快速。 **(附：作者正在寻找 DevOps 播客嘉宾，并愿意讨论 S3、ClickOps 或 FRD。)**

一个 Hacker News 的讨论集中在在使用 Terraform (TF) 进行基础设施即代码时遇到的挫折感，尤其是在*销毁*资源时。一个主要痛点是 Terraform 依赖于单个配置文件，通常存储在它管理的*内部*，这给团队带来同步挑战。用户质疑为什么云提供商不能为像 TF 这样的工具提供更好的 API，以便准确查询当前的基础设施状态。一位评论员澄清 Terraform *已经*通过 API 查询资源，暗示问题可能在于 API 质量，而不是 Terraform 本身存在根本缺陷。对话强调了 Terraform 感知到的状态、实际的基础设施状态以及 Terraform 代码本身之间的脱节，导致人们担心不可预测的“apply”操作和潜在的基础设施中断。一个建议的解决方案是手动创建后端存储，而另一些人则认为现有方法过于复杂。

原文

I had a new colleague ask a question which boiled down to "Why does destroying resource via TF suck?”

Destroying resources is just generally harder than creating them because the cloud can have lots of gotchas when determining "Is this resource okay to delete?".

is protected from deletion. AWS S3 buckets, databases, EC2 instances, and other types of resources can all have deletion protection configured.
is attached to other resources. Do you delete them, leave them dangling or ask the user?
is actively processing something that needs confirmation to stop.

Plenty of situations can block a destroy action.

Typically, unless you need to destroy that resource as a regular part of your workflow for some subset of infrastructure, which is not a common action, it's best to treat these painful interactions with the cloud and IaC as a one-off operation.

Accept the pain and handle it the best you can. That usually means doing some level of manual ClickOps delete action in the console or something similar.

That said, if you find yourself running into this problem over and over, then it can be useful to investigate that specific destroy operation and try to automate and optimize that process.

Maybe you need to have a process that empties your bucket before you attempt to destroy it. Maybe you need to stop adding items to a workstream, then wait for the processing to finish. Maybe you need to turn off deletion protection for your dev database instances. But don't do the same for your prod ones! Trust me, you want to avoid FRD.

Since this is not a common Day 2 operation I wouldn't worry too much about optimizing resource deletion. Only put effort into it if you're hitting your head against it again and again.

May your resource deletion be both seldom and fast,

PS Are you interested in being on a devops-focused podcast? Reply to me with the topic you want to discuss and I’m happy to intro you to the right podcast. Or, if you want to chat about S3 buckets, ClickOps or FRD, grab some time on my calendar here.

为什么通过 Terraform 销毁资源很糟糕？ Why Does Destroying Resources via TF Suck?

为什么通过 Terraform 销毁资源很糟糕？
Why Does Destroying Resources via TF Suck?