当前位置： 首页 > ds >正文

ansible基础-优化

ds 2025/5/6 7:55:22

简介

当管理集群达到一定规模时，ansible达到性能瓶颈是难以避免的，此时我们可以通过一定手段提高ansible的执行效率和性能。

笔者虽未管理过超大规模服务器，但也通过查找资料和咨询大神了解了一些。现总结一些调优方法，供大家参考。

Pipelinling

我们知道ansible执行一个模块要ssh到目的主机多次，开启「pipelining」特性实际上是通过减少ssh连接次数，从而缩短ansible执行时间。在部署大规模服务器或引用模块非常多时，开启「pipelining」特性会给ansible带来显著的性能提升。

开启方法也很简单，将ansible.cfg的pipelining参数设置为True即可，该参数默认值是False。

既然「pipelining」特性默认是关闭的，肯定有它的理由：关闭该特性可以与sudo的requiretty兼容（即/etc/sudoers配置文件的「Defaults requiretty」配置项）。大部分linux操作系统是默认开启requiretty功能的，所以pipelining也是默认False的。

也就是说，如果我们要开启pipelining特性，要么playbook不使用sudo越权功能，要么取消sudo的「requiretty」特性。

该特性可以通过命令行添加 -vvvv 后，根据执行结果对比出区别，因篇幅原因这里不再展示。

适用场景

  • 管理大规模集群
  • 部署代码内容很多，调用了大量的ansible模块

Control_path

control_path通过设置ControlPath sockets的文件路径与文件命名避免因sockets文件过长（超过108个字符串）导致ansible报错的问题。

设置方法为更改ansible.cfg里的control_path参数，ansible2.7版本默认值为「配置项control_path_dir的值」+「根据hostname生成的哈希值」+「ssh端口号」+「用户名」

在ansible旧版本中，默认值是包含主机名的，这在一些特殊情况下（例如EC2主机），会因主机名过长导致ControlPath sockets文件过长，从而导致ansible执行报错。但在新版本中默认值的主机名部分被替换为主机名的哈希值，这很大程度上避免了该问题的发生。

我们也可以设置其他的参数，例如：

control_path = %(directory)s/%%h-%%r

其中$directiry是control_path_dir的值，后面的参数可以灵活定制，可用参数如下：

%L 本地主机名的第一个组件
%l 本地主机名（包括域名）
%h 远程主机名（命令行输入）
%n 远程原始主机名
%p 远程主机端口
%r 远程登录用户名
%u 本地 ssh 正在使用的用户名
%i 本地 ssh 正在使用 uid
%C 值为 %l%h%p%r 的 hash

适用场景

当ansible报错并且使用 -vvvv 查看发现有类似「too long for Unix domain socket」的错误信息，我们应该想到这个调优方式。

Gather subset

Disable gather facts

在介绍Gather subset之前，我们先简单说下gather_facts功能，gather_facts用于控制一个play是否收集目的主机的facts信息（参考《ansible基础-变量》），默认值为true/True/yes，写法如下：

 - hosts: nodesgather_facts: True  tasks:

在playbook执行过程中，ansible收集facts变量是很耗时的一个步骤，如果我们确定play中没有用到fact变量信息，可以直接将其关闭，即将gather_facts设置为false/False/no。

Gather subset

但是在实际使用中不收集facts变量的情况很少。在gather_facts关闭的情况下，我们可以给play单独添加一个setup模块，并通过gather_subset参数严格控制facts的收集种类，这样既拿到了我们需要的fact变量又提高了ansible的执行效率，gather_subset参数的默认值为all。

playbook中使用方法示例：

 - name: Collect only facts returned by factersetup:gather_subset:- '!all'- '!any'- facter

命令行使用方法示例：

# Collect only facts returned by facter.
ansible all -m setup -a 'gather_subset=!all,!any,facter'

可用参数有all, min, hardware, network, virtual, ohai, facter,可以使用列表的格式指定多个参数，使用「!」指定不收集的facts类型。

比较常用的几个范例：

  • 仅指定facter，说明收集puppet facter和min子集信息（默认包含min子集）。
  • 指定「!all」，说明只收集min子集信息
  • 指定「!all,!min」，说明不收集任何信息
  • 指定「!all,!any」+其他的fact子集，说明只收集该子集信息

Fact gather cache

关于facts变量还有一个优化手段，即facts缓存。

fact缓存是指将收集到的facts信息缓存到本地json文件或者redis数据库内，以便下次执行直接读取，从而提高执行效率。

关于facts缓存，我们在《ansible基础-变量》6.1.2 facts缓存有详细介绍，在这里就不再重复介绍了。

