为什么配置漂移在实际操作中如此难避免？

我经常听说有关于配置漂移的情况，即实际状态与使用基础设施即代码（IaC）定义的理想状态出现偏离。正如我在一篇关于IaC工具中的状态的文章中提到的那样，这也是IaC的一个基本挑战。

基础设施即代码（IaC）通常指的是静态的，手写和编辑的

```(/generating-configuration-using-general-purpose-programming-languages-19230a2c2573)或代码形式的期望状态存储在版本控制系统中。IaC用户经常采用工厂模式通过单向流水线制作和部署变更。

模型是这些问题的源头：

• 变更和部署过程对于运营和紧急响应来说 太慢。
• 根据谁在应对事故，他们可能会因为配置分散而难以找到正确的IaC源文件。
• 表示方式复杂，且对其进行的变更手动且容易出错，因此，人们可能不愿意在危机中冒险尝试。
• 由于通常无法通过IaC进行精确的变更，因此变更的波及范围可能会引起担忧。
• 虽然直接对生产状态进行更改通常很简单，但将这些修改集成回IaC源代码通常难以自动化——我听说有时通过GUI、CLI或API快速进行的操作修改，手动将其合并到Helm或Terraform中可能需要数小时或数天。

自动漂移检测与修复，例如使用GitOps工具，并不能彻底解决漂移问题。我最近听说有一种常见的操作方式是禁用GitOps工具，以便直接进行操作更改以解决停机问题，然后需要有人记得手动重新启用这些工具来撤销更改。

许多通过API直接进行更改的自动化工具也面临相似的挑战，大多数这类工具都假设API是事实的源头。

• 部署工具：CI/CD 工具 可以通过直接调用 API 或 调用 CLI 来部署新镜像。
• 安全响应：例如，关闭不应开放的防火墙端口并将公共桶设置为私有。
• 成本优化：例如，删除未使用的资源，
• 云建议：这些可能与安全或成本相关，或与 性能、可管理性或可持续性 等因素有关。

当然，这些类型的改动也可能很危险，所以确实需要小心行事。我最近听说了一个组织里有人试图通过删除“未使用”的备份文件以降低成本，后来这些备份文件还是派上了用场。

除了直接调用API的各种工具，并且不假设专属激活之外，服务本身也可以直接修改资源属性。

典型的例子是水平自动扩展（例如：在 Kubernetes 中的自动调整）。例如，Kubernetes 中的自动伸缩器（例如：Horizontal Pod Autoscaler）会调整 replicas 字段（副本数字段）。如果声明性配置工具没有意识到该字段不应静态管理，就可能导致配置漂移。

我对 AWS 和 Azure 不太熟悉（虽然这听起来像是 Azure 中的一个问题 [1]），但在 GCP 中，许多服务会修改资源的输入属性。要么 Terraform 提供程序需意识到这一点并忽略这些属性的变更，要么用户需意识到这一点并指定忽略这些变更。我们起草了一个新的 API 设计规则（AIP 129），建议不要使用所谓的输入/输出字段，因为 Terraform 和一些其他工具不像 Kubernetes 那样处理事实来源的合并方式。

无论由于人类、自动化还是服务本身所做的任何更改，只要 IaC 模型的核心保持不变，漂移现象就不会消失不见。

你是否直接对生产环境进行操作，而不是通过IaC？如果是，为什么？你觉得这样更简单、更快或更安全吗？或者是因为你使用的工具就是这样设计的吗？你是否经常遇到其他人造成的配置漂移问题？这是否给你带来了严重的问题？你找到解决这个问题的方法了吗？你总是希望将这些变化恢复到生产状态吗？你会立即回滚，还是过一段时间再回滚？你是否希望将这些更改重新纳入IaC的源代码中？这通常需要多长时间来完成？

随时可以在这里回复，或者通过 LinkedIn、X/推特 或 Bluesky 私信我，在这些平台上我会转发相关内容。

如果你觉得这个内容有趣，你可能会对我的《基础设施即代码与声明式配置系列》中的其他帖子感兴趣。更多关于这个系列的内容可以在这里找到。