超越编排：IaC策略的全面方法

为了真正发挥 IaC 的力量，组织需要超越工具选择和编排，关注一些至关重要的但经常被忽视的方面。

译自 Beyond Orchestration: A Comprehensive Approach to IaC Strategy，作者 Eran Bibi。

在过去十年中，随着云（原生）技术的广泛采用，基础设施即代码 (IaC) 成为实现前所未有的增长和管理极其复杂系统的核心。然而，与其他领域一样，IaC 领域也经历了相当大的变化。

仅今年一年，HashiCorp 就用更严格的许可证取代了其开源的 Terraform 许可证，社区也对此最普遍的工具进行了分叉。（我最近在 KubeCon 巴黎的一个小组讨论中谈到了这个问题，名为“IaC 的演变：关于开源和其他一切”。）

这使得我们，作为平台工程师和 DevOps 专业人员，在制定 IaC 策略时面临着两个主要难题：

1. 我们应该使用哪种 IaC 工具？Terraform、OpenTofu、云特定解决方案，例如 AWSCloudFormation 或 Kubernetes 控制器，例如 Crossplane？
2. 我们应该如何处理编排？我们应该在我们的 CI/CD 工具中构建自己的 IaC 配置管道，还是投资于 IaC 自动化产品，例如 Terraform Cloud？

虽然这些问题无疑至关重要，但它们只是全面 IaC 策略应该包含的内容的皮毛。随着 IaC 现在成为我们交付软件及其运行的关键系统的方式的支柱——CrowdStrike 停机 只是其中一个例子，说明了这可能会出错——我们的 IaC 策略将直接影响我们的业务运营。为了真正发挥 IaC 的力量，组织需要超越工具选择和编排。这些实际上只是实现细节。让我们探讨一下那些经常被忽视的方面，这些方面可能会成败您的 IaC 操作和系统工程。

IaC 覆盖率代表通过 IaC 管理的云资源的百分比。这一关键指标提供了对云基础设施管理的健康状况和成熟度的洞察。

为什么 IaC 覆盖率如此重要？

• 它表明您的基础设施中有多少是持续管理和版本控制的。
• 它有助于识别潜在风险区域（未管理的资源不符合 DR 标准）。
• 它作为云治理持续改进的基准。

尽管它很重要，但大多数云提供商都没有提供对该指标的可见性。如果您不了解您的 IaC 覆盖率，您基本上就是在云管理工作中盲目行动。

我们多年来编写基础设施代码的经验表明，所有这些因素结合在一起，通过更好的护栏、治理和可维护性，随着时间的推移，可以提高系统健康状况和稳定性。当系统没有被编码时——这在很大程度上导致了下一条——这有时是旧系统和遗留系统的副产品，很难可视化、管理和维护系统，甚至从故障中恢复。

Lambda 今年将迎来 10 周年纪念，所以我们不要谈论 Amazon Elastic Compute Cloud (EC2)，它将在 2026 年迎来 20 周年纪念。对于现在进入该行业的年轻工程师来说，云已经存在了很长时间——云之前没有时间。然而，对于更有经验的工程师来说，我们知道之前发生了什么（而且并不漂亮）。

我们发现，在采用 IaC 时，组织通常专注于新部署，而忽略了现有基础设施——一些预云或早期云时代，当时所有内容都是通过控制台管理的。这种疏忽会导致混合状态，其中一些资源通过 IaC 管理，而另一些资源仍然是“ClickOps”控制台创建（不受 IaC 管理，并且没有获得上面提到的 IaC 的好处）。

ClickOps 挑战在于：

• 识别哪些资源目前不受 IaC 管理
• 确定将这些现有资源“编码”所需的努力
• 优先考虑哪些资源首先要纳入 IaC 管理

如果没有针对现有资源的策略，组织就有可能延续分裂的基础设施，从而削弱 IaC 采用的优势。此外，我们都了解到，有时我们最传统的系统是我们的业务“摇钱树”和关键任务系统。这不仅仅是让它们保持未编码和未管理的问题。这些通常是当它们出现故障时会造成最大伤害，并且在没有快速恢复时会造成最大痛苦的主要系统。

在大型组织中，在所有部门强制执行单一的 IaC 工具通常是不切实际的。如今，有各种各样的工具可以满足不同的堆栈、优势和与开发人员的协作——从特定平台的原生工具（CloudFormation 或 Azure 的 ARM），到多云或云原生工具，从 Terraform 和 OpenTofu，到 Helm 和 Crossplane，以及针对开发人员的工具，如 Pulumi 或 AWS Cloud Development Kit (CDK)。不同的团队可能会根据其专业知识、用例或特定项目需求偏好不同的工具。

强大的 IaC 策略必须考虑：

• 组织内多个 IaC 工具的共存
• 跨各种 IaC 实现的可见性
• 跨不同 IaC 生态系统的治理和合规性

忽略这种多 IaC 现实会导致孤岛、可见性降低和治理挑战。就像今天许多团队根据从性能到复杂性、开销维护等各种标准选择其云、编程语言和堆栈一样，IaC 也是如此。由于不同的工具针对不同的堆栈和用例进行了优化，因此了解如何在这一领域管理众多工具是强大 IaC 策略的一部分。

作为 DevOps 和平台工程师，我们开发了一个平台，我们在多年来管理大规模云集群时自己也需要这个平台。一个不仅解决工具和编排，而且解决全面 IaC 策略所有方面的平台，可以决定是凌晨 2 点的停机时间还是一夜好眠。

这样一个单一平台可以改变工程团队对 IaC 的方法，并随着不断变化的云环境而发展：

• 完全可见性——自动发现您所有多云帐户中的所有资产，在一个仪表板中提供已管理和未管理资源的清晰清单，无论您的资源和资产运行在哪个云中。
• IaC 覆盖率洞察——提供有关您的 IaC 覆盖率的实时指标，帮助您了解哪些资源由 IaC 管理，哪些资源没有管理，以及风险严重程度，从而帮助优化对关键资源和资产编码的规划。
• 多 IaC 支持——识别并支持各种 IaC 工具，无论使用哪种 IaC 解决方案，都能为您提供基础设施的统一视图。这样，工具选择就与管理和维护分离，团队能够为工作负载选择合适的工具。
• 自动编码（例如反向 IaC）——可以自动将现有资源“编码”到您首选的 IaC 格式，从而显着减少将传统资源纳入 IaC 管理和在 IaC 工具之间迁移所需的手动工作量。
• 漂移检测——识别与 IaC 定义状态不符的资源，帮助维护一致性和安全性。漂移是大型系统中日益严重的问题，在这些系统中，云资产仍然通过控制台和 ClickOps 进行更改。
• 治理和合规性——确保所有资源，无论其创建方式如何，都符合您组织的标准，而不会妨碍实时事件响应。
• 编排及更多——除了强大的编排之外，它还提供了一套全面的工具，用于管理您的整个 IaC 生命周期。

随着云变得越来越复杂和发展，我们管理它的方法也必须随之发展。通过超越工具选择和编排，并确保您的 IaC 策略侧重于包括 IaC 覆盖率、传统资源管理和多 IaC 支持在内的其他关键方面，组织可以释放其云基础设施的全部潜力。