IaC是什么？DevOps中如何应用？

基础设施即代码（IaC）并非将服务器配置写成脚本，而是通过可版本化、可测试、可复现的声明式配置（如Terraform）精准定义和管控基础设施终态——它直击运维痛点：告别“生产部署如拆弹”的不确定性；Terraform专注资源有无与生命周期，Ansible承接系统级配置与幂等性交付，二者分层协作而非替代；而在CI/CD中执行destroy等高危操作，必须依托状态锁、最小权限与人工确认门禁三重防线。真正的IaC成熟度，不在于能否写出第一版配置，而在于当有人想绕过代码在控制台“随手改一下”时，你能否用git blame和terraform plan瞬间拦截，让每一次变更都可追溯、可审计、可回归。

基础设施即代码（IaC）不是把服务器写成 Python 脚本，而是用可版本化、可测试、可复现的声明式配置来定义和管理基础设施——它解决的核心问题是：为什么每次部署生产环境都像在拆弹？

为什么 terraform apply 会删掉没写进代码的资源？

Terraform 默认采用“声明式模型”，它只关心终态是否匹配代码描述。如果某台 aws_instance 在云控制台被手动创建，但没出现在 main.tf 中，下次 terraform apply 就可能把它标记为“要销毁”。

• 这是设计使然，不是 bug；IaC 的前提是“一切皆代码”，手工变更不被承认
• 上线前务必用 terraform plan 审查变更集，尤其注意 -/+ 和 - 行
• 若需保留手工资源，可用 terraform import 拉回状态文件，再补全配置

ansible-playbook 和 terraform 到底谁管什么？

分工错位是 IaC 实施中最常见的混乱点：Terraform 管“有没有这台机器”，Ansible 管“这台机器上装了什么、配成什么样”。两者不是替代关系，而是分层协作。

• Terraform 输出（如 aws_instance.public_ip）可作为 Ansible 的 --extra-vars 输入，实现动态主机注入
• 避免在 Terraform 的 provisioner "local-exec" 里写长段 shell 配置逻辑——它不可重入、难调试、破坏幂等性
• 敏感配置（如数据库密码）应通过 Ansible Vault 加密，而非硬编码进 Terraform 变量文件

CI/CD 流水线里跑 terraform destroy 安全吗？

不安全，除非你明确做了三件事：状态锁、权限隔离、人工确认门禁。

• Terraform state 是单点故障源，必须远程后端（如 s3 + dynamodb）并启用 lock，否则并发 apply 可能损坏状态
• CI 账号的云凭证权限必须最小化：destroy 操作应禁止在非预发布环境运行，或强制 require Slack / GitHub PR approval
• 用 terraform workspace 隔离 prod / staging，但别依赖 workspace 做环境隔离主干——它只是 state 分片，不是权限边界

真正难的从来不是写对第一版 main.tf，而是当运维同学说“这个小配置我直接在控制台改一下就好”时，你能不能立刻拿出 git blame + terraform plan -out=plan.binary 把他拦住。

到这里，我们也就讲完了《IaC是什么？DevOps中如何应用？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！