结合Ansible在AWS云计算平台上实现运维自动化

桀昊j

　　刚刚看了金山梁晓聪的"在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 来定义。