海量运维常用技术之---自动化运维工具选型及应用场景（获奖名单已公布-10-24）

xiaochuanjiejie

yuhongchun 发表于 2013-09-17 15:58
可以先多用Kickstart和python,shell脚本，后期再尝试用puppet.

目前我就是使用Kickstart和python,shell脚本运维，初试了puppet，加了几个群跟大虾们沟通结果都需ruby基础。。。我想不浪费时间，直接转saltstack，因为有python基础，抚琴意见如何？指点一二吧

xiaochuanjiejie

phpcool 发表于 2013-09-20 12:01
puppet没有在生产环境使用过，不做评论。
    func在上一家公司作为基础服务部署，有500台左右的数量， ...

坚定了我使用saltstack的信心，ruby本来就不熟悉，python还好

一棵菠菜

saltstack肯定会替换掉puppet，P安装和操作各种复杂，salt简单，轻便，
最喜欢的的神奇的命令slat -E HOST cmd.run 'COMMAND'  这是神器，哈哈

salt组的观念，多ID，可以让你在不通的项目之间随意操作，就算是项目有交叉也游刃有余，心动了吗，大家一起搞起啊

kindule

呵呵, git貌似没有明确的集中是repository
回复 40# alyfrisk


   

pxf520

系统初始化类：kickstart、cobbler等
配置管理类： puppet、cfengine、bcfg2、chef、saltstack等
自动发布类：capistrano、jenkins等

工具只是手段，能实现目的就行，毕竟它是为我们所用，精一样就好，不要为了工具而用工具。
我用的是chef & capistrano，2者都是基于ruby，前者用于管理（配置文件、服务运行状态、软件包文件、目录、批量执行命令、用户、角色、 crontab 、mount、deploy etc），后者主要用于应用的发布、回滚。
在系统初始化的时候会自动安装chef的client，加入配置管理以及监控系统。
基本的运维工作就完成一半了，剩下关注的层面就是分布式日志的收集、分析、预警等等，目前已实现了分布式日志实时分析系统与nagios的联动。
再接下来，就是根据业务所在服务器的压力情况，自动上下线应用等等。这样可以节省一大部分时间，提高工作效率，相信这也是以后运维发展的趋势，向高智能、自动化方向发展。

mcshell

我们用IBM的  BuildForge{:3_190:}

lyblyc121

支持salt,只是在没有外网环境下安装比较麻烦（好多包安装有冲突，可能是我们环境问题），不过整体来看功能还是很强的，我们之前使用自己的python脚本维护的功能在salt下都能实现，最喜欢的还是他的插件功能，因为目前我的所有工具都是python写的，改起来很容易

woxizishen

1.管理的linux服務器不多，沒有使用這些工具。不過現在都比較喜歡將服務器虛擬化。貌似直接克隆比上述工具更快捷。。。。。。。我們公司服務器基本上都虛擬化了。
2.windows服務器基本上是通過腳本自動維護。

jimin_lee

目前用puppet管理3K服务器，就现在的使用经验来说。puppet并不是我想要的。puppet的主体思想是客户端去master取catalyst，如果master需要将一些命令推到客户端，可能就需要MC等来完成了。就我现在的工作来说，很多操作是我想主动推，而不是由服务器的客户端来取。salt从此种角度上，正好满足了我的要求。但是salt的不足是目前我还没有找到能够媲美puppet的dashboard。目前我使用的foreman，很不错。

总体说，puppet配套产品比较成熟，但是salt比较适合我的胃口，有较大的发展前途。

zzfzqq

推荐puppet，个人使用的心得
1）服务器标准化部署，包括网络配置、工具的安装部署、系统内核优化配置、计划任务的配置等标准化服务器的部署工作
2）适合具备一定规模的服务集群部署维护，比如tomcat cluster、java服务端集群、邮箱服务器集群等等。每个集群的规模都不是很大，可是所有集群加起来管理，快捷高效性就体现出来了。
3）部署和维护：服务的启停控制、新包发布、补丁发布、配置文件集中管理。我简单说下我做的控制过程，一个包管理中心，用于存放所有待管理的包；一个class public文件，包含了按服务名称区分的class；一个node文件，用于存放所有节点信息；一个site.pp(主要是用于存放变量，然后根据变量的值控制class public下的不同的服务) ；一个puppet-dashboard，用于日志的管理；最后一个就是总控制程序，这个是自己编写，用于对整个puppet 主动部署和维护的控制。这是一个包管理的结构，配置文件的管理会略有不同。

4）puppet管理方便之处就是它维护的是状态，而不是过程。所以我们不必写很多执行的过程，比较便于配置，针对这个设计一个好的管理框架，全部模块化，使用起来还是很方便的。当然，执行过程还需要一些额外的脚本支持或者使用系统中已经实现的。

5）我们运维最终要解决是什么呢？其实就是减少工作量，让所有的工作自动化完成。那么做到这一点，就两个途径，一个自己编写一套自动化工具；一个就是使用现有开源的工具。puppet属于后者，所以想要做的更好就心学习下它的开发语言ruby了，二次开发或许更能满足你的需要，至少可以在遇到bug时能自己分析下 呵呵！我个人属于python爱好者，可我还是先推荐puppet吧！仅供大家参考，有问题请帮忙指出 谢谢！