Ansible playbooks

Playbook是Ansible的配置，部署和编排语言。 他们能够描述您但愿远程系统执行的策略，或通常IT流程中的一组步骤。

若是Ansible modules是您workshop的工具，则playbooks是您的说明手册，您的主机inventory是您的原材料。

在基本层面上，可使用playbooks来管理远程机器的配置和部署。 在更高级别，他们能够对涉及滚动更新的多层次推出进行排序，并能够将操做委派给其余主机，与监控服务器进行交互，同时加载平衡器。

虽然这里有不少信息，可是不须要一次就能够学习全部的东西。 随着时间的推移，您能够开始小型化，随时随地选择更多功能。

playbooks旨在让人可读，并以基本的文字语言开发。 能够经过多种方法来组织playbooks和他们包含的文件，咱们将提供一些建议，并充分利用“可复制”。

建议您阅读“ Playbook ”文档，同时阅读“ 示例手册” 。 这些说明了最佳实践以及如何将许多各类概念集中在一块儿。

关于Playbooks

Playbook是一种与adhoc任务执行模式彻底不一样的方式，并且特别强大。

简单地说，Playbooks是一个很是简单的配置管理和多机器部署系统的基础，不像任何已经存在的那样，并且很是适合部署复杂的应用程序。

Playbook能够声明配置，但它们也能够协调任何手动订购过程的步骤，即便不一样的步骤必须在特定订单的机器组之间来回弹起。 他们能够同步或异步地启动任务。

虽然您能够运行主/usr/bin/ansible程序来进行自组织任务，可是Playbook更有可能被保留在源代码管理中，并用于推出配置或确保远程系统的配置符合规范。

还有一些完整的剧本能够在ansible-examples存储库中说明不少这些技术。 咱们建议您在另外一个标签中查看这些内容。

在学习剧本以后，还有不少跳跃点，因此在完成本节以后，请回到文档索引。

Playbook Language Example

Playbook以YAML格式（见YAML Syntax ）表示，并具备最少的语法，它有意尝试不是编程语言或脚本，而是一个配置或进程的模型。

每一个playbook由一个或多个“plays”组成。

一个play的目标是将一组主机映射到一些明肯定义的roles，由事件可调用的任务表明。 在基本层面上，一个任务只不过是对一个能够粘贴的模块的调用（参见关于模块 ）。

经过编写多个“plays”的playbook，能够协调多机器部署，在Web服务器组中的全部计算机上运行某些步骤，而后在数据库服务器组上执行某些步骤，而后在Web服务器组等上再次执行命令。

“plays”或多或少是体育比喻。 你能够有不少戏剧影响你的系统作不一样的事情。 它不像你只是定义一个特定的状态或模型，你能够在不一样的时间运行不一样的play。

对于初学者来讲，这是一个仅包含一个play的playbook：

---
- hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf notify: - restart apache - name: ensure apache is running (and enable it at boot) service: name=httpd state=started enabled=yes handlers: - name: restart apache service: name=httpd state=restarted 

当使用具备很长参数的任务或具备许多参数的模块时，能够经过多行将任务项目中断以改进结构。 如下是上述示例的另外一个版本，可是使用YAML字典为它们的key=value参数提供模块：

---
- hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: name: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf notify: - restart apache - name: ensure apache is running service: name: httpd state: started handlers: - name: restart apache service: name: httpd state: restarted

Playbook能够包含多个play。 您可能有一个Playbook首先定位到Web服务器，而后是数据库服务器。 例如：

---
- hosts: webservers remote_user: root tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf - hosts: databases remote_user: root tasks: - name: ensure postgresql is at the latest version yum: name=postgresql state=latest - name: ensure that postgresql is started service: name=postgresql state=started

您可使用此方法在您要定位的主机组，登陆到远程服务器的用户名，是否要sudo之间进行切换。 play，像任务同样，按照playbook中指定的顺序运行：从上到下。

Basics

Hosts and Users

对于Playbook中的每一个play，您能够选择您的基础设施中的哪些机器进行定位，以及什么远程用户完成步骤（称为任务）。

hosts行是一个或多个组或主机模式的列表，以冒号分隔，如“ 模式”文档中所述。 remote_user只是用户账户的名称：

