分类目录归档:Ansible

ansible之三自定义模块

接上篇内容,等我们熟悉了ansible playbook后,已经能满足我们日常的运维工作了,而且大大减轻了我们的工作压力,在这个阶段,你已经熟练掌握了ansible的各种模块,并能快速根据业务配置playbook,那从运维角度我个人觉得对ansible掌握是比较不错的了,当然但如果想更深入的了解,那就要学习我们今天讲的ansible api了,了解api,就可以从底层了解ansible的运行机制,当然直接去看ansible源代码也是不错的选择,所以说api其实是为开发人员准备的,通过api接口,开发人员可以自定义一些ansible的模块,今天我们就来看一个小例子来学习如何自定义ansible模块,大家也别对自定义模块感到很深奥,其实深奥的业务逻辑,本身ansible api调用是比较容易的,基本思路是这样,先定义我们的模块脚本,然后通过ansible api来调用,开始前让我们先了解下我们例子的需求:

需求:我们有批机器,领导需要看到每台机器每个挂载点实时的磁盘可用空间和总的可用空间之和,其实这个需求我们脚本可能都实现烂了,不夸张的说闭着眼睛都能写出来,但我们今天来看看如何用ansible来实现,先写我们定义的模块mydf.py文件,内容如下:

这个mydf.py就是自定义的模块,脚本不解释了,如果有不理解的给我留言,完成这个模块后,我们将它拷贝到/usr/share/ansible/下,具体为什么放到这个目录我们待会说,我们先看如何调用这个模块,这就用到ansible的api,具体代码如下:

 

这个脚本中我们用到了ansible的runner api,在modle_name中指定了我们自定义模块的名字,其它内容不多说了,看注释就能明白了,如果有问题可以给我留言,这样就可以运行了吗?如果你在终端输入:

发现会报错,没有发现这个模块,这是因为自定义的模块需要在ansible配置文件中指定,打开/etc/ansible/ansbile.cfg文件,找到library,把注释去掉,修改成如下:

注:版本不同可能会有所差异

这样再运行就没有问题了,当然文中我只给了个比较简单的例子,主要是大家学会这种自定义模块的方法,实际工作中可以根据自己的业务编写符合自己的业务模块,到此呢,三篇关于ansible的学习之旅就全部结束了,经过这三篇的学习,希望对大家有所帮助,如果有什么疑问可以给我留言,当然如果觉得不错,还请帮忙转发,在此谢过。

Ansible入门之Playbook

上一篇我们介绍了常用的ansilbe模块,如果熟练掌握了这些模块,你以为这就精通了ansible,那就大错特错了,anislbe的精华还没开始呢,当然熟练掌握模块是基础,接下来我们就要学习playbook,什么是playbook呢,可以说之前我们学习的那些模块都是ansible系统的基础组件,而playbook通过灵活的组装这些组件,可以实现更为复杂的业务操作场景,所以呢,playbook就是ansilble的另一种运行模式,除了直接命令行调模块,真正在线上展示威力的还得依靠playbook,那么这篇我们就来通过例子来介绍如何使用,开始前我们先假设一个场景:

最近不知道领导的脑袋里那两个脑触突然碰到了一起,突然今天跟部门开会说,我们部门要搭建一个技术博客,把咱们的技术都沉淀下来,环境呢我看也别太复杂,就选择wordpress就行,哪个同事给搭建下,这时你发现大家的目光都聚集到了你这里,别想了,就是你了,全桌就你一个干运维的,这活铁定你干,接下来开始准备服务器(也可能就是台式机什么的),服务器安装好系统后,你ssh进入系统(当然如果你装了windows,这篇文章到这你就不用看了,省下的时间重装完系统再回来看也不迟,反正我也不会删),开始下载所需的软件nginx,mysql,workdress,php-fpm,然后开始编译安装,过程不在赘述,经过几个小时,你终于搞定了,领导来审查,拍着你肩膀说,小四五呀,做的不错,这么快就搞定了,就在你心底一乐,腰板刚要挺直,感觉自己光芒万射的时候,领导突然说,咱们客户那边还有2000台机器要安装wordpress环境,你去帮你一起安装下吧,小伙子能干,明天下班前可以把? 这时你的cpu粗算了下,搭一个环境预计二小时,2000台就是4000个小时,4000个小时就是166天,卧槽,半年过去了,还没算自己吃饭睡觉,XX的时间,这时你弱弱的跟领导说,2年行不? 领导沉稳的反问了你一句:你小子打算去财务交工牌么?。故事到此结束,这个故事只是了解下背景,当然写的有点夸张,所以喜欢较劲的朋友在后台留言的时候千万别问我,”为什么不写脚本完成这个需求?“,那样的话我只能默默的关闭你的留言了,顺便问一句,咱还能好好一起坐友谊的小船么?

背景有点长了,我们进入技术阶段,那我们用ansible如何完成上面的需求呢,我们就来看如何组装我们的模块吧,因为ansible用的是yaml语言,如果有不了解的自己补补,在这就不多说了,在开始前我们先来了解几个概念:

var:ansible里变量的概念是重用某些定义值,主要是模板会用到。

tasks:任务就是按配置文件的定义的去执行的操作。

handlers:当被操作的主机配置发生改变时要进行的操作,这里需要通知它,然后handlers定义的动作会被执行。

了解了这三个,我们再了解一个概念role,role在ansible可以将任务等模块化了,使他们复用性更强,概念介绍到这里,如果以上没完全理解也没关系,我们一会看实际的例子就明白了,了解了以上概念,就可以给出出整体的配置文件目录结构了,这样大家先有一个大致的框架,接下来我们我们再一一讲解。

以上就是整体的目录结构,还有2个文件没介绍,hosts是要操作的主机组或ip,site.yml是playbook的入口文件,定义了主机,角色等,内容如下:

