首先给出文档的版本：2.7
然后是使用的Ansible版本:ansible 2.4.2.0

Each playbook is composed of one or more ‘plays’ in a list.

The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks.
一个play的目标是映射一组主机组为一些定义明确的角色，（这些角色）由ansible所谓的tasks所代表。

Playbooks are expressed in YAML format and have a minimum of syntax, which intentionally tries to not be a programming language or script, but rather a model of a configuration or a process.

Each playbook is composed of one or more ‘plays’ in a list.
也就是说，整个YAML文件就是多个play的YAML列表，而每个play都是一个YAML字典。

##############一个play开始#####################
- hosts: web
#这是一个play的最小化定义（只制定了一个hosts字段）
#hosts的值不能为空
#主机名或者IP必须在/etc/ansible/hosts中定义过 
##############一个play结束#####################
##############一个play开始#####################
- host: 172.16.1.31
##############一个play结束#####################

一个play的重要字段有：

• hosts（YAML字典）
• tasks(YAML列表)
• handlers（YAML列表）
• pre_tasks（暂时未知）
• post_tasks （暂时未知）
  注意，notify是task的列表项。

下面是其说明：

1. hosts line is a list of one or more groups or host patterns, separated by colons.

2. The remote_user is just the name of the user account.Remote users can also be defined per task.

3. tasks:

   Each play contains a list of tasks.Tasks are executed in order, one at a time, against all machines matched by the host pattern, before moving on to the next task. It is important to understand that, within a play, all hosts are going to get the same task directives. It is the purpose of a play to map a selection of hosts to tasks.

   The goal of each task is to execute a module, with very specific arguments. Variables, as mentioned above, can be used in arguments to modules.

   Tasks can be declared using the legacy action: module options format, but it is recommended that you use the more conventional module: options format. This recommended format is used throughout the documentation, but you may encounter the older format in some playbooks.

   Every task should have a name, which is included in the output from running the playbook. This is human readable output, and so it is useful to provide good descriptions of each task step. If the name is not provided though, the string fed to ‘action’ will be used for output.

   Here is what a basic task looks like. As with most modules, the service module takes key=value arguments:

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

   The command and shell modules are the only modules that just take a list of arguments and don’t use the key=value form. This makes them work as simply as you would expect:

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

   忽略错误的两种方式：

   tasks:
     - name: run this command and ignore the result
       shell: /usr/bin/somecommand || /bin/true
       #或者
       ignore_errors: True
   

4. handlers:

   The things listed in the notify section of a task are called handlers.

   Handlers are lists of tasks, not really any different from regular tasks, that are referenced by a globally unique name, and are notified by notifiers.

   其实，notify就是一个事件注册器，而handler也是task。
   那么，几个问题，第一，可以在全局注册事件还是只能在task内部注册事件？
   经测试，只能在task内部注册事件，因为：
   ERROR! 'notify' is not a valid attribute for a Play
   第二，如果有多个task绑定了某个handler，handler会被多次执行么？
   第三，task和handler的执行顺序是怎样的？

   If nothing notifies a handler, it will not run. Regardless of how many tasks notify a handler, it will run only once, after all of the tasks complete in a particular play.

   如果一个task需要绑定多个handler，使用listen语法。
   最后，一些注意事项：

   • Notify handlers are always run in the same order they are defined, not in the order listed in the notify-statement. This is also the case for handlers using listen.
   • Handler names and listen topics live in a global namespace.
   • If two handler tasks have the same name, only one will run. 说明连接
   • You cannot notify a handler that is defined inside of an include. As of Ansible 2.1, this does work, however the include must be static.

5. pre_tasks和post_tasks

遗留问题：

handlers notified within pre_tasks, tasks, and post_tasks sections are automatically flushed in the end of section where they were notified;

联系上文所说，

Regardless of how many tasks notify a handler, it will run only once, after all of the tasks complete in a particular play.

如果一个handler在pre_tasks和tasks中都被nofite了，那么它会被执行几次？