Strategy

strategy的作用范围是一个play，通过设置不同参数，控制一个play内所有任务的执行策略。

设置方法为更改ansible.cfg里的strategy参数，默认值为linear，可选参数为free；另外一种方式是在playbook内定义该策略，格式为：

- hosts: allstrategy: freetasks:...

参数含义：

  • linear策略即线性执行策略，线性执行策略指主机组内所有主机完成一个任务后才继续下一个任务的执行，在执行一个任务时，如果某个主机先执行完则会等待其他主机执行结束。说直白点就是第一个任务在指定的主机都执行完，再进行第二个任务的执行，第二个任务在指定的主机都执行完后，再进行第三个任务的执行…… 以此类推。
  • free策略即自由策略，即在一个play执行完之前，每个主机都各顾各的尽可能快的完成play里的所有任务，而不会因为其他主机没执行完任务而等待，不受线性执行策略那样的约束。所以这种策略的执行结果给人感觉是无序的甚至是杂乱无章的，而且每次执行结果的task显示顺序很可能不一样。

举个🌰，展示下两种策略的执行效果：

playbook要实现的是三台主机debug出test_1，test_2，test_3三个字符串。当使用linear策略时，执行效果如下：

➜  lab-ansible ansible-playbook playbooks/test_trategy.yamlPLAY \[nodes\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*TASK \[Gathering Facts\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node3\]
ok: \[node2\]
ok: \[node1\]TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_1"
}
ok: \[node3\] \=> {"msg": "test\_1"
}
ok: \[node2\] \=> {"msg": "test\_1"
}TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_2"
}
ok: \[node3\] \=> {"msg": "test\_2"
}
ok: \[node2\] \=> {"msg": "test\_2"
}TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_3"
}
ok: \[node3\] \=> {"msg": "test\_3"
}
ok: \[node2\] \=> {"msg": "test\_3"
}PLAY RECAP \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
node1                      : ok\=4    changed=0    unreachable=0    failed=0
node2                      : ok\=4    changed=0    unreachable=0    failed=0
node3                      : ok\=4    changed=0    unreachable=0    failed=0执行结果当使用free策略时，执行效果如下：PLAY \[nodes\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*TASK \[Gathering Facts\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node3\]
ok: \[node2\]
TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node3\] \=> {"msg": "test\_1"
}
ok: \[node2\] \=> {"msg": "test\_1"
}
TASK \[Gathering Facts\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\]TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node3\] \=> {"msg": "test\_2"
}
ok: \[node2\] \=> {"msg": "test\_2"
}
TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_1"
}
TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node3\] \=> {"msg": "test\_3"
}
ok: \[node2\] \=> {"msg": "test\_3"
}TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_2"
}TASK \[debug\] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ok: \[node1\] \=> {"msg": "test\_3"
}PLAY RECAP \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
node1                      : ok\=4    changed=0    unreachable=0    failed=0
node2                      : ok\=4    changed=0    unreachable=0    failed=0
node3                      : ok\=4    changed=0    unreachable=0    failed=0

执行结果:

从上面两个个执行结果很明显的能看出区别，linear策略是遵循第一个任务、第二个任务、第三个任务……这样顺序执行下去的，而free策略则是无序的，甚至Gathering Facts任务也可能在debug任务之后执行。

Forks

forks用来设置同一时刻与目的主机连接数，也可以理解为主机并行数，默认值比较保守为5。在生产中，多数情况下我们会更改这个参数。如果控制节点的CPU和网络性能够用，设置几十上百个也是可以的。

在ansible.cfg设置forks的全局默认值：

# ansible.cfg
[defaults]
forks  = 15

命令行设置forks的数量，即在执行playbook时，通过「–forks」或「-f」指定：

lab-ansible ansible-playbook playbooks/test_forks.yaml --fork 10

Serial

serial用于控制一个play内的主机并行数，这个并行数不能超过forks，超过后则serial不会生效。

定义方法如下：

--
- hosts: nodesserial: 2tasks:

本质上，serial作用范围是一个play，受限于forks，但比forks控制的更加细节。假如我们的forks设置为100，但是想让某个play里的所有任务并行数为50的执行，此时我们应该想到serial这个调优方法。

Async and poll

同步阻塞模式和异步模式

  1. 同步阻塞模式指在playbook执行时，控制端和被控制端会一直保持连接状态，逐个任务的执行，直到该playbook执行完毕，这种模式称为同步阻塞模式，也是absible的默认执行模式。
  2. 异步模式指ansible将一次性运行所有的任务，并将所有的任务丢到后台执行，每个任务有一个job_id，ansible会根据这个job_id每隔一段时间轮训检测该任务的执行情况，直到检测到任务执行结束。这种模式称为异步模式。