这里看到了我们定义的4个角色,每个角色会对应完成自己的功能,我们一会再说,先从头看起。

group_vars,目录下的all定义了所有的变量,内容如下:

这些定义的值都是给模板传值用的,一会就会看到。

我们看来每个role的定义,common是通用的role,就是表示其他角色都可能用到的可以放这里,common有点特殊,它有个file目录,主要是存储一些服务器需要的系统配置文件,要拷贝到目标服务器上,然后tasks,handlers就比较熟悉了,我们先看tasks目录,这个目录下只有一个文件,定义了要完成的任务,内容如下:

注意看最后一句notify,这条语句表示iptables配置文件变更后,通知restart iptables ,这个定义在然后看handler的main.yml,下:

 

如果理解了common,那以下几个模式基本都一样了,我们来看看mysql目录的内容,

tasks目录下的main.yml文件:

handlers/main.yml:

templates/my.cnf.j2:

这里我们说2个内容,一个是with_items,这是常用的循环方法,这个语句下的内容会依次传入{{ item}}来替换item,第二个说下模板,my.cnf.j2里的内凡是{{ }}的内容都在group_var/all里做了定义,顺便说下,ansible模板文件用的jinja2的模板,如果有了解flask的肯定会理解,jinja2是flask框架默认的模板,想深入了解的,自己可以补补。

php-fpm内容,php-fpm/tasks/main.yml:

handlers/main.yml:

templates/wordpress.conf :

这部分没特殊的,不多说了,大家看看配置文件了解下即可。

最后一个workpress/tasks/main.yml;

templates/wp-config.php:

wordpress模板基本都是wordpress的配置,没什么特殊要讲的,到这里,我们基本就讲完了ansilble的playbook的一个实例配置,如果你要问,配置这么一大堆,到底怎么运行呀,运行命令是这样地:

#ansible-playbook -i hosts site.yml

就可以运行了,如果机器多就并发去做,ansible都可以支持,这篇文章就到这里,这是系列2,还剩最后的开发篇,我们下篇见。

Ansible从入门到精通(一)

现在做运维的估计都对ansible不陌生了,如果还没有使用过的,我建议尽快尝试下这个技术,入门非常简单,一旦你运用熟练,将大大减轻运维工作的压力,ansible只需要在主控端安装,客户端无需做任何操作即可对被控端进行批量操作,这也是相对于saltstack的一个优点,saltstack除了在主控端安装外,客户机要安装客户端,其它不多说了,如果有兴趣的可以百度,这种文章已经满大街都是了,回到正题,今天这篇我们还是主要来介绍介绍ansible如果在运维中的应用,本来我刚开始打算用一篇来完成对ansible的介绍,在实际写的过程中才发现,如果只用一篇来写,那篇幅就会非非常的长,为了让大家阅读起来不那么痛苦,我最后决定分三篇来写完,三篇分别介绍ansible的常用模块,然后讲解playbook配置,最后介绍ansible的api,这篇是开头篇,所以暂不涉及python的编码工作,学习起来也比较轻松,废话不多说了,我们接下来开始我们的正题:

首先,我们安装ansible

然后输入个Y,就完成了,就是这么简单。

安装完,我们说下基本的配置,运行命令:

我们看到有2个文件和1个目录,,其它先不用管,我们先只看hosts文件,用vi打开,除[webservers],[dbservers]这两行外,其它全部注释掉,这二行的作用的定义主机组,主机组名下可以写成员主机的IP(或域名),我们可以把的客户机的IP放到[webservers]主机组下,这样,定义主机和组的规则就算完成了,接下来进入我们模块学习部分。

不得不说ansible的模块真是丰富,基本上我们日常运维用到功能全部都有了,运行命令:

可以看到全部的模块名称,对模块的使用还是要看业务场景,比如你如果没有在aws上机器,那么像ec2你也不会用到,所以今天我们就只会对日常运维最常用的模块做说明,剩余的模块可以根据自己的业务用到了,再去学习了解,我们在讲模块前,会先给出每个模块的应用场景,方便大家快速上手使用:

场景1:需要在客户机上执行命令,可以用command模块,命令如下:

其中webservers是主机组名称,在该主机组名称下的所有主机都会运行uptime命令,-m后是模块名称,-a 后是模块参数,后续命令都基本一个模子,不再赘述。

场景2:需要执行客户机上的脚本,可以用shell模块,命令如下:

场景三:脚步在主控端,但需要在客户机上执行,可以用script模块,命令如下:

请注意,你主控端/root/下必须有local.sh脚本。

场景四:文件发布,这种需求很多,比如日常的配置文件更新,程序版本发布等,基本都会用到,可以用copy模块:

注意我这里xl2pdf是个目录。

场景5:想在客户机上安装软件,可以用yum模块,这个用的还是挺多的,比如用ansible去链接低版本的centos时,就乎出现”ansible requires a json module, none found! “的错误,需要远程机安装samplejson包。

raw是什么鸟?莫急,我们看看帮助文档怎么说:

第一句就说明了问题,raw模块是靠底层ssh的通讯,不依靠python的模块,所以如果碰到低版本的系统,如果command和shell模块无法使用,可以先用这条命令安装完需要的包。

场景6:重启客户机服务,可以用service模块:

对服务操作有started,stopped,restarted,reloaded四个参数。

以上主要的模块就说完了,还有ping模块,setup模块(获取远程主机信息),cron模块等大家可以按以上模块使用的思路去参考运行,不知道怎么使用的,就看看帮助文档,这篇就到这里了,下篇我们开始聊聊如何将这些模块组合起来满足更复杂的业务操作,这就要用到我们的playbook了,先不多说,我们下篇见。