基础设施即代码

你有没有经历过这种噩梦：线上服务器挂了，但没人记得当初是怎么配置的？ 手动登录服务器、凭记忆敲命令、祈祷不要敲错——这就是传统运维的日常。基础设施即代码（Infrastructure as Code，IaC）彻底改变了这一切：用代码来定义和管理基础设施，让服务器配置像软件一样可版本控制、可复现、可审计。

• 可复现：同一份代码，无论执行多少次，结果都一样（幂等性）
• 可版本控制：基础设施变更通过 Git 管理，谁改了什么、为什么改，一目了然
• 可审计：所有变更都有记录，满足合规要求
• 可自动化：通过 CI/CD 流水线自动部署，消除人为操作风险
• 可协作：团队成员通过 Pull Request 审查基础设施变更，就像审查代码一样

• 声明式（Declarative）：描述"我要什么"，工具自动计算"怎么做"。Terraform、CloudFormation 采用这种方式。优点是幂等性好，缺点是灵活性受限。
• 命令式（Imperative）：描述"怎么做"，一步步执行。Ansible、Shell 脚本采用这种方式。优点是灵活，缺点是难以保证幂等性。
• 混合式：Pulumi、AWS CDK 用通用编程语言编写，兼具声明式的状态管理和命令式的灵活性。

1. Write（编写）：用 HCL（HashiCorp Configuration Language）编写基础设施定义文件（.tf）。声明你需要的资源：服务器、数据库、网络等。
2. Plan（计划）：运行 terraform plan，Terraform 会对比当前状态和目标状态，生成一份"执行计划"——告诉你它打算创建、修改、删除哪些资源。这是安全网，让你在真正执行前确认变更。
3. Apply（执行）：确认计划无误后，运行 terraform apply，Terraform 按计划创建或修改资源。执行完成后，当前状态会保存到状态文件（terraform.tfstate）。
4. Destroy（销毁）：不再需要时，运行 terraform destroy 清理所有资源，避免产生不必要的费用。

• 初创团队 / 单云：CloudFormation（AWS）或对应云平台原生工具，生态集成最好
• 多云 / 中大型团队：Terraform，社区最大、Provider 最丰富、招聘最容易
• 开发者主导的团队：Pulumi 或 CDK，用熟悉的编程语言写基础设施，IDE 支持好
• 需要配置管理：Ansible，擅长服务器内部配置（安装软件、修改配置文件）

1. 不可复现：代码描述的环境和实际环境不一致，新建环境时会出问题
2. 回滚失败：以为回滚到上一版本就能恢复，但实际环境已经被手动修改过
3. 安全隐患：手动开放的端口、放宽的权限可能被遗忘，成为攻击入口
4. 审计失效：合规审计基于代码，但代码不反映真实状态

1. 模块化：将可复用的基础设施抽象为模块（如 VPC 模块、数据库模块），避免复制粘贴。就像写函数一样，一处定义、多处调用。
2. 环境隔离：开发、测试、生产使用独立的状态文件和变量文件，通过 workspace 或目录结构隔离。
3. 远程状态管理：状态文件（tfstate）存储在远程后端（S3 + DynamoDB），支持团队协作和状态锁定，避免并发冲突。
4. 敏感信息管理：密码、密钥等敏感信息不要写在代码里，使用 Vault、AWS Secrets Manager 等工具管理。
5. CI/CD 集成：将 terraform plan 集成到 PR 流程，apply 通过流水线自动执行，杜绝本地手动操作。
6. 代码审查：基础设施变更和应用代码一样需要 Code Review，尤其是涉及安全组、IAM 策略的变更。