标签：自动化运维 自动化工具
现在运维圈子里都流行利用各个自动化工具进行运维，个人感觉，这些只是一个噱头，是一些培训机构利益获取的幌子，也是各个运维人员提高身价的砝码，本身并没有什么。
对于大批量的系统运维，不外乎几大业务场景：
1、统一配置管理
（如批量更改服务器的某个参数，批量上传一个文件，批量更改服务器的一个文件）
有人说puppet可以做得很好，其实，写个循环脚本，针对每一个ip，执行一个实现配置功能shell脚本
（ssh可以实现远程更改一个参数，远程更改一个文件，scp可以实现upload一个文件），是一个件easy的事情，我为什么要耗费精力去学习、配置puppet，且不说puppet的安装可能还需要其他依赖的包。
至于说puppet具备版本控制功能，其实就是个鸡肋。在生产环境中，所有系统所做的配置（变更）都会走流程（变更单号），要追朔某个系统的配置变更过程，只需要在“变更管理平台（每个公司的叫法可能不一样）”以关键字（如系统名，业务名，ip，变更项）检索即可。
So，我为什么要用puppet等之类的工具？
2、远程命令执行
（如批量检查服务器的配置参数）
ssh命令完全可以实现该功能，至于批量执行，也不过是在ssh的外层，套一个循环结构而已。所以，我为什么要用func来进行远程命令执行。
至于saltstack（实现了puppet和func的功能），配置麻烦，既然shell都能实现，我为什么要用它？
3、交互过程的自动应答
对于一些需要运维人员手动输入的交互过程（如对于没有配置ssh互信的机器的登录，需要input密码，该业务场景发生在配置ssh互信阶段，一旦ssh互信成功，就可以用普通脚本了），expect工具，python的pexpect模块，都能实现。
对于大量服务器的操作系统的安装，pxe+kickstart稍显麻烦，但是cobbler其实也没有简单到哪里去。再说，对于IDC而言，采购的服务器都是由供应商负责上架，系统安装（或者推送），IP设定、扎线等。
4、批量部署服务器（web server，app server，db server）
现在都是用云平台如OpenStack直接创建，然后跑后置脚本进行服务器软件的安装、配置等。交付的产品都是各种软件都已经配好
标签：自动化运维 自动化工具
原文地址：http://dannyswallow.blog.51cto.com/5062777/1740104
