使用 Terraform 优化 CDN 管理

使用 Terraform 优化 CDN 管理

在不断发展的技术世界中，通过用户界面手动管理基础设施就像是试图用蜡烛点亮一座现代化的城市。您需要的是一个能够自动化、适应和随着您的需求而发展的高性能引擎。这就是 Terraform 的作用所在。它是一种基础设施即代码工具，是现代 DevOps 实践的基石。特别有趣的是它最近的许可动荡，这给开源社区带来了重大影响。让我们剖析一下 Terraform 的运作原理，了解它的历史背景，并深入了解它的优点和局限性。

什么是 Terraform？

‍

在深入了解 Terraform 之前，让我们先从一个真实示例开始，了解 Terraform 代码的外观和工作原理：

‍

# 来自已知 Tor 出口节点的挑战请求。

在上面的示例中，我们使用 Terraform 在 Cloudflare 上设置访问规则。此规则会质询来自已知 Tor 出口节点的请求。代码是声明性的，这意味着您可以指定最终配置的样子，Terraform 会确保基础设施与所需状态相匹配。

‍

那么，Terraform 到底是什么？

‍

Terraform 是我们处理基础设施方式的一次革命。它使 DevOps 团队能够以简化的方式管理、配置和自动化基础设施。它不仅限于 AWS 和 Azure 等云资源；Terraform 用途广泛，将其功能扩展到内容交付网络 (CDN) 管理等关键性能领域，确保高效的内容交付和最佳的用户体验。

‍

Terraform 几年前成立时专注于云管理，并围绕其开源许可证建立了一个庞大的社区——直到两周前才开始，但后来情况有所好转。该社区甚至开发了大量插件来管理各种工具和服务；这包括对 Cloudflare、Fastly、Akamai 等 CDN 的全面管理，使企业能够无缝集成和自动化其内容交付机制。

背景

‍

通过代码管理基础设施的想法并非由 HashiCorp 发起。事实上，亚马逊网络服务 (AWS) 通过其服务 CloudFormation 开辟了道路，该服务引入了基础设施即代码 (IaC) 的概念。CloudFormation 允许用户利用代码以自动化和一致的方式定义和配置 AWS 基础设施资源。

‍

然而，在 AWS 提供基础的地方，Terraform 背后的公司 HashiCorp 建立了一个帝国。从 AWS 的 CloudFormation 中汲取灵感，HashiCorp 以更广阔的视野推出了 Terraform。

‍

与仅限于 AWS 资源的 CloudFormation 不同，Terraform 的设计考虑了多云方法。这意味着使用 Terraform，您可以使用单一工具管理多个云提供商（包括 AWS、Azure、Google Cloud 等）的资源。

‍

Terraform 崛起的一个重要因素是其开源性质。作为开源软件，Terraform 吸引了大量开发者和公司加入。这导致了大量插件的创建，使 Terraform 能够与云提供商以外的各种工具和服务进行交互。一个典型的例子是 Cloudflare Terraform 插件，它允许用户使用 Terraform 管理 Cloudflare 配置。

‍

大大小小的公司都利用 Terraform 的开源灵活性来开发适合其特定需求的插件，从而进一步扩展了 Terraform 的功能。以 Cloudflare 为例；他们有一项名为Cloudflare Terraform 的完整服务。

‍

如今，由于其适应性、多功能性和强大的社区支持，Terraform 已成为通过代码进行基础设施管理的行业标准。

为什么要通过代码管理基础设施？

如果您仍在努力应对麻烦的 UI 界面或在多个仪表板之间切换以管理您的基础设施，那么现在是时候加入 IaC 革命了。

‍

版本控制

首先，让我们谈谈版本控制，这是采用 IaC 可以获得的一个重要方面。您可以将基础设施管理集成到 Git 存储库中，从而更轻松地跟踪谁做了什么、何时做以及为什么做。这不仅提供了审计培训，而且还提供了“强化版审计线索”。

‍

一个简单的“ git blame ”就可以让你直接找到做出特定更改的个人。

实时监控和异常检测

在 IaC 范式中，代码变更往往会触发自动重新部署。实时监控可以帮助在异常发生时立即检测到，从而提高诊断和解决问题的速度。

