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

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

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

如图为简单的发布流程，其中涉及到运维操作的有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均可在最大化不更改运维操作习惯的前提下完成业务的(工具)自动化发布。

优点： 

◆沟通成本小

◆约束点少

缺点：

◆冗余模块变多

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

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

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