基础设施即代码：为业务应用自动化服务器与云环境

在许多公司里，服务器和云服务是以传统盖房子的方式搭建的：有人在控制台点几个菜单、敲几条命令、从旧笔记里抄一些设置，然后一切就运转起来了。只要那个人还在、记忆良好，就没有问题。但当他休假、跳槽，或服务器在事故后必须重建时，没有人确切知道那个环境当初是怎么搭起来的。测试环境悄悄地与生产环境不同，“在我电脑上是好的”成了熟悉的借口。

基础设施即代码（Infrastructure as Code，IaC）就是解决之道：基础设施被描述为存放在代码仓库中的文本文件，像应用代码一样被评审、测试，并由自动化工具执行。本文面向企业主和技术经理介绍这一概念：它的好处、何时值得使用、常见工具与实践、风险，以及如何在不干扰运营的前提下逐步开始。我们并不建议所有人都使用 IaC；对某些小企业来说，更简单的做法就足够了。

摘要

• IaC 把服务器、网络、数据库和云服务定义在可读、可评审、可重复运行的文件中
• 主要好处：环境可复现、变更有记录、恢复更快，以及开发、测试和生产之间的一致性
• 常见工具包括 Terraform 或 OpenTofu、Pulumi、云厂商原生模板，以及用于服务器配置的 Ansible
• 风险：学习曲线、可能批量删除资源的错误，以及机密泄露到代码仓库
• 从小处着手：一个环境、一个仓库、变更评审和安全的状态存储
• 对于托管平台上的简单网站，完整的 IaC 往往是过度投入

IaC 解决的问题

看看手动搭建基础设施时经常出现的症状：

• **雪花服务器**：由于累积的手动修改，每台服务器都是独一无二的，没人敢碰它或重建它
• **环境差异**：测试环境与生产环境不同，所以缺陷只在发布后才出现
• **知识只存在于一个人的脑中**：文档过时或根本不存在
• **变更无迹可寻**：谁修改了防火墙规则，何时，为什么？
• **恢复缓慢**：事故或数据中心故障后，重建需要数天
• **游离的成本**：为试验创建的资源被遗忘，持续产生费用

IaC 不会自动解决所有问题，但它提供了以软件开发同样的纪律来解决问题的基础。

两种方式：声明式与命令式

• **声明式**：你写下期望的最终状态（“有一个符合这些规格的数据库和一个带有这些规则的网络”），由工具计算达成该状态的步骤。Terraform、OpenTofu 和云厂商原生模板都是这样工作的。优点是重复运行同一文件会得到相同的状态（幂等）
• **命令式**：你写下要执行的命令序列。Shell 脚本属于此类。灵活，但更容易发生偏差，也更难保证每次结果相同

有些工具，如 Pulumi，使用通用编程语言来编写声明式定义。工具的选择应当基于团队技能，而不是潮流。

常见工具及其作用

资源供应：构建资源

Terraform 和 OpenTofu（开源分支）可跨多个服务商描述云资源。Pulumi 使用 TypeScript 或 Python 等语言。每个云服务商也提供自己的模板。跨服务商工具可以减少（但不能消除）对单一供应商的依赖。该主题在云与企业软件的供应商锁定：退出策略中有更广泛的讨论。

配置管理：准备服务器内容

Ansible 等类似工具负责配置服务器内部的软件：软件包、配置文件、服务。在现代实践中，许多团队改用现成的镜像或容器来取代这一步。

容器与编排

容器把应用及其依赖打包在一起，使其在任何地方运行结果一致。IaC 随后构建容器运行的环境。容器何时有用、何时过度，见企业应用的 Docker 与容器。

自动化流水线

IaC 的变更通过 CI/CD 流水线运行，流水线展示变更计划、请求批准，然后执行。这一概念与企业应用的自动化测试与 CI/CD相一致。

可以现实期待的好处

可复现的环境

测试和生产由同一份定义构建，差异仅在于规模和数据。你可以创建临时环境来测试发布，然后删除它，从而节省成本。

可评审的变更

基础设施变更与代码变更走同样的流程：提出、同行评审、批准，并记录在版本历史中。“谁改了什么”的问题可以从历史中得到答案。

更快的恢复

如果环境丢失，只要数据仍可从备份中取得，就可以根据定义重建。IaC 不能替代备份，却是灾难恢复与业务连续性计划和企业数据备份策略的重要补充。

成本控制

由于所有资源都列在代码中，很容易找出正在运行的资源及其负责人。自动成本标签有助于报告，与企业的云成本控制一致。

更一致的安全性

网络规则、加密和访问权限只需设定一次并统一应用。扫描工具可以在应用之前检查定义，以发现危险配置，例如向公众开放的数据存储。

风险及其管理

大规模错误

一行错误的代码就可能删除生产数据库。缓解措施：

• 应用之前务必评审变更计划（plan）
• 对关键资源启用删除保护
• 分离权限：并非每个人都能应用到生产环境
• 先应用到测试环境
• 确保存在数据库备份，并且恢复已被测试过