‍

它消除了检查日志和监控仪表板的手动过程，让您的团队有更多时间专注于创造价值。

‍

问责制和透明度

接下来是“谁干的”因素。使用代码，您可以轻松识别谁做了特定的更改，而不像 UI，这些更改通常被埋在日志中，直到出现问题，才会有人真正检查。

‍

通过 GitHub 等平台，您可以追踪代码更改的具体行数及其背后的人员。这种精细度在 UI 管理系统中是找不到的。

‍

自动化

基于代码的系统在自动化方面也大放异彩。当您编纂基础设施时，您可以将其与 DevOps 管道集成，以自动执行各种任务，如服务器配置、数据库扩展和安全审计。如果通过 UI 尝试，同样的自动化将更加困难且容易出错。

‍

合作

基础设施即代码 (IaC) 不仅仅是一种自动化工具，它还是协作的催化剂。随着整个基础设施的编码，包括 DevOps 和 DevSecOps 在内的专业团队可以以增强的协同作用开展工作。这种动态对于组织行为尤其具有变革性。

在传统设置中，安全和运营等团队通常以孤立方式运作。

‍

有了 IaC，这些传统上截然不同的团队就不得不更加紧密地整合在一起。其中一个主要原因是共享的工作流程。与任何软件代码一样，基础设施代码也可以通过协作的方式进行审查、讨论和修改。

‍

此次合作的一个关键方面是工作流程。例如，DevOps 团队可以设置一个工作流程来审查 SecOps 推送的代码。可以将此工作流程配置为根据预定义的标准自动阻止或允许更改，从而确保安全配置符合运营要求。

‍

该工作流程不仅简化了流程，而且还确保任何更改都符合组织的最佳实践和合规标准。

‍

使用 Terraform 的优势

‍

从其与小丑无关的方法到其模块化架构，Terraform 不仅充当了您基础设施的骨干，而且还以一种尊重现代云基础设施复杂性的方式实现了这一目标。

‍

1.可扩展性

Terraform 的突出特点之一是其固有的轻松扩展资源的能力。随着业务的增长和需求的波动，基础设施需要适应。Terraform 的声明性特性使这种适应变得简单。

‍

假设一家公司在云提供商上运行多个虚拟机 (VM)。如果最初的需求是 5 个 VM 实例，而需求突然增加，则调整基础设施以满足这一需求就像修改 Terraform 清单中的单个变量一样简单。

在上面的代码片段中，虚拟机实例的数量由 instance_count 变量控制。要从 5 台机器扩展到 10 台机器，只需将此变量的默认值从 5 调整为 10，然后重新运行 Terraform apply 命令。

‍

除了 VM 实例之外，这种可扩展性还扩展到基础架构的其他方面。无论您是扩展存储解决方案（如 S3 存储桶）、计算资源（如 EKS 集群）还是通过 CDN 的内容交付机制，Terraform 都提供了一种简化的方法。

‍

企业可以同样轻松地调整配置来管理一切，从基本分发设置到复杂的地理定位内容缓存和交付策略。

‍

‍

2.易于维护

当我们说“易于维护”时，这并不是一个模糊的承诺。使用 Terraform，您可以将代码划分为模块，从而获得更清晰、更易于理解的代码库。

‍

假设您的前端和后端资源被分割成两个不同的模块。如果前端需要升级，只需修改相应的模块并执行 Terraform 的“ apply ”命令，后端则保持不变但仍处于版本控制之下。

‍

3. 增强控制和可读性

使用典型的 GUI，用户经常会发现自己在迷宫般的复选框和表单字段中导航。虽然这些图形界面可能很直观，但它们通常缺乏对整个配置的全面视图。人们对通过一系列点击应用的精确设置有多大信心？

‍

另一方面，Terraform 则呈现出鲜明的对比。它的配置文件详细列出了资源的每个属性。这些文件不仅用作配置，还充当清单——即基础设施的清晰、简洁的蓝图。它是封装整个设置的声明。

‍

Terraform 方法的优势在于其可读性。借助 Terraform，用户可以轻松地在一个地方概览其整个配置。

