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 红色代表执行失败，显示错误输出。
　　  执行有三个步骤：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改变时，我们就直接找到对应的文件，直接修改，而不是一行行的去找整个剧本，还要通读一遍。