Chinaunix

标题: 海量运维常用技术之---自动化运维工具选型及应用场景（获奖名单已公布-10-24） [打印本页]

作者: send_linux 时间: 2013-09-16 17:18
标题: 海量运维常用技术之---自动化运维工具选型及应用场景（获奖名单已公布-10-24）
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4102938-1-1.html

话题背景：
系统管理员经常陷入一系列的重复任务中：如升级软件包、管理配置文件、系统服务、cron任务以及添加新的配置、修复错误等，这些任务通常是重复低效的，解决这类任务的第一反应是让他们自动化，于是出现了定制脚本。环境复杂的场景中，定制脚本和应用程序一再被重复开发，并且很难适合多种平台，灵活性和功能也很难保证，于是魔术师Puppet 这样的自动化配置管理工具便出现了。而喜欢python的同学则喜欢用saltstack，saltstack是一个新的基础平台管理工具。很短的时间即可运行并使用起来, 扩展性足以支撑管理上万台服务器，数秒钟即可完成数据传递，经常被描述为 Func加强版+Puppet精简版；而Func是由红帽子公司以Fedora平台统一网络控制器，目的是为了解决这一系列统一管理监控问题而设计开发的系统管理基础框架。它是一个能有效的简化我们多服务器系统管理工作的工具，它很容易学习、很容易使用、也很容易被扩展，它功能强大而我们只需要非常少的配置和维护。

本期话题：
话题一：在自动化运维工作中，你较喜欢用哪种工具呢，puppet、saltstack还是func呢？它们的各自优势在哪里？
话题二：列举实例说明以上工具在工作中的应用。

本期嘉宾：
刘天斯  （phpcool）腾讯高级系统运维工程师
刘鑫（gray1982）高级系统运维工程师，CU集群和高可用版版主
余洪春（抚琴煮酒）资深项目实施工程师、系统架构师
崔晓辉（ coralzd ）  大众网高级系统管理员
刘晗昭（wenzizone）  高级架构师
胡安伟（king_819）系统运维主管，CU自动化运维版版主

活动时间：
2013.9.16-10.10

活动要求：
1、要言之有物，不能低于20个字
2、本次话题主要关注信息安全原理和实践方面的心得体会和使用技巧，其他问题可能不做重点

讨论有奖：
优秀讨论奖一名：奖励昂达2G MP3一个
积极参与奖四名：奖励脸谱开瓶器一个或者杯垫一套

作者: forgaoqiang 时间: 2013-09-16 20:01

抢个沙发坐坐~ 自动化运维只用过Puppet 相关经验较少坐着沙发看看大家都在怎么说~

作者: vnline 时间: 2013-09-16 21:04
本帖最后由 vnline 于 2013-09-16 14:20 编辑

puppet尝未入门...saltstack最近很火，而且国内开始形成一股先锋力量大力推广中，简单易上手以及配置灵活，模块开发入门门槛相对较低，必将成为运维的一大利器。。

作者: yuhongchun027 时间: 2013-09-16 21:06
saltstack 最近发现好多人都在用或在尝试用，特别是喜欢python的。

作者: yuhongchun 时间: 2013-09-16 21:08
提示: 作者被禁止或删除内容自动屏蔽

作者: vnline 时间: 2013-09-16 21:22

yuhongchun 发表于 2013-09-16 14:08
saltstack 最近发现好多人都在用或在尝试用，特别是喜欢python的，一不小心用马甲发言了，呵呵。

不过稳定性还不怎么好，有些小BUG，线上试用碰到过由于通信问题造成客户端进程爆增造成服务器死机的问题。。

作者: Gray1982 时间: 2013-09-16 21:37
saltstack 0.9版本在管理过50台服务器时所说内存溢出不知道新的版本怎么样
我这用的是puppet 2.7 管理的服务器也不多200台
一般都自己写模块，20个左右吧，就是用什么写什么
P的东西很多，也很全，感觉挺不错
本身也没感觉有什么难的地方
CU博客里有安装文档哦

作者: wenhq 时间: 2013-09-16 21:54
puppet是ruby写的
saltstack是python写的。
最近看新闻说某公司用saltstack管理20k+的机器。
顾虑的是puppet在如此大规模的机器中会好用么？