状态文件与机密

声明式工具会保存“状态”，即受管资源的记录，有时包含敏感值。请把状态保存在带有访问控制的加密远程存储中，而不是笔记本上。不要把密码或 API 密钥写进代码文件；使用机密管理服务，见企业应用中的机密与 API 密钥管理。

漂移（drift）

如果有人在代码之外通过控制台修改资源，实际状态就会偏离定义。制定政策：变更只能通过代码进行，并定期运行漂移检查。

过度复杂

嵌套的模块和过于聪明的抽象让新成员难以理解。请选择简单性和清晰的文档。

对某个人的依赖

如果只有一个人懂 IaC，你只是把老问题挪了位置。通过共同评审和文档来传播知识，与软件项目的技术文档与交接一致。

让 IaC 成功的实践

• **一个清晰的仓库**，按环境或按服务划分文件夹结构
• **小型可复用模块**，用于网络或数据库等常见模式，但不要过度
• **锁定工具和服务商版本**，避免结果悄悄改变
• **强制变更评审**，至少由一位同事完成
• **对定义进行自动安全扫描**
• **一致的命名和标签**，涵盖环境、负责人和成本中心
• **定期恢复测试**：真正在沙箱中从零重建环境，以证明定义是完整的
• **记录**应用事件，并配合[可观测性、日志和错误处理](/blog/observabilitas-log-dan-penanganan-error-aplikasi-bisnis)

何时值得使用，何时还不必

值得考虑的情形

• 你有不止一个环境（开发、测试、生产）
• 基础设施由许多组件构成：网络、数据库、队列、存储、服务
• 接触基础设施的人多于几个
• 审计或合规要求有变更轨迹
• 你经常创建和删除临时环境
• 事故后的恢复时间必须很短

可能暂时不需要的情形

• 网站或应用运行在隐藏了基础设施的托管平台上
• 只有一台简单的服务器，变更很少
• 小团队没有时间学习新工具，风险大于收益

对于第二种情形，只需把服务器搭建步骤整理好并保留一个简单的脚本，这已经是一种进步。关于托管平台和基础设施位置的考量，可阅读云端还是本地部署。

分阶段采用计划

第 1 阶段：盘点（1 至 2 周）

• 列出所有现有资源及其负责人
• 标记手动创建且无文档的资源
• 找出风险最高或最常被重建的环境

第 2 阶段：小型试点（2 至 4 周）

• 选择一个低风险组件，例如测试环境或存储桶
• 编写其定义，保存在仓库中，并通过流水线应用
• 记录障碍和所需时间

第 3 阶段：扩展到网络和数据库

• 谨慎地把现有资源导入代码，且不更改它们
• 启用删除保护和强制评审
• 把机密迁移到机密管理服务

第 4 阶段：生产与自动化

• 仅通过流水线应用生产变更
• 添加安全扫描和漂移检查
• 定期演练恢复

每个阶段都有各自的价值，因此如果额外收益不值得付出努力，你可以随时停下。

与应用发布的关系

IaC 管辖应用在哪里运行，而应用发布管辖运行什么。二者协同工作：流水线构建、测试并把应用部署到由 IaC 构建的环境中。功能开关与渐进式发布等技术降低变更风险，而 IaC 确保变更运行的环境一致。

成功的衡量标准

• 从零构建新环境的时间（从数天缩短到数小时或数分钟）
• 通过代码管理的生产资源所占百分比
• 经过评审的基础设施变更数量
• 由手动配置引起的事故数量
• 演练得出的恢复时间
• 没有负责人或标签的资源成本

常见问题

IaC 只适合大公司吗？

不是。拥有几个环境的小团队同样可以受益。但学习成本是真实的，所以应按需求选择范围，并从小型试点开始。

Terraform 还是 OpenTofu，该选哪个？

两者在概念和语法上相似。选择往往取决于许可证、生态系统支持和公司政策。最重要的是团队内保持一致并锁定工具版本。

IaC 会取代数据备份吗？

不会。IaC 重建的是基础设施，而业务数据只能从备份中恢复。两者都必须存在并经过测试。

已经手动创建的资源怎么办？

可以逐步导入代码。要谨慎进行，核实变更计划没有显示不想要的修改，并从低风险组件开始。

团队需要多久才能适应？

因团队经验而异。许多团队在几次试点后就相当适应，但模块、测试和安全策略等最佳实践需要数月才能形成。

结论

基础设施即代码把基础设施从脆弱的手工活变成可以评审、重复和恢复的流程。对于拥有多个环境、团队在成长或有审计需求的企业，收益最大。从小型试点开始，保护机密和状态，要求评审，并定期演练恢复。

Agsora 帮助企业为业务应用设计架构、发布流水线和环境自动化，从简单的托管平台到更复杂的云基础设施。告诉我们你当前的基础设施情况，我们将帮助确定相称的方案。