---
- hosts: webservers remote_user: root

还能够为每一个任务定义远程用户：

---
- hosts: webservers remote_user: root tasks: - name: test connection ping: remote_user: yourname

支持做为其余用户来运行（请参阅Become (Privilege Escalation) ）：

---
- hosts: webservers remote_user: yourname become: yes

您也可使用成为特定任务而不是整个play：

---
- hosts: webservers remote_user: yourname tasks: - service: name=nginx state=started become: yes become_method: sudo

您也能够登陆，而后成为与root不一样的用户：

---
- hosts: webservers remote_user: yourname become: yes become_user: postgres 

您还可使用其余权限升级方法，如su：

---
- hosts: webservers remote_user: yourname become: yes become_method: su
若是须要指定sudo的密码，请使用或使用旧的sudo语法 （  ）运行 。 
若是你运行成为playbook，而且playbook彷佛挂起，它可能会停留在特权升级提示符下。 只要控制C来杀死它并再次运行，添加相应的密码。
您还能够控制运行主机的顺序。 默认是按照inventory提供的顺序：
--ask-become-pass--ask-sudo-pass-Kansible-playbook

- hosts: all order: sorted gather_facts: False tasks: - debug: var=inventory_hostname

order的可能值为：

inventory:

  默认值。 该order是由“inventory”提供的

reverse_inventory:

  顾名思义，将inventory提供的顺序反过来了

sorted:

主机按名称的字母顺序排列

reverse_sorted:

反向

shuffle:

Hosts are randomly ordered each run 主机每次运行随机顺序

Tasks list

每一个play包含一个任务列表。 任务按顺序执行，一次一个地执行与主机模式匹配的全部计算机，而后再转到下一个任务。 重要的是要明白，在一个playbook中，全部的主机都要获得相同的任务指令。 play的目的是将选择的主机映射到任务。

当运行从上到下运行的playbook时，失败任务的主机将从整个playbook的旋转中取出。 若是事情失败，只需更正playbook文件并从新运行。

每一个任务的目标是执行一个很是具体的参数的模块。 如上所述，变量能够在模块的参数中使用。

模块应该是幂等的，也就是说，按顺序运行一个模块屡次应该具备同样的运行效果。 实现幂等的一种方法是使模块检查其所指望的最终状态是否已经实现，而且若是该状态已经实现，
则在不执行任何动做的状况下退出。 若是一个playbook所使用的全部模块都是幂等的，那么这个playbook自己就有多是幂等的，因此从新运行这个playbook应该是安全的。
command和shell模块一般会从新运行相同的命令，若是命令相似于或等，则彻底能够。尽管有一个可用于建立这些模块的标志也是幂等的。
每一个任务都应该有一个 ，它包含在运行该play的输出中。 这是人类可读的输出，所以提供每一个任务步骤的良好描述是有用的。 若是没有提供名称，则将“feed”的字符串用做输出。
可使用旧版格式声明任务，但建议您使用更常规的格式。 在整个文档中使用了这种推荐的格式，可是您可能会在某些playbook中遇到较旧的格式。
这是一个基本的任务。 与大多数模块同样，服务模块采用参数：
chmodsetseboolcreatesnameaction: module optionsmodule: optionskey=value

tasks: - name: make sure apache is running service: name=httpd state=started 

command和shell模块是惟一获取参数列表而不使用表单的模块。 这使得他们按照你所指望的方式工做：key=value

tasks: - name: enable selinux command: /sbin/setenforce 1

command和shell模块关心返回代码，因此若是你有一个成功的退出代码不为零的命令，你可能但愿这样作：

tasks: - name: run this command and ignore the result shell: /usr/bin/somecommand || /bin/true
或这个：

tasks: - name: run this command and ignore the result shell: /usr/bin/somecommand ignore_errors: True
若是行动线太长了，你能够在一个空间上打破它，并缩进任何延续线：

tasks: - name: Copy ansible inventory file to client copy: src=/etc/ansible/hosts dest=/etc/ansible/hosts owner=root group=root mode=0644
变量能够在动做行中使用。 假设您在部分中定义了一个名为的 ，您能够这样作：
varsvhostvars