看好saltstack

作者: wlforyou1 时间: 2013-09-16 22:46
纯手工配置服务器，自动化工具，好像就没使用过。就弄过自动备份。其他都没使用过，也没接触过。发现自己真的很菜。

作者: chenryn 时间: 2013-09-17 07:42
puppet的状态收敛维护的思想非常喜欢，另外搭配了rex作为执行工具。
rex是perl写的集群自动化运维工具，其配置很类似puppet，不过他是通过SSH并发来工作的，所以更适合执行而不是状态维护。另一个特色是rex自带有对amazon啊，virt啊等云计算接口的支持。
http://rexify.org/

作者: xike2002 时间: 2013-09-17 09:04
这个话题好啊

作者: Gray1982 时间: 2013-09-17 11:29

wenhq 发表于 2013-09-16 21:54
puppet是ruby写的
saltstack是python写的。
最近看新闻说某公司用saltstack管理20k+的机器。

效率确实是个问题，不过只是说S管理20K+的服务器确实有点不具体，想知道S用多少机服务器来管理
像P单台不够时可以加多台，所以能有一个具体的架构对比就好了。

作者: 小飞侠xl 时间: 2013-09-17 12:04
现在运维还是一台台服务器搞得飘过~

作者: yuhongchun 时间: 2013-09-17 15:58
提示: 作者被禁止或删除内容自动屏蔽

作者: 小飞侠xl 时间: 2013-09-17 16:15
好的，我也慢慢学习一下，多谢。回复 14# yuhongchun

作者: seesea2517 时间: 2013-09-17 17:03
唉哟，这么多好工具要好好学学。目前还是手工写脚本，没遇到大项目需要用到工具的。这个见识到了高调华丽有档次的工具了，一定得学学好装。（此装非彼装

）

作者: tigerlsea 时间: 2013-09-18 09:14
都没用过，关注一下！

作者: kindule 时间: 2013-09-18 09:19
话题一：在自动化运维工作中，你较喜欢用哪种工具呢，puppet、saltstack还是func呢？它们的各自优势在哪里？
比较喜欢saltstack，配置管理+远程执行，因为是python写的，比较熟悉。
puppet已经是老牌配置管理工具了，相当成熟，
func目前还没接触过

话题二：列举实例说明以上工具在工作中的应用。

目前是用saltstack+git
管理了大概20台设备
git 作为前端版本控制，salt作为状态检查和命令执行来使用，杠杠滴

作者: haipeng110 时间: 2013-09-18 09:55
占了沙发，先试试看。

作者: myw58 时间: 2013-09-18 10:22
刚刚接触saltstack，感觉配置部署比puppet简单很多，配置也更好理解，目前只在10台机器的小范围内测试。
现在的确还存在一些不足，相信只是时间问题，随着社区的壮大，会不断完善。

作者: yuhongchun 时间: 2013-09-18 17:13
提示: 作者被禁止或删除内容自动屏蔽

作者: igkimm 时间: 2013-09-19 20:00
PRTG。PRTG。

作者: phpcool 时间: 2013-09-20 12:01
puppet没有在生产环境使用过，不做评论。
func在上一家公司作为基础服务部署，有500台左右的数量，总体而言还是比较稳定，只负责远程操作的功能，同时结合资产库再做一层UI封装，一个自动化的运维平台原型已经浮现，可满足日常60%的运维操作，那40%为啥没覆盖到？是的，func没有统一配置管理，程序、系统态的支持。
现引出saltstack吧，saltstack是今年7月份才接触，个人针对不同业务场景不同功能点进行了测试，结果符合预期。saltsatck非常强大、灵活，很多功能都没有做太死板的封装，都可以通过python api进行扩展。远程操作功能覆盖了func，还加入了更多的模块支持，更多见官网模块简介http://docs.saltstack.com/ref/modules/all/index.html#all-salt-modules，在程序配置方面，引入了公共与私有数据的不同角色，利用好可以动态配置灵活的程序配置规则，例子：基于saltstack实现的配置集中化管理，同时saltstack也支持系统程序包、系统态管理，良好执行返回接口、代理支持（master的容量扩展）、文件同步等等，更多特性大家有兴趣可以去挖掘http://docs.saltstack.com/(官网doc)、http://wiki.saltstack.cn/FrontPage（中文wiki），目前社区活跃度很高，在github提交的bug，1天内就有人跟进并给予回复。从长远来看，saltstack蕴藏着巨大的潜力，建议运维人员都可以关注下。之前在使用的0.16.0版本还存在bug或文档与程序描述不一致的地方，但升级到最新的0.16.4后功能上基本上都已经解决，官网文档也会第一时间完善，赞一个。

