基础设施即代码 (IaC) 是一种管理和预配计算基础设施的方法。它依靠机器可读的定义文件进行配置,而不是手动调整物理硬件或使用互动式配置工具。通过像开发者处理应用代码一样处理基础设施设置,团队可以快速可靠地自动部署网络、虚拟机、Kubernetes 集群、数据库和负载均衡器。它是现代 DevOps 实践的一个组成部分,有助于组织以一致的速度进行扩缩。
IaC 通过代码自动执行预配流程,无需在云控制台中进行手动设置。首先,开发者在配置文件中定义所需的基础设施规范,这些文件通常存储在版本控制系统中。然后,自动化工具(例如 Terraform)会处理这些文件,并向云服务提供商发出必要的 API 调用,以创建、更新或删除实际资源。此工作流通常遵循从代码(定义)到版本控制,再到 CI/CD 流水线,最后到预配的路径。

在实施 IaC 时,团队通常会在以下两种方法之间选择:声明式方法和命令式方法。主要区别在于,您是关注最终结果,还是关注实现结果的步骤。
方法 | 说明 | 示例 |
声明式 | 您需要定义最终状态。该工具会确定实现该状态所需的步骤。这是 Terraform 和 Kubernetes 等工具的现代标准。 | “我想要 3 个虚拟机,每个虚拟机有 8GB RAM。” |
祈使语气 | 您可以通过列出要按顺序执行的特定命令或脚本,来定义如何更改基础设施。 | “运行脚本 A 以启动服务器 1。接着运行脚本 B 来配置网络。然后运行脚本 C…" |
方法
说明
示例
声明式
您需要定义最终状态。该工具会确定实现该状态所需的步骤。这是 Terraform 和 Kubernetes 等工具的现代标准。
“我想要 3 个虚拟机,每个虚拟机有 8GB RAM。”
祈使语气
您可以通过列出要按顺序执行的特定命令或脚本,来定义如何更改基础设施。
“运行脚本 A 以启动服务器 1。接着运行脚本 B 来配置网络。然后运行脚本 C…"
除了支持检索增强生成 (RAG) 应用等常见部署模式外,IaC 还有助于解决复杂运营部署面临的挑战。
企业通常需要在不同环境中运行工作负载。借助 Terraform 等工具,团队可以使用单一配置工作流,同时在 Google Cloud 或其他云环境以及本地数据中心内部署和管理资源。这样降低了学习每个平台不同专有工具的复杂性。
开发者经常需要安全的地方来测试新功能。借助 IaC,团队可以启动一个与生产环境完全相同的临时“预演”环境,运行测试,然后在测试完成后立即销毁该环境。这有助于确保测试的准确性,同时避免了全天候运行永久性预演服务器的成本。
如果发生灾难性区域中断,手动恢复可能需要数天时间。IaC 支持“灾难恢复即代码”,使组织能够使用现有的代码定义,在不同区域快速重新预配整个基础设施。这可以大幅减少停机时间并确保业务连续性。
对于希望实现 IT 运维现代化的组织,采用 IaC 可以带来显著优势。
速度
借助自动化,您可以在几分钟内(而不是几天或几周)部署复杂的环境。
一致性
由于每次部署都会使用相同的代码来部署相同的环境,因此 IaC 可以消除“配置漂移”问题(服务器因手动临时更改而变得不一致)。
节约费用
团队可以在不需要时轻松关闭未使用的资源,例如在周末关闭开发环境,这有助于管理云支出。
版本控制
由于基础设施是以代码形式定义的,因此基础设施更改的整个历史记录都存储在一个位置。这样,您就可以更轻松地跟踪是谁更改了什么,并在出现问题时回滚到之前的版本。
Google Cloud 提供了一整套工具,可为您的基础设施即代码之旅提供支持,从初始设计到部署和持续管理,全程无忧。App Design Center 是一个很好的起点,您可以在其中探索、自定义和构建预构建的参考架构。这有助于您在编写任何代码之前,根据 Google Cloud 最佳实践设计应用堆栈,确保从一开始就构建出架构完善的基础设施。
有了设计方案后,Google Cloud 开放式生态系统可让您轻松地将设计方案实现为代码。该平台将 Terraform 等开源标准视为一等公民,而非事后补充。Infrastructure Manager 等服务可让您直接使用 Terraform 部署和管理 Google Cloud 资源,而 Config Connector 可让您通过 Kubernetes 管理 Google Cloud 资源,帮助弥合云基础设施与容器编排之间的差距。
Cloud Resource Manager 是一项服务,用于以编程方式管理 Google Cloud 资源层次结构,包括组织、文件夹和项目。虽然许多团队使用 IaC 来部署虚拟机等资源,但 Cloud Resource Manager 允许您将项目结构本身定义为代码。这有助于团队自动设置具有一致 Identity and Access Management (IAM) 政策和组织限制的新环境,确保从一开始就将治理融入到基础设施中。
IaC 最有价值的用途之一是解决开发者经常遇到的问题:“在我的机器上运行没问题,为什么在生产环境中就出错了?”您可以通过创建临时环境来解决这个问题。
在此工作流中,当开发者打开拉取请求 (PR) 时,IaC 工具会自动启动一个临时、隔离的应用副本。当 PR 合并后,环境会自行销毁。
为了实现这一点,您的 Terraform 代码不能有硬编码的名称。您必须使用变量为每个 PR 创建唯一的资源。
main.tf(代码段)
在 cloudbuild.yaml 中,您使用 Cloud Build 提供的 _PR_NUMBER 替换变量将 PR 编号注入 Terraform。
cloudbuild.yaml(代码段)
此工作流将 IaC 从静态维护任务转变为动态效率提升工具,可加快审核周期。