Ansible Playbook vs Ad-Hoc

下面是一份 Ansible Playbook vs Ad-Hoc 的详细对比、适用场景、生产最佳实践、常见误区。

非常适合构建 Ansible 自动化体系时使用。

🔥 一句话总结

项目	Ad-Hoc	Playbook
用途	临时命令 / 快速操作	长期维护 / 可重复的配置管理
场景	临时批量执行命令、查看状态、修改单个配置	系统部署、应用部署、运维流程自动化、持续交付
适合	运维工程师的日常行政命令	团队协作 / 可版本化 / CI/CD
优势	快速、无文件、简单	可复用、结构化、依赖管理、幂等可靠
缺点	不可维护、不可回滚、无幂等性	写起来相对复杂

1. 📌 什么时候用 Ansible Ad-Hoc？

Ad-Hoc = 一条临时命令即可完成一次性任务

无需 Playbook、无需文件，适用于 短平快操作。

✅ Ad-Hoc 典型场景（非常明确）

1. 批量执行简单命令

ansible all -m ping
ansible web -a "uptime"
ansible db -a "df -h"

2. 临时状态查看

ansible web -m setup
ansible all -m shell -a "ps aux | grep nginx"

3. 临时修改文件/参数

ansible all -m lineinfile -a "path=/etc/sysctl.conf line='net.ipv4.ip_forward = 1'"

4. 快速分发文件

ansible web -m copy -a "src=a.conf dest=/etc/a.conf"

5. 执行一次性维护操作

ansible web -m service -a "name=nginx state=restarted"

6. 运维紧急处理

临时关掉服务
临时删除文件/清理日志
临时加监控

⭐ Ad-Hoc 最佳实践

1. 小操作必用 ad-hoc，大操作禁用 ad-hoc

一次性、无副作用操作——适合 ad-hoc

危险操作、重操作——不要 ad-hoc！

2. 加上 –check 模式

可模拟执行：

ansible web -m lineinfile -a "... " --check

3. 使用 –limit 缩小范围

ansible all -m shell -a "systemctl restart nginx" --limit web1

4. 高风险命令必须加确认

千台服务器执行：

ansible all -a "rm -rf /tmp/*"

❌ 这是最常见的事故

务必限制：

ansible all -a "rm -rf /tmp/*" --limit 'app-&prod' --check

5. ad-hoc 不做业务逻辑、不做多步操作

一条只能做一件事

如果需要流程 -> playbook

2. 📘 什么时候用 Ansible Playbook？

Playbook = 可重复的自动化蓝图

适合：固定流程、复杂操作、系统部署、持续交付、环境一致性管理。

✅ Playbook 典型场景

1. 服务部署（Nginx/MySQL/Redis）

包含安装 -> 配置 -> 启动 -> 检查 -> 回滚完整流程

2. 应用发布（Java、Python、Go）

从拉代码到重启服务全自动

3. 版本管理、环境管理（prod/staging/dev）

4. 业务系统上线/升级

需要多步流程的统一版本控制

5. 操作需幂等性

Playbook 反复执行不会出错（ad-hoc 不具备）

6. 持续交付 CI/CD 与流水线

GitLab、Jenkins 都依赖 Playbook

⭐ Playbook 最佳实践（企业级）

1. 一切自动化都写成 Role（强烈推荐）

不要把逻辑散落在多个 playbook 中。

结构化：

roles/
  nginx/
    tasks/
    templates/
    files/
    handlers/

2. playbook 中不写 shell，优先使用模块

❌ 错误：

- shell: "systemctl restart nginx"

✅ 正确：

- service:
    name: nginx
    state: restarted

3. 默认使用 handlers（减少重复启动服务）

4. 使用条件（when）控制逻辑分支

5. 使用模板渲染配置（templates/*.j2）

6. 所有变量必须存放在 group_vars/host_vars

Playbook 不包含变量，这是可维护性关键。

7. 用 tags 进行分模块执行

ansible-playbook site.yml --tags "deploy"

8. 使用检查模式（–check）+ 差异模式（–diff）

ansible-playbook site.yml --check --diff

9. Playbook 存 Git，要求 Code Review -> 防止事故

10. Playbook 必须可重试（幂等设计）

确保重复执行不会破坏系统。

3. 🎯 Ad-Hoc vs Playbook 场景对比总结

📌 Ad-Hoc

✅ 适合

批量命令
一次性任务
临时的、无副作用的小操作
查看信息、调试、批量检查
服务器上线前的快速验证

❌ 不适合部署、业务逻辑、长流程

📘 Playbook

✅ 适合

正式部署流程
大型业务系统上线
多步流程
配置管理
应用发布
多环境管理
固定任务周期
安装、配置、日志、监控、限流、恢复

❌ 不适合快速零碎的小任务

4. 🎖️ 如何选择？（运维工程师入门级判断法）

只有 1 步 -> Ad-Hoc
多于 3 步 -> Playbook
将来需要重复执行 -> Playbook
影响面大（生产环境） -> Playbook
实时操作 + 紧急处理 -> Ad-Hoc（但需谨慎）

5. 🧨 常见误区

❌ 误区 1：全部用 ad-hoc

结果：无版本控制、难以重复执行、容易误操作。

❌ 误区 2：Playbook 写成“多 shell 脚本”

不要把 playbook 当成 shell 集合。

❌ 误区 3：Playbook 中写 IP

生产绝不能这样做，应使用 inventory + 变量。

❌ 误区 4：playbook 没有幂等性

写成：

- shell: "echo 1 >> file"

导致重复执行追加多次。

6. 📦 最终简短总结（你可以直接放到文档中）

Ad-Hoc：

用于临时命令、一次性维护、批量检查、快速操作
不适合复杂流程
最佳实践：限制范围、启用 check、谨慎执行

Playbook：

用于可重复的自动化流程：部署、升级、配置管理、CI/CD
强调幂等性、结构化、版本化、模块化、可重复
最佳实践：使用 Roles、使用模块、handlers、加 diff/check、CI 审核