基础设施即代码(IaC)

问题:点控制台建出来的基础设施,没人说得清

先看没有 IaC 的团队怎么准备基础设施--业界戏称 "ClickOps"(点点运维):

需要一套生产环境:登录云控制台 → 点"创建 VPC" → 点"创建子网" → 点"创建 K8s 集群" → 点"创建数据库" → 配安全组 → 配负载均衡 → 配 DNS...几十次点击,散落在十几个控制台页面里.

三个月后,要再开一套一模一样的灾备环境:"当时那个集群的网络是怎么配的来着?" → 没人记得;"安全组开了哪些端口?" → 得一个个翻;"为什么这个参数是这个值?" → 当时点的人离职了.结果:照着记忆又点一遍,开出来一套"看起来差不多但其实不一样"的环境.

这和第 01 篇手工发布,第 05 篇手动改集群是同一个病:依赖人的记忆和手工操作,不可复现,不可追溯,无法 review,会漂移.解药也是同一个思路--把它变成声明式代码.

IaC 是什么:用代码声明基础设施

基础设施即代码(Infrastructure as Code,IaC)的主张:把服务器,网络,数据库,DNS 等基础设施,用代码声明出来,由工具读取代码去自动创建和管理.

注意这里又是熟悉的声明式(第 05 篇)--你描述"我要什么基础设施",而不是"一步步怎么点".以 Terraform 为例,声明"一台云服务器 + 一个数据库"大致长这样:

# main.tf -- 声明期望的基础设施(HCL 语言)
resource "aws_instance" "web" {
  ami           = "ami-0abc123"
  instance_type = "t3.medium"        # 我要一台这样的机器
  tags = { Name = "web-server" }
}

resource "aws_db_instance" "db" {
  engine         = "postgres"
  instance_class = "db.t3.small"     # 我要一个这样的数据库
  allocated_storage = 20
}

$ terraform plan     # 预览:对比"代码声明"和"云上现状",告诉你它打算做什么
$ terraform apply    # 执行:调用云 API,把这些资源真正创建出来

这套代码可以进 Git,可以 review,可以在任意地方 apply 出一模一样的环境--ClickOps 的所有毛病都被治好了.但 IaC 有一个 Kubernetes 世界里不存在 的独特难题,理解它才算真正理解 IaC.

IaC 的灵魂:状态(State)

这是本篇最关键,也最容易被初学者忽略的概念.先抛出一个问题:

答案是:IaC 工具维护一份 状态文件(State)--一份"我管理的代码资源 ↔ 云上真实资源"的映射账本.每次 apply,它做的其实是三方对比:

IaC 的核心循环:代码,状态,现实三方对账

┌─ 代码(期望):我声明要 2 台机器
   │
   ├─ 状态(记录):我上次创建了 1 台,叫 i-0abc123    ──┐
   │                                                    ├─▶ diff → 计划:再建 1 台
   └─ 云上(现实):实际有 1 台 i-0abc123                ──┘

正是这份状态,让 IaC 能算出"从现状到期望,需要增,删,改哪些资源".terraform plan 展示的就是这个 diff.

状态带来的两个现实难题

• 状态必须共享且加锁:状态默认是本地一个文件.但团队协作时,每个人本地一份状态会彻底打架.所以生产实践中状态要放在远程后端(如 S3 + DynamoDB 锁,Terraform Cloud),并加锁防止两人同时 apply 把账本搞乱.
• 状态文件含敏感信息:数据库密码等可能被明文记进状态.因此状态后端必须加密,严格管控访问--它的敏感级别等同于密钥(回想第 02,04 篇对机密的谨慎).

三个主流工具的定位与取舍

IaC 工具不少,挑三个有代表性,思路各异的,理解它们的取舍比记语法重要.

Terraform:行业事实标准

用专门的声明式语言 HCL 描述基础设施,通过 "Provider"(插件)对接几乎所有云厂商和服务(AWS,GCP,Azure,甚至 Cloudflare,GitHub).

• 优点:生态最庞大,Provider 最全,社区资料最多;声明式,跨云通用,是事实标准
• 取舍:要学一门新语言 HCL;表达复杂逻辑(循环,条件)时 HCL 略显笨拙

Pulumi:用通用编程语言写基础设施

Pulumi 让你用 Python,TypeScript,Go 等真实编程语言来声明基础设施,而非专用 DSL.

# 用 Python 声明,可以用真正的循环,函数,条件
import pulumi_aws as aws

for i in range(3):                       # 想建 3 台?用语言原生的循环
    aws.ec2.Instance(f"web-{i}",
        instance_type="t3.medium",
        ami="ami-0abc123")

• 优点:复用你已掌握的语言和工具链(IDE,测试,包管理);复杂逻辑表达自然
• 取舍:灵活性是双刃剑--能写出难以维护的"基础设施程序";生态和社区规模不及 Terraform.注意它底层同样有"状态"概念,前面讲的状态难题一个都不少.

Crossplane:把基础设施变成 K8s 资源

Crossplane 思路最特别:它让你用 Kubernetes 的方式(写 YAML,kubectl apply)来管理云基础设施.一个云数据库,在 Crossplane 里就是一个 K8s 自定义资源:

apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance                  # 一个"云数据库",但它是 K8s 资源
metadata:
  name: my-postgres
spec:
  forProvider:
    engine: postgres
    dbInstanceClass: db.t3.small

这带来一个杀手级优势:它复用 K8s 的控制器和 etcd 来做调谐和状态管理--于是"状态"问题自动消失了,和第 05 篇 K8s 资源一样由集群托管.更妙的是,它能被 ArgoCD 直接管理:

IaC 与 GitOps:把整条链路彻底打通

IaC 让基础设施变成了代码,自然该和阶段二的工作流合流.两种程度:

程度一:IaC 进 CI/CD 流水线. 把 .tf 代码放进 Git,提 PR 时自动跑 terraform plan 把"将要发生的变更"贴到 PR 上供 review,合并后自动 apply.基础设施变更从此和应用代码一样:有 review,有审计,可回滚.

程度二:用 Crossplane 把基础设施纳入 GitOps. 如前所述,基础设施直接成为 ArgoCD 同步的对象,和应用共用一套声明式管线.

┌──────────────────────────────────────────────────┐
│ 底座层(阶段三 · IaC)                                   │
├──────────────────────────────────────────────────┤
│  • Terraform/Crossplane 声明<br/>VPC,K8s 集群,数据库,DNS │
└──────────────────────────────────────────────────┘
┌──────────────────┐
│ 应用层(阶段一,二)       │
├──────────────────┤
│  • CI 构建可信镜像(阶段一) │
└──────────────────┘

关系: B ──→ 应用层(阶段一,二)

至此,从一行代码提交,到承载它的服务器,网络,集群,每一层都是声明式的代码,都在 Git 里,都可复现可审计.这就是现代云原生交付的完整图景.

整个 CI/CD 系列的收束

回头看这八篇,其实是同一个核心思想在不同层次的反复应用--用声明式代码替代人工操作,设好客观标准让机器自动决策:

三个阶段层层向下:阶段一造出可信的"货",阶段二把货安全地送上"车"(集群),阶段三则保证"路和车"(基础设施)本身也是按图纸建的,可随时重建.人的角色,从"亲手操作每一步",变成"定义标准,审查变更,处理例外".