作者: yuhongchun 时间: 2013-09-20 14:49
提示: 作者被禁止或删除内容自动屏蔽

作者: kongjx_cu 时间: 2013-09-21 16:50
cfengine 为什么没有提起？

作者: kongjx_cu 时间: 2013-09-21 16:52
cfengine 以前用的，过5k以上服务器，包括教育网，联通和电信，做帐号同步使用，非常方便，不过是多台做集群架构，有总控服务器，在多线上放节点服务器，达到帐号同步目的。

作者: GB_juno 时间: 2013-09-21 21:07
之前有搞过chef+openstack，也考虑过puppet，运维自动化就那么点工具，把一样弄通就可以了。

作者: Purple_Grape 时间: 2013-09-21 22:56
本帖最后由 Purple_Grape 于 2013-09-21 23:07 编辑

偶用puppet管了几十台windows机器，总体效果还不错。

puppet 性能问题还是有点小头疼，客户端经常超时。

准备将puppet放本地跑，定期通过版本控制或者http/ftp等文件传输协议下载规则文件到本地执行，这样服务端就成了纯静态文件下载了，

对比C/S结构，功能虽然弱了，但自动化能力并没有减弱，仅仅是设想，还没实施。

saltstack 目前有点嫩，算是puppet的fork，虽然puppetlabs 被 vmware 通过投资控制了很大的话语权，但vmware不像oracle，没有作恶前科，属于开源友好型。

作者: chszs 时间: 2013-09-22 15:47
用过puppet，感觉简单易用。

作者: zhaopingzi 时间: 2013-09-22 16:50
这些东西没使用过啊，不好意思

作者: microsea 时间: 2013-09-23 11:29
虽然都还没深入使用，上手时第一感觉puppet需要针对hostname进行证书发放，saltstack只需要在minion的配置里面设置id即可，并且salt支持一台服务器设置多id（同时设上内网IP，多个别名），发放多个证书，这样操作起来比puppet灵活多了。

其他配置方面salt支持YAML格式更易于完全不懂python、ruby语言的同学使用。

都是好东西，需要继续学习

作者: alyfrisk 时间: 2013-09-23 11:56
回复 18# kindule

是自己搭的git服务器？

作者: zongg 时间: 2013-09-23 12:17

话题一：在自动化运维工作中，你较喜欢用哪种工具呢，puppet、saltstack还是func呢？它们的各自优势在哪里？

答：正在学习puppet 中，saltstack 和func 都没用过。。。
puppet 属于自动化的范畴，做运维的还是得会些。

话题二：列举实例说明以上工具在工作中的应用。

答：现在正在实验puppet 的rsync 模块，到时想放在线上应用。

作者: badb0y 时间: 2013-09-23 17:40
线上使用puppet管理100+台机器，主要是安装和配置管理，
实时执行命令一般都用fabric，这工具非常好用

作者: 代号：军刀 时间: 2013-09-23 17:53
看来我out了，这几个工具都没使用过，每次都是自己写脚本完成一系列操作。

作者: kindule 时间: 2013-09-24 10:09
本帖最后由 kindule 于 2013-09-24 10:09 编辑

是的呢
回复 32# alyfrisk

作者: alyfrisk 时间: 2013-09-24 10:26
回复 36# kindule

怎么搭的呢？有什么参考资料吗？

作者: kindule 时间: 2013-09-24 13:10
本帖最后由 kindule 于 2013-09-24 13:10 编辑

回复 37# alyfrisk

呵呵，就是把/srv/salt初始化成git working tree, 然后在clone一个git bare repository, 客户端与git bare repository同步, 通过git hook自动执行一些命令。。。

