IaC的核心是声明式配置管理基础设施，Terraform只维护代码定义的终态，手工变更会被销毁；其与Ansible分层协作，前者管资源有无，后者管系统配置；CI/CD中destroy需状态锁、权限隔离与人工确认。

基础设施即代码（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 把他拦住。