Ansible pull 模式适合控制节点并发瓶颈明显的大规模集群，但会牺牲实时管控能力并增加目标节点配置复杂度。

命令速用版

在目标节点上配置 cron 任务定期执行 ansible-pull，替代控制节点主动推送。

# 在目标节点执行，从 Git 仓库拉取 playbook 并运行
ansible-pull -U https://git.example.com/ansible-repo.git -d /opt/ansible

# 配置 cron 每 30 分钟执行一次
*/30 * * * * /usr/bin/ansible-pull -U https://git.example.com/ansible-repo.git

为什么会这样

Push 模式在大规模场景下控制节点 SSH 并发连接会成为瓶颈，Pull 模式将执行负载分散到目标节点。

标准 Ansible 架构基于推送 (Push) 模式工作，控制节点通过 SSH 连接被管理节点执行任务，当节点数量激增时，控制节点需要维护大量并发 SSH 连接，可能导致连接超时或资源耗尽。Pull 模式下，目标节点主动从 Git 仓库拉取配置并本地执行，消除了控制节点的并发压力，但依赖目标节点的定时任务和网络连通性。

分步处理

1. 准备 Git 仓库：将 playbook 和 inventory 配置存入 Git 仓库，确保目标节点有读取权限。

2. 安装依赖：在所有目标节点安装 ansible 和 git 工具，验证版本兼容性。

3. 配置免密或凭证：配置 SSH 密钥或 Git token，确保目标节点能无交互拉取代码。

4. 设置定时任务：在目标节点写入 cron 任务，指定执行频率和日志路径。

5. 配置日志回传：设置 ansible.cfg 中的 log_path 或将日志发送到中央日志服务器，以便追踪执行状态。

怎么验证是否生效

检查目标节点 cron 日志和 ansible 本地执行日志，确认任务按时运行且无报错。

查看 /var/log/cron 或 journalctl -u cron 确认定时任务触发记录。检查 ansible-pull 指定的日志文件，确认 OK 和 Changed 状态正常。在 Git 仓库修改 playbook 版本，观察目标节点是否在下个周期自动同步并应用变更。

常见坑

1. 网络隔离问题：目标节点必须能访问 Git 仓库，内网环境需配置代理或私有 Git 服务。

2. 并发冲突风险：多个节点同时拉取可能触发 Git 锁或应用部署冲突，需设计幂等 playbook。

3. 密钥管理难度：目标节点存储 Git 凭证存在泄露风险，建议使用只读 Token 或 SSH 密钥限制权限。

4. 状态可见性降低：控制节点无法实时知道目标节点执行结果，需依赖日志聚合系统监控。

常见问题

Ansible pull 模式比 push 模式更安全吗？

不一定，pull 模式需要在目标节点存储 Git 凭证，增加了凭证泄露面，但减少了控制节点 SSH 暴露风险。

大规模集群必须用 pull 模式吗？

不是，如果控制节点性能足够且网络稳定，push 模式更便于集中管控和即时响应。

如何混合使用 push 和 pull 模式？

常规配置用 pull 模式定期同步，紧急修复用 push 模式临时下发，需确保 playbook 幂等性避免冲突。

参考来源

1. 运维效率革命:Ansible vs Puppet vs Salt 三大配置管理工具深度测评 - 配置管理工具架构对比

2. 『运维备忘录』之 Ansible 自动化运维工具 - Ansible 架构与 pull 内容说明

3. Ansible 自动化运维实战：从核心架构到大规模部署调优 - 无代理架构与执行效率分析