‍

无需浏览多个选项卡或屏幕。每个设置和每个资源属性都以结构化格式布局。这确保任何人（无论是经验丰富的开发人员还是新手）都可以一目了然地阅读、查看和了解基础架构。

‍

‍

4.冗余

冗余就是拥有一个自动化、可复制的备份。您编写的 Terraform 脚本不仅可以用作文档，还可以用作灾难恢复计划。

‍

如果您的某个基础设施部分出现故障，您只需参考版本控制的配置并在几分钟内恢复丢失的资源。

‍

对于 CDN 来说，冗余非常重要。如果某个接入点 (PoP) 出现故障，企业需要立即恢复。借助 Terraform 的脚本化基础设施，企业可以确保其内容始终可用，并在必要时快速重新路由流量。

‍

此外，作为持续部署 (CD) 流程的一部分，始终会进行代码审查以查看确切的变化，从而有助于跟踪和减轻故障。

‍

‍

缺点和局限性

‍

Terraform 在基础设施即代码 (IaC) 领域非常重要，但与任何工具一样，它也有缺点。

‍

无需多言，以下是您需要了解的内容：

‍

提供者依赖性

Terraform 依赖于提供商，提供商本质上是允许您管理特定服务的插件，例如 AWS、Azure 甚至非云服务（如 GitHub）。

‍

但问题在于：如果提供商缺乏某些功能，您就会束手无策。想象一下，您制造了一辆高科技汽车，但只能使用基本引擎。它可能会完成工作，但您却错失了潜在的马力。

‍

在这种情况下，所有 Terraform 功能都未准备好 API，这意味着如果您选择利用这项技术，您将只能使用有限的工具。

‍

复杂性和学习曲线

虽然 Terraform 非常灵活和强大，但它要求您学习它的语言 HCL（HashiCorp 配置语言）。

‍

如果您以前使用过 JSON 或 YAML，那么一开始这可能会让您感到陌生。语法并不是唯一的障碍；概念本身对于新手来说可能很复杂。

迁徙的噩梦

您可能会认为，如果您使用 Terraform 在 AWS 中设置了基础架构，那么迁移到 Azure 将是小菜一碟。请记住这一点。不同的提供商有不同的插件和配置。迁移并不像“复制粘贴”那么简单。

‍

即使在同一个云提供商内，比如说，从 EC2 实例迁移到 AWS 中的 Lambda 函数，也可能迫使您重写整个代码库，或者使用 Terraform 从一个 CDN/云迁移到另一个 CDN/云可能需要长达一年的时间。

‍

在 CDN 提供商之间转换甚至更改 CDN 配置都可能很棘手。虽然 Terraform 提供了一定程度的抽象，但 CDN 处理缓存、失效和路由的方式存在固有差异，可能需要进行大量重新配置。

Terraform 是一个标准

Terraform 在基础设施领域的突出表现并非偶然。我们已经进入了一个高效、快速的基础设施部署比以往任何时候都更为重要的时代。在这个快节奏的时代，以编程方式、可靠且一致地管理基础设施的能力不可或缺。

‍

Terraform 的出现标志着一个新时代的开始。其基础设施即代码 (IaC) 方法以以前不可能的方式简化了基础设施管理。想想看：基础设施曾经是一项主要依靠手动且耗时的事务，现在可以像编写和部署代码一样轻松处理。

‍

但这如何应用于 CDN？内容分发网络的工作是在全球范围内以快速、高效和可靠的方式分发内容。为了实现这一点，需要有一层底层基础设施，需要不断配置、监控和扩展。这就是 Terraform 的闪光点。

‍

‍

优化基础设施

集成和 API 支持： Terraform 在该领域的权威性体现在它的通用 API 支持上。很难找到没有 Terraform 集成的知名 CDN 或任何基础设施工具。

‍

这里的逻辑很明确：要让一个工具在基础设施领域受到尊重并保持竞争力，它必须与 Terraform 配合良好。该工具广泛的提供商支持确保集成顺畅且多功能，使我们能够通过其 API 与各种 CDN 进行通信并以编程方式管理它们。

