ansible基础-优化

简介

当管理集群达到一定规模时，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: nodes
  gather_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 facter
  setup:
    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: all
  strategy: free
  tasks:
  ...

参数含义：

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

举个