当服务器数量从 1 台变成 10 台再变成 50 台时，逐台 SSH 上去手动配置就彻底行不通了。Ansible 用统一的剧本（Playbook）管理所有服务器——它不需要在被管理机器上安装 Agent，只需要 SSH 连接。

为什么是 Ansible？

与 Puppet、Chef、SaltStack 相比，Ansible 的最大优势是无 Agent 架构——被管理服务器不需要安装任何额外软件。只要你能 SSH 上去，Ansible 就能管。这大大降低了准入门槛和维护成本。

我的踩坑记：那次凌晨的批量灾难

去年某次给 12 台 Redis 从节点做配置升级，我手写了 Playbook，其中一行 restart 任务的 when 条件漏写了引号。结果执行到第 4 台时直接报错退出——前 3 台已经重启、剩下的 9 台还是旧配置。

更糟的是 Redis 重启顺序错了，导致主从同步短时全断。那次我没用 serial 滚动执行（应该一次只动 1 台），也没做 handlers 的强制顺序。后来我给所有涉及”重启类服务”的剧本都加了 serial: 1，并且把 become 提权、validate 模板的预检查全补上。这次的教训是：Ansible 不是”快速执行”，而是”可预测的执行”——任何涉及多台的破坏性操作，必须先在测试分组上 dry-run。

Inventory：主机清单

主机清单定义了要管理的服务器，支持分组嵌套。一个 prod 组可以包含 webservers 子组和 databases 子组——对不同组执行不同的剧本。

Playbook：剧本文件

Ansible 的核心是 Playbook——YAML 格式的剧本文件，描述要在目标机器上执行的任务序列。核心元素：hosts（目标组）、tasks（任务列表）、handlers（触发器）、vars（变量）。

关键实践：用 template 模块动态生成配置文件（Jinja2 模板）、用 notify+handlers 在配置变化时自动重启服务、用 become 进行 sudo 提权。

Roles：模块化组织

当 Playbook 变长后，用 Roles 将任务/模板/变量/处理器按功能拆分——nginx 角色负责 Web 服务器、postgresql 角色负责数据库。每个角色是独立的可复用的模块。

Ansible Vault：加密敏感变量

数据库密码、API 密钥等敏感信息不能明文写进 Playbook。Ansible Vault 加密整个文件或单个变量，执行时用密码解密。

总结

Ansible 的无 Agent 架构让它成为运维自动化的入门首选。从 Inventory 定义目标、Playbook 描述任务、Roles 组织代码、Vault 保护密钥——一台机器到一百台，同样的剧本，同样的结果。