‍

专业 DevOps 的选择：现在，假设您是一名 DevOps 专业人员。您的职责涉及管理支持 CDN 的复杂基础架构。您想处理无休止的 UI 配置，还是更喜欢编写无缝部署和扩展基础架构的代码？

‍

当然是后者。这正是你今天遇到的任何 DevOps 专家都会对 Terraform 深信不疑的原因。它不仅赋予他们管理基础设施的能力，而且还确保他们的 CDN 配置是最佳、安全和可扩展的。

‍

Terraform 中的常见做法

‍

想象一下：我们公司有两个专家团队——DevOps 团队和 DevSecOps 团队。

‍

1. DevOps 团队：这些人是公司基础设施的骨干。他们的专长在于确保一切顺利运行，从服务器到网络。他们就像摩天大楼的建筑师和建造者，确保摩天大楼稳定、实用，并能经受住任何挑战。

‍

2. DevSecOps 团队：这些专家专注于安全服务 - 比如 Web 应用程序防火墙 (WAF)、速率限制（防止系统因过多请求而超负荷）和机器人检测（抵御恶意自动攻击）。如果 DevOps 团队建造摩天大楼，那么 DevSecOps 团队则确保其防盗和防火。

‍

现在，问题来了：尽管 DevSecOps 团队负责安全，但他们却不能随心所欲地做出任何改变。为什么？因为整个基础设施的责任都在 DevOps 团队身上。他们掌握着万能钥匙。任何调整，尤其是与安全相关的关键调整，都需要进行交叉验证，以确保它们不会无意中导致其他问题。

‍

那么，如果 DevSecOps 团队认为需要进行更改，会发生什么？他们不能直接应用它。相反，他们会起草拟议的变更，并将代码推送到名为 GitHub 的平台。可以将此视为提交提案或计划以供审查。

‍

然后，DevOps 团队在 GitHub 上审查这个“计划”。他们会彻底检查，确保它与所有其他现有系统一致，不会造成任何问题。只有得到他们的批准，这些更改才能实施。

‍

‍

两周前发生了什么？

‍

本月初，HashiCorp 发布了一项令许多人感到意外的声明。他们宣布决定更改 Terraform 的开源许可证。

‍

此次转变并非只是一次小小的许可变更，而是从著名的开源许可证 Mozilla 公共许可证 v2.0 (MLP 2.0) 转变为商业源代码许可证 (BSL) v1.1。现在，对于不熟悉的人来说，BSL 是一种“源代码可用”许可证，但传统上并不被视为开源许可证。

‍

这意味着虽然源代码可供查看，但它带有某些限制，不符合正统的开源理念。

‍

‍

开源社区的反应

该声明刚刚在公共论坛上发布，开源社区就陷入了讨论、辩论，不幸的是，还有不和的旋风中。

‍

Terraform 凭借其传统和庞大的用户群，多年来培育了一个强大的社区，许多人认为许可证的改变是一种背叛。

‍

这不仅仅是代码可访问性的变化；这关乎信任。鉴于 Terraform 在开源领域的地位，这一声明让许多人对其他 HashiCorp 产品的未来产生了疑问。他们会效仿吗？这种怀疑并非毫无根据；毕竟，在科技界，一个举动可以开创先例。

‍

OpenTF——一个新的分支

几天之内，异议开始出现。到周五，来自原 Terraform 社区的一个分支开始行动。他们宣布打算开发 Terraform 的开源分支，并启动了 OpenTF 项目。

‍

OpenTF 不是一款产品，而是一种声明。它代表了开源原则，并证明了社区的韧性。它旨在在 Linux 基金会真正的开源保护伞下发扬 Terraform 的开源性质。

‍

‍

结论

‍

对于像 HashiCorp 这样的公司来说，开源是一把双刃剑。虽然它促进了社区和协作，但它往往不会转化为收入，尤其是当大型云提供商采用代码并将其商业化时。

‍

然而，对 HashiCorp 决定的回应表明，商业战略与社区期望之间存在着巨大的差距。只有时间才能告诉我们 Terraform 的未来是否能找到一个让两者满意的中间立场。

‍