3. 批量部署工具选型：Ansible vs SaltStack vs Puppet vs 自研脚本
说到批量部署，很多刚入行的朋友第一反应就是：“写个 Shell 循环不就行了？”
嗯，我当年也是这么想的。直到有一次，我在一个 500 台规模的机房里，用 for 循环跑 scp 和 ssh，结果网络被打爆，一半机器没跑完就卡死了。从那以后，我才老老实实研究起专业工具来。
今天咱们就来聊聊，市面上主流的几款批量部署工具，到底该怎么选。
核心观点：没有最好的工具，只有最适合你场景的工具。选型前，先搞清楚你的规模、团队能力和运维习惯。
3.1 四款工具的核心差异
我先把结论放在前面，方便你快速建立认知框架。下面这张图，是我自己总结的选型决策树。
3.2 逐个拆解：谁适合什么场景？
3.2.1 Ansible — 上手最快的“瑞士军刀”
Ansible 是我个人最常用的工具。为什么？因为它不需要在客户端装 agent，只要 SSH 通就能跑。这一点在初期部署时太省心了。
优点：
- 无代理架构： 纯 SSH，不需要提前部署客户端
- YAML 语法： 可读性强，运维和开发都能看懂
- 模块丰富： 从系统配置到应用部署，官方模块覆盖很全
缺点：
- 性能瓶颈： 机器超过 200 台时，SSH 并发会成为瓶颈
- 实时性差： 不是常驻进程，每次执行都要重新建立连接
我的经验： 如果你管理的机器在 100 台以内，Ansible 绝对是最优解。我曾经用 Ansible 在 30 分钟内完成了 80 台新服务器的初始化配置，包括修改主机名、配置 yum 源、安装基础监控 agent。整个过程就一个 playbook 文件，团队里新来的同事也能看懂。
3.2.2 SaltStack — 大规模集群的“性能怪兽”
SaltStack 用的是 C/S 架构，客户端需要装 minion。但换来的是极致的性能。
优点：
- 速度快： 基于 ZeroMQ 消息队列，并发能力极强
- 实时执行： 可以像操作本地一样，远程实时执行命令
- Grains 系统： 可以按机器属性（如操作系统、CPU 核数）做精细化配置
缺点：
- 部署复杂： 需要维护 master 和 minion 的证书认证
- 学习曲线陡： 状态系统的写法比 Ansible 的 YAML 要复杂一些
避坑指南： 我曾经在一个 1000 台规模的集群上部署 SaltStack，结果 master 的内存配置没调好，导致消息队列积压，minion 全部失联。后来才发现，SaltStack master 的 worker 数量和内存分配需要根据 minion 数量做精确计算。这个坑，我踩过。
3.2.3 Puppet — 配置合规的“强迫症福音”
Puppet 是声明式配置的鼻祖。你只需要告诉它“最终状态是什么”，它会自动帮你达成。
优点：
- 声明式模型： 配置即代码，确保所有机器状态一致
- 成熟稳定： 企业级功能完善，有完善的 RBAC 和审计
- 资源抽象： 对文件、服务、包等资源做了很好的抽象
缺点：
- 笨重： 需要部署 Puppet Server，架构相对复杂
- 调试困难： 声明式的问题排查不如命令式直观
我的建议： 如果你的团队有严格的合规要求（比如金融、医疗行业），Puppet 是不二之选。它的报告系统可以清楚地告诉你“哪台机器在什么时候配置发生了漂移”。但如果你只是做快速部署，Puppet 可能有点杀鸡用牛刀了。
3.2.4 自研脚本 — 小团队的“最后一公里”
说实话，我不建议你从零开始写一套部署系统。但如果你只是管理十几台机器，或者有非常特殊的定制需求，自研脚本反而更灵活。
优点：
- 完全可控： 想怎么改就怎么改，没有框架限制
- 零依赖： 不需要安装任何第三方软件
缺点：
- 重复造轮子： 错误处理、并发控制、日志审计都要自己写
- 维护成本高： 脚本写多了，自己都看不懂
避坑指南： 我曾经接手过一个项目，前任用 Python 写了一套部署脚本，功能倒是都有，但错误处理几乎为零。有一次部署时网络中断，脚本直接崩溃，导致 20 台机器配置了一半，状态完全不一致。从那以后，我坚持：如果超过 20 台机器，就别自己写脚本了。
3.3 选型对比表
我把核心差异整理成了一张表，方便你快速对比。
| 维度 | Ansible | SaltStack | Puppet | 自研脚本 |
|---|---|---|---|---|
| 架构 | 无代理（SSH） | C/S（ZeroMQ） | C/S（HTTPS） | 自定义 |
| 学习成本 | 低 | 中 | 高 | 取决于实现 |
| 性能（500台） | 中 | 高 | 中 | 低 |
| 实时性 | 低 | 高 | 低 | 自定义 |
| 配置语言 | YAML | YAML + Jinja | DSL（Ruby） | Shell/Python |
| 适用规模 | 1-200台 | 100-10000台 | 500-50000台 | 1-20台 |
| 维护成本 | 低 | 中 | 高 | 高 |
3.4 我的最终建议
说了这么多，其实选型没那么复杂。我个人的经验是：
- 50 台以下： 直接用 Ansible，别犹豫。学习成本最低，效果最好。
- 50-500 台： 如果团队有 Python 基础，上 SaltStack；如果团队偏运维，继续用 Ansible 也够用。
- 500 台以上： 认真考虑 SaltStack 或 Puppet。这时候性能和维护成本才是关键。
- 特殊场景： 比如需要和现有 CMDB 深度集成，或者有非常特殊的部署流程，可以考虑自研脚本，但一定要做好错误处理和日志审计。
记住一句话： 工具是拿来用的，不是拿来秀的。选一个团队能快速上手、能稳定维护的工具，比选一个“最牛”的工具重要得多。