Async and pool

前面章节我们所说的Strategy、Forks、Serial都是ansible同步阻塞模式下的优化方法，其中，strategy是通过控制任务执行策略进行优化，forks和serial是通过控制并行数进行优化。

针对某些特殊任务，尤其是可能被锁住或超时的任务，我们可以采用ansible异步模式来提高执行效率。

async和poll分别用来指定异步模式下任务的最大运行时间和检测间隔时间，poll的缺省值为10。

---
- hosts: allremote_user: roottasks:- name: simulate long running op (15 sec), wait for up to 45 sec, poll every 5 seccommand: /bin/sleep 15async: 45poll: 5

该示例中sleep命令采用异步的方式执行，ansible会等待该任务最长45秒，每隔5秒钟检测一次任务的执行结果。

特殊情况下，我们可以将poll的值设置为0，这代表ansible将任务放到后台后，不会再管这个任务的执行状态，任其自生自灭。

这里举一个利用异步重启服务器的例子，因篇幅原因，仅给大家展示部署代码，就不贴执行结果了，如果您感兴趣，可以亲自实践下：

---
- hosts: node1gather_facts: notasks:- shell:cmd: grub2-set-default 0notify:- reboot- wait for reboot- wait for ssh starthandlers:- name: rebootshell:cmd: shutdown -r now "Reboot triggered by ansible"async: 1poll: 0ignore_errors: True- name: wait for rebootwait_for_connection:timeout: 300- name: wait for ssh startwait_for:host: node1state: starteddelay: 10port: 22timeout: 30

🔥运维干货分享

  • 软考高级系统架构设计师备考学习资料
  • 软考中级数据库系统工程师学习资料
  • 软考高级网络规划设计师备考学习资料
  • Kubernetes CKA认证学习资料分享
  • AI大模型学习资料合集
  • 免费文档翻译工具(支持word、pdf、ppt、excel)
  • PuTTY中文版安装包
  • MobaXterm中文版安装包
  • pinginfoview网络诊断工具中文版
  • Xshell、Xsftp、Xmanager中文版安装包
  • Typora简单易用的Markdown编辑器
  • Window进程监控工具，能自动重启进程和卡死检测
  • Spring 源码学习资料分享
  • 毕业设计高质量毕业答辩 PPT 模板分享
  • IT行业工程师面试简历模板分享
http://www.xdnf.cn/news/4204.html

相关文章：

  • 代码随想录算法训练营day9:字符串part02
  • 英伟达开源英语自动语音识别模型：nvidia/parakeet-tdt-0.6b-v2
  • android zxing QrCode 库集成转竖屏适配问题
  • 餐具瓷器品牌十大排名
  • Linux安装RTL8215网卡驱动
  • FreeRTOS系统CPU使用率统计
  • AutoGPT
  • GESP2024年3月认证C++八级( 第二部分判断题（6-10））
  • 柯西乘积定理（Cauchy Product Theorem）
  • C# 反射
  • [特殊字符] 大模型（LLMs）RAG 版面分析——文本分块面
  • 农经权二轮延包软件—摸底申请表生成
  • 数据库的并发控制
  • nats v2.11.3全新上线！MQTT支持增强、JetStream性能优化、关键BUG修复，构建高效可信消息中间件新时代
  • NV287NV291美光固态闪存NV293NV294
  • Deepseek基础-api key申请及应用(java)、硅基流动api key申请及应用(dify)
  • ThreadLocal源码深度剖析：内存管理与哈希机制
  • Lora原理介绍并用Macbook air超快实现本地微调小模型
  • AI日报 · 2025年5月05日｜雅诗兰黛与微软合作成立 AI 创新实验室，加速美妆产品研发与营销
  • 【言语理解】片段阅读之下文推断(6)
  • 设计模式每日硬核训练 Day 18：备忘录模式（Memento Pattern）完整讲解与实战应用
  • 全球化电商平台AWS云架构设计
  • 矩阵置零（中等）
  • 设计模式-基础概念学习总结（继承、多态、虚方法、方法重写）
  • 深入理解块级格式化上下文（BFC）
  • 文本三剑客
  • 字符串匹配 之 拓展 KMP算法(Z算法)
  • 数据集-目标检测系列- 印度人脸 检测数据集 indian face ＞＞ DataBall
  • 深度解析：从 GPT-4o“谄媚”到 Deepseek“物理腔”，透视大模型行为模式的底层逻辑与挑战
  • Unity：AddTorque()（增加旋转力矩）