触发器：
一个任务同时调用多个触发器：
为远程主机上的用户设置环境变量：
保存前一步命令的输出结果，并保存到foo中：
添加环境变量的另一种方式：
注意：lineinfile模块只适用于修改少量环境变量的情况。如果要修改大量的环境变量，请使用copy模块和模板。
如果任务量变多，或者环境变量变多，则需要在playbook中的var区块定义环境变量。
playbook中的变量：
ansible-playbook example.yml --extra-vars "foo=bar"
ansible-playbook example.yml --extra-vars "@even_more_vars.json"
ansible-playbook example.yml --extra-vars "@even_more_vars.yml"
vars.yml的格式如下：
顶格写。
ansible的内置环境变量，可以通过setup模块查看到。
使用场景：根据ansible的内置环境变量来判断如何执行。
为CentOS系统定义一个变量配置文件：apache_CentOS.yml，内容为apache: httpd
为Debian系统定义一个变量配置文件：apache_default.yml，内容为apache: apache2
在inventory文件中定义变量：【不建议这么做】
在group_vars目录下，按照组名创建文件，然后填写变量。
在host_vars目录下，按照主机名创建文件，然后填写变量。
注意：组名和主机名是根据/etc/ansible/hosts文件中的内容来的。
假如给app1.example.com这台主机设置一组变量，则需要先创建/etc/ansible/host_vars/app1.example.com文件，
然后将变量填写到里面即可。
在app1.example.com文件中填写内容如下：
假如给shanghai这组主机设置一组变量，则需要先创建/etc/ansible/group_vars/shanghai文件，然后将变量填写到里面即可。
注册变量：将操作的结果，包括标准输出和标准错误输出，保存到变量中，然后再根据这个变量的内容来决定下一步的操作。
数组变量或列表变量：
取值时，用python语法：
foo_list[0]
foo_list[1]
foo_list[2]
用jinja语法：
foo_list|first
/etc/ansible/group_vars/all文件：给所有组设置变量。
/etc/ansible/host_vars/all文件：给所有主机设置变量。
Facts信息：
在运行任何一个playbook之前，ansible默认会先抓取playbook中所指定的所有主机的系统信息。这些信息称为Facts。
ansible all -m setup
查看所有主机的系统信息
ansible db -m setup
只查看db组中主机的系统信息
收集系统信息是耗费时间的，如果想节省这笔时间，可以关闭收集功能。
关闭之后就收集不到信息了。
实际使用中，用的比较多的Facts变量有ansible_os_family、ansible_hostname、ansible_memtotal_mb，这些变量通常
当做when的判定条件。
在远程主机自定义facts变量：
在远程主机上创建/etc/ansible/facts.d/settings.fact文件，内容为：
然后在ansible服务端上执行：
通过filter=ansible_local参数，就得到了自定义的变量。
注意：在任何远程主机的/etc/ansible/facts.d/目录下可以创建任意*.fact文件，文件格式可以是JSON格式、ini格式，或者是一个返回
JSON的可执行文件。这种动态的自定义变量只能用于临时需求，还是推荐将各种变量定义在ansible服务器端上。
变量优先级：
1、命令行中用--extra-vars或-e定义的变量。
2、inventory中定义的关于连接的变量（比如ansible_ssh_user）。
3、命令行转换、play中的变量、included中的变量、role中的变量。
4、inventory中定义的其他变量。
5、facts变量。
6、role默认变量。
变量定义原则：
1、role中定义的变量应尽量合理。因为它是最后的一层保护门。其他门被攻破了，才会来找它。
2、尽量不要在Playbook中定义变量，而是通过引用变量文件来使用变量。
3、只有与主机强关联的变量才定义在inventory文件中。
4、尽量避免在命令行上使用-e选项来定义变量，除非是做测试。
jinja2的语法示例：
1 in [1, 2, 3]
'see' in 'can you see me'
foo is defined
如果jinja2不能满足要求，就用python的内置方法来补充。
变量注册器：
大部分情况下，使用变量注册器来接收shell命令的返回结果。结果中包含标准输出和标准错误输出。
my_command_result.stdout 标准输出的内容
my_command_result.stderr 标准错误输出的内容
when条件判断：
很多任务只有在特定条件下才执行。
只有在when条件满足时才会执行yum。
when语句和注册变量的结合。
判断一个应用的运行状态，并判断返回的状态值，状态为ready后，再执行下一步操作。
最后一个例子中，如果远程主机不存在/etc/hosts文件，就从ansible服务器端复制一份到远程主机。
这里使用的是stat模块，用于判断文件的状态。
changed_when 什么时候返回changed，如果不用这个，那么ansible将永远返回changed。（不管三七二十一，全部返回changed，加了changed_when后，需要满足条件才会返回changed）
failed_when 什么时候返回failed，也就是满足一定条件后才会返回failed。
当执行命令后，返回的结果中如果含有Nothing to install or update，说明已经有了，此时不会有危险。因为安装过了，所以不再变化，
因此返回的changed为false。
如果在里面，说明已经有了，暂时不用再管了。
如果不在里面，说明可以安装。安装之后，说明可以返回changed了。也就是说有条件地返回changed。
当import.stderr有内容时，且already exists不存在于其中，才算失败failed。
可以在相关任务中添加ignore_errors: true来屏蔽错误信息，以免不太重要的错误影响全局大业。但尽量少用，我们不能放任错误信息，
而应该解决问题。
任务委托：
比如给某台服务器发送通知或向监控服务器中添加被监控服务器。
使用delegate_to关键字便可以配置任务在指定的机器上执行，其他任务依旧按照hosts的规定。
如果想让一个任务在ansible服务器本地运行，可以委托给127.0.0.1，也可以用local_action来完成。
每隔10s检查一次主机webserver1上面的80端口是否开启，如果超过300s，80端口仍未开启，将返回失败信息。
这里使用的是wait_for模块。这里相当于是一个校验确保的措施，保证服务确实开启了，才去执行后面的步骤。
交互式提示
虽然有些值可以存储在文件中，但是有些用户的需求不一样，所以需要用户自己来填写。
给playbook中的部分任务打上标签，这样我们在执行时，可以有选择性地进行执行，而不是一股脑的全部执行。
只执行Notify on completion任务。（我们根据标签来）
ansible-playbook tags.yml --tags "say"
我们这里是根据标签来挑选的。
跳过某些任务（也是根据标签名来跳过）
ansible-playbook tags.yml --skip-tags "notifications"
为每个任务添加合适的标签，在执行时就可以有选择性地执行，而不是全部执行。
在任务比较多时，可以适当添加标签，对于任务比较少的playbook，就不要添加较多的标签。
block块
根据when中的条件来决定使用哪个block。block将一组相关的任务组成一个块，这样就可以给它们统一设置参数了。
同时，不用给每个任务都单独设置when条件了。
块功能非常适用于多个任务共用一套任务参数的情况。