linux运维学习之ansible的playbook及roles的使用

  上次给你们介绍了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 红色表明执行失败，显示错误输出。
  执行有三个步骤：一、收集facts 二、执行tasks 三、报告结果
  以后是关于变量的一些定义和使用，和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改变时，咱们就直接找到对应的文件，直接修改，而不是一行行的去找整个剧本，还要通读一遍。