作者: aku1 时间: 2013-09-24 14:18
话题一：在自动化运维工作中，你较喜欢用哪种工具呢，puppet、saltstack还是func呢？它们的各自优势在哪里？
目前只测试过puppet,感觉还不错，只是ruby开发框架的对性能有一定担心
话题二：列举实例说明以上工具在工作中的应用
还在测试中计划部署puppet,以后在谈体会

作者: alyfrisk 时间: 2013-09-24 14:28
回复 38# kindule

git服务器是这么搭建的呀？我还以为类似svn那种搭建的方式呢！呵呵

作者: xiaochuanjiejie 时间: 2013-09-24 15:24

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

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

作者: xiaochuanjiejie 时间: 2013-09-24 15:27

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

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

作者: 一棵菠菜 时间: 2013-09-24 16:15
本帖最后由一棵菠菜于 2013-09-24 16:20 编辑

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

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

作者: kindule 时间: 2013-09-24 16:43
呵呵, git貌似没有明确的集中是repository
回复 40# alyfrisk

作者: pxf520 时间: 2013-09-25 11:01
本帖最后由 pxf520 于 2013-09-25 11:04 编辑

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

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

作者: mcshell 时间: 2013-09-30 14:51
我们用IBM的 BuildForge{:3_190:}

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

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

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

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

作者: zzfzqq 时间: 2013-10-12 10:25
推荐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吧！仅供大家参考，有问题请帮忙指出谢谢！

作者: loveguo7 时间: 2013-10-21 21:29
cfengine puppet fabric saltstack 都折腾使用，至于那个好用，主要看业务需求。

作者: wtoppp 时间: 2013-10-21 23:40
stack 的监控机制目前有哪些？怎样监控部署过程中的成功也失败状态？？回复 8# wenhq

作者: gavindev 时间: 2013-11-11 13:56
我做的是业务运维，正在尝试使用salt，

推送命令，管理配置文件非常方便，已经在管理nginx配置文件了

puppet也尝试了几天，可能是我用得不熟，上手还是有点麻烦

作者: francisjohn 时间: 2013-11-23 02:59

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

感谢分享

作者: sgysz 时间: 2013-11-23 22:51
回复 7# Gray1982

写的些模块能贡献一下不？

作者: sgysz 时间: 2013-11-23 22:53
回复 7# Gray1982

写的些模块能贡献一下不？

作者: Gray1982 时间: 2013-11-28 11:43
回复 61# sgysz

根据自己实际用的写比较方便

作者: tonyzhang828 时间: 2014-09-20 22:25
我们公司从去年开始就在生产环境推进saltstack的实施。当初选择salt的一个很重要的因素就是python编写，适合扩展。
一个公司总有些属于自己的运维特性，必然会带来不少二次开发。我们现在除了用saltstack来进行配置管理、批量执行外，还自行开发了UI界面（目前官方的太挫），并结合公司的ITIL流程进行服务器上下线变更的自动化处理。

当然现在的saltstack在大量client的环境下还是有不少bug（前台显示问题、对底层对zeroMQ调用的问题），但我觉得国内的氛围已经起来了，未来的前景看好

PS：目前我们还在研究ansible，有使用经验的同行可以交流下

作者: jixuuse 时间: 2014-09-22 10:41
话题一：在自动化运维工作中，你较喜欢用哪种工具呢，puppet、saltstack还是func呢？它们的各自优势在哪里？

目前正在用的是pssh，主要用来作远程命令执行。我这边linux主要做编译服务器，因此配置很少变动，sdk经常需要拷贝和修改。
有大概8台左右VM在做saltstack的测试，因为自己用python比较多，因此感觉很好用，yaml也很好理解。

话题二：列举实例说明以上工具在工作中的应用。
系统初始化时用的比价多，还有就是批量远程执行

作者: coffee_45 时间: 2014-10-15 15:46
我觉得Cacti+Nagios比较好用，大家不要以为Cacti只是snmp，在我公司服务器环境中，我的Cacti监控脚本都是直接利用的Nagios的nrpe插件，部署一次Nagios，以后就可以给Nagios和Cacti监控使用了，而且比snmp的udp协议更可靠。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)