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

  

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