带你揭开运维自动化的面纱：Ansible业务自动化之路(1)
2016-02-20 19:33:59   来源： 李松涛 马哥Linux运维    评论：0 点击：

1.作者介绍

2008年开始接触linux，之后一起从事linux相关工作，先后就职于上海woyo、腾讯、汇联、诺亚等企业，马哥教育特约讲师。

2.主题介绍

30分钟带你揭开运维自动化的面纱-Ansible业务自动化之路

难度指数：2星(满星5星)

技术指数：4星(满星5星)

理论指数：3星(满星5星)

面向人群：运维~技术流

本次分享重点：跨“种族”业务发布自动化之路

其中：练就18式，拿下自动化。时间关系本次不做重点讲解，后续会做为系列分享进行。

3.分享内容

第一章、情定Ansible

和谈男女朋友一样，如果不对眼再漂亮的对象也白搭，如果相互不了解，再牛也有被当成是拍黄片(PHP)的时候。

我选择PHP的原因，sorry，我选择Ansible的原因有如下几个方面：

1.去中心化

作为 Ansible 发展至今的核心优势极具竞争力，最大的优势是人人皆可成为三军将领，迁移非常方便，要求也很简单，python 2.6+、pip/yum/apt简单的几条命令即可全盘搞定。据称该特性也会一直坚持下去，不确认是不是基于这个原因红帽才下决心收购了Ansible 呢(个人推断也是“轻”的缘故)。无论如何作为一个新秀，如此成绩实在惊为天人。

2.简单

和saltstack/puppet不同，不用class等高级语法即可满足业务日常所需；虽然devops是新一代运维必备，但万丈高楼平地起，devops也非简单几日就能信手拈来。

和fabric不同，无需懂python任何语种即可快速上手掌握；好吧！也不得不承认 fabric 是开发同时的最爱，几行简单的代码无需改变习惯就能完成心中所想，但应对项目日趋复杂，对开发能力要求也不断提高，且维护成本指数增加。

最后，用官方原话形容Ansible简单的特性：Stupid simple。

3.友情搜索 

众所周知，未来是关系搜索的时代。身边朋友的实践体验也是极为重要。想到saltstack，puppet不停反馈出来的问题，心中也是略有阴影，当然也不排除Ansible问题还没有暴露出来的可能。

4.“大势所趋” 

想想XEN，KVM，有了奶妈的支持，高低立显。继Ansible之前自动化工具虽如雨后春笋，但未来还不一定“鹿死谁手”。

更多： 

对比参见 黄博文 http://www.cnblogs.com/huang0925/p/4664608.html

ok！Ansible的基础介绍到此结束。

第二章：跨”种族”业务发布自动化之路

开始之前，先为小白们普及下发布流程。

如图为简单的发布流程，其中涉及到运维操作的有8步。相对脚本化，Ansible更多程度上：1.降低了上手难度；2.保障了自动化质量；3.健壮了可扩展性。

举个例子：

PHP/Java项目的发布就底层而言有非常大的不同和实现机制，同时由于开发同学多样化需求，针对多套环境如何保障运维发布操作单一化、简单 化，Ansible的实现方式非常针对性的考验运维同学思维深度和全面性。Ansible在设计之初侧面帮了运维同学不少忙，你会发现在运用的过程中会不 自主的靠着Ansible的“规则”来,当然这些规则对运维架构框架是有利的。下面的例子简单来分析看看：

如图为我们当前业务的发布方式，现在还处于脚本自动化阶段，比较lower。 

化零为整

Ansible一次完整的发布可以非常灵活的按模块拆分，场景：

针对测试环境不希望人工参与的背景下：化零为整，一键部署。

化整为零 

针对正式生产环境操作繁多变更不定的背景下：化整为零

Ansible的模块化 & tags 功能轻松驾驭

有朋友当然会反问，上面我写个脚本轻松搞定。 

确实，我们后面会讲到，请稍安勿躁！

运维同学SHELL脚本是必备技能，相比较devops而言，SHELL脚本的学习成本和上手难度几乎为零。再回头看Ansible的发布方式，结合SHELL脚本的参数调用，有没有觉得似曾相识，改变一个人的习惯何其难，所以Ansible playbook简单是运维的福音。

Yml语法清晰明了，规则简单，99%的功能都是一行命令即可实现。Ansible自带冥等判断机制也省去运维不省逻辑判断伤脑费心的人脑运算。