tasks: - name: create a virtual host file for {{ vhost }} template: src=somefile.j2 dest=/etc/httpd/conf.d/{{ vhost }}

Action Shorthand

可选择在0.8及更高版本中列出这样的模块：

  template ： src = templates / foo.j2 dest = / etc / foo.conf 

您会注意到在早期版本中，这只能用做：

  action ： template src = templates / foo.j2 dest = / etc / foo.conf 

旧的表单继续在较新的版本中工做，没有任何弃用的计划。

Handlers: Running Operations On Change

如上所述，模块应该是幂等的，而且能够在远程系统上进行更改时进行中继。 Playbook认识到这一点，并有一个基本的事件系统能够用来响应变化。

这些“通知”动做在play中每一个任务块的末尾触发，只有在多个不一样任务通知时才会被触发一次。

例如，多个资源可能代表apache须要从新启动，由于它们已经更改了一个配置文件，但apache只会被triggered一次以免没必要要的从新启动。

如下是当文件内容更改时从新启动两个服务的示例，但仅当文件更改时：

- name: template configuration file template: src=template.j2 dest=/etc/foo.conf notify: - restart memcached - restart apache

任务部分列出的内容称为处理程序。
处理程序是由全局惟一名称引用的任务列表，与常规任务彻底没有任何区别，并由通知程序通知。 若是没有通知处理程序，它将不会运行。 不管经过处理程序有多少任务，在全部任务在特定的play中完成后，它将只运行一次。
这是一个示例处理程序部分：
notify

handlers: - name: restart memcached service: name=memcached state=restarted - name: restart apache service: name=apache state=restarted
至于Ansible 2.2，处理程序也能够“listen”通用主题，任务能够通知这些主题以下：

handlers: - name: restart memcached service: name=memcached state=restarted listen: "restart web services" - name: restart apache service: name=apache state=restarted listen: "restart web services" tasks: - name: restart everything command: echo "this task will restart the web services" notify: "restart web services"

这种使用能够更容易地触发多个处理程序。 它也使处理程序与名称分离，从而更容易在剧本和角色之间共享处理程序（特别是当使用像Galaxy这样的共享源的第三方角色时）。

角色将在后面描述，但值得指出的是：

• 在pre_tasks ， tasks和post_tasks部份内通知的处理程序将在通知的部分的末尾自动刷新;
• 在roles部份内通知的处理程序将在roles部分结束时自动刷新，但在任何tasks处理程序以前。

若是您想要当即刷新全部处理程序命令，在1.2及更高版本中，您能够：

tasks: - shell: some tasks go here - meta: flush_handlers - shell: some other tasks

在上述示例中，任何排队处理程序将在达到语句时提早处理。 这是一个niche的例子，但能够不时地派上用场。
meta

Executing A Playbook

如今你已经学会了Playbook的语法，你如何运行一个playbook？ 这很简单。 让咱们用10级的并行度来运行一个playbook：

ansible-playbook playbook.yml -f 10

Ansible-Pull

若是你想反转Ansible的架构，那么节点就能够检查到一个中央位置，而不是把配置推送给他们，你能够。

ansible-pull是一个小脚本，能够从git检出配置指令的备份，而后针对该内容运行ansible-playbook 。

假设您负载平衡您的checkout位置，基本无限可ansible-pull秤。

运行ansible-pull --help帮助详细信息。

还有一个clever playbook能够经过推送模式下的crontab来配置安全性。

Tips and Tricks

要检查playbook的语法，请使用带有--syntax-check标志的--syntax-check ansible-playbook 。 这将经过解析器运行playbook文件，以确保其包含的文件，角色等没有语法问题。

查看playbook执行的底部以获取目标节点的总结以及它们的执行状况。 通常失败和致命的“不可达到”的通讯尝试在计数中保持分开。

若是您想查当作功模块以及不成功模块的详细输出，请使用--verbose标志。 这在可用0.5和更高版本中可用。

若是安装了cowsay包，可靠的剧本输出将大大提高。 尝试一下！

在运行它以前，要查看playbook会受到哪些主机的影响，您能够执行如下操做：

  ansible-playbook playbook.yml --list-hosts