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的基础介绍到此结束。
#p#
第二章：跨”种族”业务发布自动化之路
开始之前，先为小白们普及下发布流程。
如图为简单的发布流程，其中涉及到运维操作的有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均可在最大化不更改运维操作习惯的前提下完成业务的(工具)自动化发布。
优点：
◆沟通成本小
◆约束点少
缺点：
◆冗余模块变多
◆运维维护成本大，复杂程度增加。
◆来简单对比下代码差异化程度。
可以看出差异化地方只在执行的服务器和进程管理的各类。
#p#
再来看看代码量。
第四章：练就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. 为方便各位第一时间接受最新技术前沿，我们成立运维部落微信订阅号，除了每日分享，定期更新外，还有大虾不定期解惑，欢迎关注！