写playbook的过程就是一个思维整理的过程。

太过复杂的思维在写的过程中会无意中被简化。

好的，上面的内容大家可以先消化1min。

第三章： 不同“种族”业务Ansible的处理方式

以PHP/JAVA多项目为例，有如ppt所示问题：

公司现有PHP项目近10个，JAVA项目也纳入运维管理，后期也可能不断融入新项目，如何保证1.现有操作习惯不变改变；2. 简单一致的发布操作。

越来越具挑战。

起初希望通过git命名规范来实现简化发布操作，但随之发现不可能，原因如下：1.影响合作部门已有工作习惯；2.约束力太多阻力也在不断加大；3.沟通成本大；4.非核心功能开发支持力度不及自力更生来的快。

最终方案：

多一层判断和roles模块，通过git的变量名来定义git拉取地址。

这个用ansible来实现简单是易如反掌。

如此以来php，java均可在最大化不更改运维操作习惯的前提下完成业务的(工具)自动化发布。

优点： 

◆沟通成本小

◆约束点少

缺点：

◆冗余模块变多

◆运维维护成本大，复杂程度增加。

◆来简单对比下代码差异化程度。

可以看出差异化地方只在执行的服务器和进程管理的各类。 

再来看看代码量。 

第四章：练就18式，拿下自动化

基础模块13式

作为基础模块，熟悉掌握即能完全驾驭ansible日常工作90%自动化工作，简单指数5星。 

辅助模块5式

拥备基础模块，同时配合辅助模块可使已有成果更上一层楼，简单指数 4星。 

第四章：AnsibleUi -jumpserver

话说自动化怎么能停留在工具时代，但 tower 又收费，如何破?

jumpserver 完全开源的，堡垒机功能日趋完善，自动化发布平台底层也基于 Ansible 实现，更多精彩可参考http://jumpserver.org/ 。

最新功能： 

第五章：后记分享目录

分享目录及方式参考

参考http://www.178linux.com/doc/ansible/翻译的内容按功能模块结合业务实践以场景化方式逐一讲解。

问题反馈路径 http://www.178linux.com/qa/重复收看 http://www.osstep.com。

群友Q/A

问题1：发布为啥是用ansible去打包的?

最小化最简化原则，运维需要懂的工具很多，需要熟练不会太多，精一通百的人毕竟少数，精力也是有限，就如用阿里云，ucloud就推荐使用他们的“四大件”。

问题2：ansible在上千机器的集群中有没有瓶颈?

这个我如实回答，我知道的还没有。数百台的应用是有的。但我觉得RedHat都不担心这个问题，我们更不需要担心，看看kvm,docker的发展就是指导。

问题3：ansible在win上只支持nt不支持2003 如何解决？

A：只能说是所有开源软件的通病，windows闭源已经深知其中的痛点，近些年不是一直有传言会开源吗?哈哈！

问题4：ansible在上千机器的集群中有没有瓶颈?

有瓶颈，一次在千台以上建议salt，万台建议go自己写，主要是消息回收master受不了。

问题5：我想知道部署的时候，有没有向移动端发展的趋势!

A：有，前沿的大公司已经在用，如鹅厂，jumpserver.org也在首面放在 mobile的daemon。

　　问题6：感觉ansibie异常的时候不好排错！有没有好的方法?

A：这样问是因为你还不熟悉，多被磨磨就好。python的报错输出和shell一样简单。见过JAVA的复杂日志输出会深有体会，看完我们开发同学输出的日志再看ansible的报错输出是觉得好幸福。哈哈！

问题7：我们可否跟监控服务器联动，一旦执行出错马上报警，并且让系统提供出错日志。

A：ansible本身提供mail alert功能，你可以把ansible日志记录到syslog里面，用ELK 或者splunk来实现报警。

Ansible原著翻译团队

联系人：stanley (微信号: fengzhilinux) 5. Ansible专题分享，请把你想听到的想学到的录入到 http://www.178linux.com/qa/。

Ansible部落

致力全球流行技术本土化

运维部落---Ansible部落群功能：1. Ansible的翻译工作马上就要结束进行最后的 review 阶段，你知道吗?2. 为方便各位第一时间接受最新技术前沿，我们成立运维部落微信订阅号，除了每日分享，定期更新外，还有大虾不定期解惑，欢迎关注！

【编辑推荐】