自动化运维软件设计实战-所感

今天利用了大概一小时的时间翻看完了《自动化运维软件设计实战》

这本书在思路上面给我提供了很大的帮助和借鉴，最近打算搭建一套运维平台。这本书开篇前三章介绍了Ansible，Puppt以及SaltStack，这三个运维工具都是可以单点主机操作多点客户端，就是操作多个机器像操作单台主机一样。Ansible的思想即使无入侵式的，同时SSH协议，来操作目标主机，而且是主动通知各个目标主机做事情；Puppet则是需要部署agent，而且下发操作的思想是我把声明写好后公开，各个agent定时过来取；Puppet在管理海量节点的时候会有性能问题；第三个就是SaltStack，集合了Ansible和Puppet的长处：既可以SSH，也可以agent，另外SaltStack相比较于Ansible和Puppet是重量级集中式运维工具：因为他引入了ZeroMQ，master和minion之间通信是ZeroMQ，实现前后台解耦，同时还保证了任何一点挂掉，都不影响消息被后续执行。

貌似有着各种强大的集中运维工具，但是笔者最终还是决定了自研一套运维系统，因为项目需求比较坑：Window+Linux混搭，装Ansible被Over了，部分机器没有安装GCC，没有安装python和Ruby，这样Puppet和Saltstack被Over了（Puppet采用Ruby编写，Saltstack采用Ruby编写，SaltStack采用都需要GCC进行编译安装组件）；安装也不太现实，因为机器数量太大，而且有的机器还连不了外网。于是笔者实现了一套类似于SaltStack的工具；采用OSGi技术开发，容器选用的是Karaf（我之前使用的是Fliex），采用的理由是热部署可以完全自动进行（Felix需要通过命令行来搞），但是代价就是这个Krafa的组件竟然达到了30M，要知道Flex才10M。消息中间件选用的是ActiveMQ（为什么不是RabbitMQ呢？）

最后一章，作者祭出Zabbix。运维其实是分三个层次，了解，决策以及执行；其中了解就是获知信息，决策就是根据获知的信息决定下一步做什么（条件分支），执行就是来执行决策；Zabbix就是做了解层和决策层的，集中式运维工具就是做执行层的内容。和Zabbix交互的方式就是在Zabbix中做配置，当触发了某个调用OSGi条件，将会通过脚本向ActiveMQ中发送一条消息，这个时候OSGi作为消费者来监听ActiveMQ的主题，发现有告警，则会触发相应的操作。