刚刚看了金山梁晓聪的"在AWS上的运维自动化实践分享",发现技术都是相通的,大家都是用最好的技术。我们的业务平台主要也是AWS云计算平台,尝试了许多自动化运维/配置工具,最后还是选终了Ansible。下一步在公司运维自动化DevOps要做的工作:增大Ansible在系统中的应用比重,真正跟AWS结合起来。选择Ansible主要因为丰富的相关支持,包括很多现有的组件和模块和开源的Ansible部署和脚本。笔者也尝试了市面上所有自动化运维和自动化配置工具,发现Ansible是对AWS支持得最好的一个。Ansible的开发过程是写大量 Playbooks。现在Ansible支持的有251个模块,特别是对于云服务的支持。像AWS、Docker、OpenStack,部署脚本都放在一个子目录下。这就意味着把别人写的脚本拿过来,或者把别人写定义的Playbook拿过来非常容易。现在关于Ansible的开源脚本数量庞大,3000多个项目,我相信这个数字只会越来越多,这意味着以后的很多DevOps工作会越来越简单容易。

  找到 Ansible 的过程(套用下云巴张虎的原话,因为我们的过程很类似)

       最早我们用 SSH 写很多脚本,要用 SSH 连过去,也是在某一台机器上执行,不用在目标机上登陆。这种做法在相当一段时间内是我们实际使用的手段,它实际上比 Puppet 有效。但是它有一些问题:管理成本高、脚本会越来越多。部署的过程有很多的基础部件需要反复部署,几乎是没法管理。后来我们用了 RunDeck,它有界面、有一定的管理能力。我们还用过 Fabric,即批量执行命令,能做到类似部署的事情。但是,目标机规模大了之后仅有管理的能力是不够的。后来我们又调研过 Salt,不认为有太大的差别。选择 Ansible 主要因为丰富的相关支持,包括很多现有的组件和模块和开源的 Ansible 部署和脚本。我们的团队不喜欢纠结。我们发现 Ansible 没有太本质的区别,就开始用起来。如果没有明确理由,我们就凭感觉选一个用。

       Ansible 是通过 SSH 连接到目标服务器,上面这两个东西是我想了很久,我希望去拥有的特性。一个是完整的集群,只需要有一个 inventory 去定义,写出清单就可以定义集群。每一个角色的具体功能有若干 playbooks 来定义。


wKiom1fADtDRO0t2AAA16826P6k317.jpg-wh_50