标签：open 时间 操作 问题 就会 程序 将不 多个 计时
Ansible 是一个系统自动化工具，可以用来做系统配管理，批量对远程主机执行操作指令。我自己使用 Ansible 也有一段时间了，这里总结了一些使用 Ansible 过程中使用的心得与大家分享。
在使用 Ansible 的过程中，当管理的服务器数量增加时，不得不面对一个无法避免的问题执行效率慢，这里列出一些解决办法。
在做性能优化之前首先需要做的是收集一些统计数据，这样才能为后面做的性能优化提供数据支持，对比优化前后的结果。非常不错的是，在 github 发现一个 Ansible 任务计时插件“ansible-profile”，安装这个插件后会显示 ansible-playbook 执行每一个任务所花费的时间。Github 地址： https://github.com/jlafon/ansible-profile 。 这个插件安装很简单，只需要简单的三个命令即可完成安装。在你的 playbook 文件的目录下创建一个目录，目录名 callback_plugins 然后将下载的 profile_tasks.py 文件放到该目录下。
cd /etc/ansible
mkdir callback_plugins
cd callback_plugins
wget https://raw.githubusercontent.com/jlafon/ansible-profile/master/callback_plugins/profile_tasks.py
现在，执行 ansible-playbook 命令就会看到 playbook 中每个 tasks 的用时情况。
在这里，我设置了 2 个 task，1 个 task sleep 10 秒，另 1 个 task sleep 15 秒，在 PLAY RECAP 处会汇总所有 task 执行消耗的时间。
如果您观察过 ansible-playbook 的执行过程中，您会发现 ansible-playbook 的第 1 个步骤总是执行 gather facts，不论你有没有在 playbook 设定这个 tasks。如果你不需要获取被控机器的 fact 数据的话，你可以关闭获取 fact 数据功能。关闭之后，可以加快 ansible-playbook 的执行效率，尤其是你管理很大量的机器时，这非常明显。关闭获取 facts 很简单，只需要在 playbook 文件中加上“gather_facts: no”即可。如下
---
- hosts: 172.16.64.240
gather_facts: no
remote_user: liheng
sudo: yes
roles:
- {role: profile_test}
好的，来看关闭前后的执行时间变化。
关闭前后，执行时间相关 1 秒，因为我这里只有一台机器，所以时间差距并不是很明显。不过，从这个例子也可以看出，关闭 facts 获取后，执行速度是快了的。
SSH pipelining 是一个加速 Ansible 执行速度的简单方法。ssh pipelining 默认是关闭，之所以默认关闭是为了兼容不同的 sudo 配置，主要是 requiretty 选项。如果不使用 sudo，建议开启。打开此选项可以减少 ansible 执行没有传输时 ssh 在被控机器上执行任务的连接数。不过，如果使用 sudo，必须关闭 requiretty 选项。修改 /etc/ansible/ansible.cfg 文件可以开启 pipelining
将
pipelining=False
修改为
pipelining=True
修改完后，可以批量对机器执行命令试下，可以明显感受到速度的提升。
ControlPersist 特性需要高版本的 SSH 才支持，CentOS 6 默认是不支持的，如果需要使用，需要自行升级 openssh。ControlPersist 即持久化 socket，一次验证，多次通信。并且只需要修改 ssh 客户端就行，也就是 Ansible 机器即可。
升级 openssh 的过程这里不做介绍。这里只介绍下 ControlPersist 设置的办法。
cat ~/.ssh/config
Host *
Compression yes
ServerAliveInterval 60
ServerAliveCountMax 5
ControlMaster auto
ControlPath ~/.ssh/sockets/%r@%h-%p
ControlPersist 4h
在开启了 ControlPersist 特性后，SSH 在建立了 sockets 之后，节省了每次验证和创建的时间。在网络状况不是特别理想，尤其是跨互联网的情况下，所带来的性能提升是非常可观的。有这边需求的，试试就知道了。
在刚开始使用 ansible-playbook 做应用程序部署的时候，因为在部署的过程中有使用到 command 或 shell 模块执行一些自定义的脚本，而且这些脚本都会有输出，用来表示是否执行正常或失败。如果像之前自己写脚本做应用程序部署的，这很好实现。但现在是用 Ansible 做，那么要怎么样做可以获取到 ansible playbook 中 command 模块的输出呢？ Ansible 也提供的解决办法，这时我们就可以通过使用 register 关键字来实现，register 关键字可以存储指定命令的输出结果到一个自定义的变量中，我们通过访问这个自定义变量就可以获取到命令的输出结果。Register 的使用很方便，只需要在 task 声明 register 关键字，并自定义一个变量名就可以。如下：
- name: echo date
command: date
register: date_output
- name: echo date_output
command: echo "30"
when: date_output.stdout.split(‘ ‘)[2] == "30"
这里第 1 个 task 是执行了一个 date 命令，register 关键字将 date 命令的输出存储到 date_output 变量名。第 2 个 task 对输出进行分析，并使用 when 对关键字对分析后的进行判断，如果匹配，则执行这个 task，不匹配就不执行。这里要重点说下的，因为 register 获取到的输出内容都是字符串，而 ansible 又是 python 写的，你可以使用 python 字符串的方法对其做处理，比如本文中使用的 split，还可以使用 find 方法。个人觉得，真是非常灵活方便。
这里由于条件匹配，两个 task 都执行了。然后把第 2 个 task 中的条件改动了下，使其不匹配，执行结果如下：
这里第 2 个 task 条件不匹配，skipping 了。
场景介绍：在对一组服务器 server_group1 执行操作过程中，需要在另外一台机器 A 上执行一个操作，比如在 A 服务器上添加一条 hosts 记录，这些操作必须要在一个 playbook 联动完成。也就是是说 A 服务器这个操作与 server_group1 组上的服务器有依赖关系。Ansible 默认只会在定义好的一组服务器上执行相同的操作，这个特性对于执行批处理是非常有用的。但如果在这过程中需要同时对另外 1 台机器执行操作时，就需要用到 Ansible 的任务委派功能（delegate_to）。使用 delegate_to 关键字可以委派任务到指定的机器上运行。在 playbook 的操作如下：
- name: add host record
shell: ‘echo "192.168.1.100 test.xyz.com" >> /etc/hosts‘
- name: add host record to center server
shell: ‘echo "192.168.1.100 test.xyz.com " >> /etc/hosts‘
delegate_to: 192.168.1.1
任务委派功能还可以用于以下场景：
Ansible 默认只会对控制机器执行操作，但如果在这个过程中需要在 Ansible 本机执行操作呢？细心的读者可能已经想到了，可以使用 delegate_to( 任务委派 ) 功能呀。没错，是可以使用任务委派功能实现。不过除了任务委派之外，还可以使用另外一外功能实现，这就是 local_action 关键字。
- name: add host record to center server
local_action: shell ‘echo "192.168.1.100 test.xyz.com " >> /etc/hosts‘
当然您也可以使用 connection:local 方法，如下：
- name: add host record to center server
shell: ‘echo "192.168.1.100 test.xyz.com " >> /etc/hosts‘
connection: local
这两个操作结果是一样的。
当以— check 参数来运行 ansible-playbook 时，将不会对远程的系统作出任何修改。相对的，任何带有检测功能的模块只要支持‘检测模式’将会报告它们会做出什么改变而不是直接进行改变。其他不支持检测模式的模块将即不响应也不提出相应的报告（事实上几乎所有主要核心模块都是支持‘检测模式’）。检测模式只是一种模拟。如果你的 playbook 是以先前命令的执行结果作为条件的话，那它可能作用就不明显了。但是在正式运行前，使用 check 模式做个语法检查也是不错的。
选择性执行 task-- Tag（标签）
您可能因为某些原因，会创建一个很大型的 playbook，但是你可能只想想运行其中特定部分的配置而无需要运行整个 playbook 。那么这时你可能需要用到 tag 功能。示例如下：
- name: yun install package
yum: name={{ item }} state=installed
with_items:
- httpd
- memcached
tags:
- packages
- name: configuration modity
template: src=templates/src.j2 dest=/etc/foo.conf
tags:
- configuration
如果你只想运行 playbook 中的”configuration”和”packages”，你可以这样做
ansible-playbook example.yml – tags “configuration,packages”
如果你只想执行 playbook 中某个特定任务之外的所有任务，你可以这样做：
ansible-playbook example.yml – skip-tags “configuration”
tag 特性是一个不错的功能，但如果真的是要维护一个大型的 playbook，还是建议将 playbook 按功能或应用拆分成多个 playbook，然后再在主 playbook include 其他子 playbook，这样即既利于维护也方便管理
Ansible 默认会检查命令和模块的返回状态，并进行相应的错误处理，默认是遇到错误就中断 playbook 的执行，这些默认行为都是可以改变的。
command 和 shell 模块执行的命令如果返回非零状态码则 ansible 判定这 2 个模块执行失败，可以通过 ignore_errors 忽略返回状态码（前提是要确定这 command 与 shell 执行错误不会影响后面 task 的执行）。如下：
- name: this will not be counted as a failure
command: /bin/false
ignore_errors: yes
命令不依赖返回状态码来判定是否执行失败，而是要查看命令返回内容来决定，比如返回内容中包括 failed 字符串，则判定为失败。示例如下：
- name: this command prints FAILED when it fails
command: /usr/bin/example-command -x -y -z
register: command_result
failed_when: "‘FAILED‘ in command_result.stderr"
ansible 会自动判断模块执行状态，command、shell 及其它模块如果修改了远程主机状态则被判定为 change 状态，不过也可以自己决定达到 changed 状态的条件，示例如下：
- name: copy in nginx conf
template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf
- name: validate nginx conf
shell: "/data/app/nginx/sbin/nginx -t"
register: command_result
changed_when: command_result.stdout.find(‘successful‘)
命令返回中有“successful”字符串，则为 changed 状态，下面这个设定将永远也不会达到 changed 状态。
- name: validate nginx conf
shell: "/data/app/nginx/sbin/nginx -t"
changed_when: false
本文介绍了一些关于 Ansible 的执行性能优化与 playbook 使用的技巧，这些都是在我们使用 Ansible 过程中需要面对的问题，希望今天列出的这些内容对大家学习和使用 Ansible 能有所帮助。
标签：open 时间 操作 问题 就会 程序 将不 多个 计时
原文地址：http://www.cnblogs.com/garfieldcgf/p/7000715.html
