Roles
New in version 1.2.
你现在已经学过 tasks 和 handlers，那怎样组织 playbook 才是最好的方式呢？简单的回答就是：使用 roles ! Roles 基于一个已知的文件结构，去自动的加载某些 vars_files，tasks 以及 handlers。基于 roles 对内容进行分组，使得我们可以容易地与其他用户分享 roles 。
一个项目的结构如下:
site.yml
webservers.yml
fooservers.yml
roles/
common/
files/
templates/
tasks/
handlers/
vars/
defaults/
meta/
webservers/
files/
templates/
tasks/
handlers/
vars/
defaults/
meta/
一个 playbook 如下:
---
- hosts: webservers
roles:
- common
- webservers
这个 playbook 为一个角色 ‘x’ 指定了如下的行为：
注意只有在各个main.yml文件中的（task，variables）等才会
添加到play中，才在这次play的流程中
- 如果 roles/x/tasks/main.yml 存在, 其中列出的 tasks 将被添加到 play 中
- 如果 roles/x/handlers/main.yml 存在, 其中列出的 handlers 将被添加到 play 中
- 如果 roles/x/vars/main.yml 存在, 其中列出的 variables 将被添加到 play 中
- 如果 roles/x/meta/main.yml 存在, 其中列出的 “角色依赖” 将被添加到 roles 列表中 (1.3 and later)
- 所有 copy tasks 可以引用 roles/x/files/ 中的文件，不需要指明文件的路径。
- 所有 script tasks 可以引用 roles/x/files/ 中的脚本，不需要指明文件的路径。
- 所有 template tasks 可以引用 roles/x/templates/ 中的文件，不需要指明文件的路径。
- 所有 include tasks 可以引用 roles/x/tasks/ 中的文件，不需要指明文件的路径。
在 Ansible 1.4 及之后版本，你可以为”角色”的搜索设定 roles_path 配置项。使用这个配置项将所有的 common 角色 check out 到一个位置，以便在多个 playbook 项目中可方便的共享使用它们。查看 Ansible的配置文件 详细了解设置这个配置项的细节，该配置项是在 ansible.cfg 中配置。
上次给大家介绍了ansible的基础命令，一些基本的常用模块，今天就给大家带来ansible的进阶版本，playbook，以及roles的使用。
首先我们要知道我们的ansible的playbook是什么？playbook就是剧本的意思，用于配置，部署，和管理被控节点，剧本怎么写，操作怎么执行，很容易理解。
通过playbook的详细描述，执行其中的一系列tasks，可以让远端主机达到预期的状态。playbook就像Ansible控制器给被控节点列出的的一系列to-do-list，而被控节点
必须要完成。
首先我们先介绍一下ansible playbook的格式。
1 YMAL格式是类似于JSON的文件格式，
2 文件的第一行应该以 "---" (三个连字符)开始表明YMAL文件的开始;
3 在同一行中，#之后的内容表示注释，类似于shell，python和ruby;
4 YMAL中的列表元素以”-”开头然后紧跟着一个空格，后面为元素内容;
5 同一个列表中的元素应该保持相同的缩进。否则会被当做错误处理。
既然是YMAL格式的文件，后缀就理所当然的为yml，所以在yml文件中，主要有三个部分组成：hosts、remote_user、tasks。
hosts：使用hosts指示使用哪个主机或主机组来运行下面的tasks
remote_user：指定远端主机中的哪个用户来登录远端系统
tasks：指定远端主机将要执行的一系列动作，tasks的核心为ansible的模块，前面已经提到模块的用法。tasks包含name和要执行的模块，name是可选的，只是为了便于用户阅读，不过还是建议加上去，模块是必须的，同时也要给予模块相应的参数
除上面一些主要之外，还有tags和notify、handlers，tags是打标签，而后可在ansible-playbook命令上使用-t指定进行调用，tags在哪，剧本从哪里开始；某任务的状态在运行后为changed时，可通过“notify”通知给相应的handlers。
这样以介绍是不是感觉对playbook的格式有了大致的了解了呢？
下面我们来介绍一下，关于playbook执行后得到的输出信息，可以用来帮我们判断成功与否。
一般而言
l 绿色代表执行成功，系统保持原样
l ×××代表系统代表系统状态发生改变
l 红色代表执行失败，显示错误输出。
执行有三个步骤：1、收集facts 2、执行tasks 3、报告结果
之后是关于变量的一些定义和使用，和shell一样，有系统变量和自定义变量，但当我们使用变量是可以使用{{ VAR }},记得要在两边有空格，定义的方式有4中。
(1) facts：可直接调用；注意：可使用setup模块直接获取目标主机的facters；
(2) 用户自定义变量：
(a) ansible-playbook命令的命令行中的
-e VARS, --extra-vars=VARS
(b) 在playbook中定义变量的方法：
vars:
- var1: value1
(3) 通过roles传递变量；
(4) Host Inventory
(i) 向不同的主机传递不同的变量；
IP/HOSTNAME varaiable=value var2=value2
(ii) 向组中的主机传递相同的变量；
[groupname:vars]
variable=value
运行playbook的方式：
(1) 测试
ansible-playbook --check 只检测可能会发生的改变，但不真正执行操作；
ansible-playbook --list-hosts 列出运行任务的主机；
(2) 直接运行
下面我们做一下playbook的小实验，给两台下属主机，安装nginx，并且，当检测到nginx配置文件更改后，重启服务，此实验共三台主机，只需要一台安装ansible即可。
首先要定义两个主机为一个web组内，vim /etc/ansible/hosts
[web]
172.17.254.112
172.17.254.113
其次，生成密钥，发送给其他两个主机，实现无密登录(具体操作可以瞅瞅我的ansible的基本知识详解。
然后我们就要做一个yml的剧本了，内容如下：
新版博客的缩进不是很方便，我就直接放了一张图，这是从安装，到启动，到拷贝本机的修改文件到其他机器，然后根据notify触发handlers，重启nginx服务。
然后听过ansible-playbook test.yml执行，结果应该如下：
至此我们的playbook的编辑到结束已经完成，只要我们制定好hosts，然后定义一下，方便我们以后看的name，再之后就是我们的动作，利用各个模块，来做好一件大任务！
playbook虽然看起来挺方便的，但是有个弊端就是无法实现复用假设在同时
部署Web、db、ha 时或不同服务器组合不同的应用就需要写多个yml文件。很难实现灵活的调用。
roles应运而生，roles 用于层次性、结构化地组织playbook。roles 能够根据层次型结构自动装载变量文件、tasks以及handlers等。
与其说playbook把所有的模块功能，集合一起做事情，对于相同的事件，或者不复杂任务，可以胜任，roles就是把模块又拆了出来，哪一块都可以随时替换，应对各种复杂情况。
文件目录结构：
roles/nginx/
├── default
├── files
├── handlers
│ └── main.yml
├── meta
├── tasks
│ └── main.yml
├── templates
└── vars
└── main.yml
这是我把刚才那个实验用roles来做的目录结构图，vars明显是变量，我们定义了一个变量，tasks是任务，handlers，是当notify触发时的一些任务，当然我们还要有yml剧本，这个剧本里可以写入我们的角色。
nginx.yml
roles/nginx/handlers/main.yml
roles/nginx/tasks/main.yml
roles/nginx/vars/main.yml
上面就是我们的定义的文件，当我们使用nginx.yml启动时，发现和刚才一样的效果，不过当我们的变量需要改变，或者tasks改变时，我们就直接找到对应的文件，直接修改，而不是一行行的去找整个剧本，还要通读一遍。
出处：http://blog.51cto.com/13296640/2048436