讨论：如何同步上百/千台服务器的某一个配置文件？（获奖名单已公布-2012-9-6）

jiaolt

回复 67# Gray1982


    多线程也挺好，我用的是python,python多线程，不能真正利用多核cpu.
    我尝试最快的一次，开次几百个进程，几千台服务器，大概20秒搞定。
   

bettydreamit

lollollollol  puppet

busyant

个人的理解，欢迎探讨指正。

首先，上千台server规模已经很大了，个人觉得一个管理员能support的服务器上限是500台。因为自动化程度再高的环境，也会有很多突发情况需要处理的：网络不稳定，监控报警的处理，还有公司内部的各种case都可能要管理员从特定server上取数据。所以假定需要2-3个管理员。
所以，日常运维使用脚本批量的方法并不可取：

• 太过依赖管理员技术水平，不利于知识的传递。shell script很牛的人，可能不懂perl。perl很牛的人可能不懂python，python很牛的人可能从来没用过expect。有人可能会开玩笑说这样子公司就不敢开你了，但是，如果你是升迁呢？找个和你一样牛的人真的很难的，你会发现工作交接真的很头大！
• 维护工作千变万化，脚本随时可能做修改，调试成本高，出错的风险也大。一次错一千台，看老板怎么骂死你！
• 随着时间的推移，脚本会越来越多，越来越长，工作交接的问题又来了。最后你可能自己都记不清test_run.sh 是用来干嘛的了。
• 管理员写脚本的习惯，也会成为知识传递的问题。命令不加注释，缩进不规范，爱用管道，超级长的命令组合写在同一行。
• 服务器信息的维护。为了跑脚本，每个server至少需要维护一个IP列表。新增、修改、删除随时都可能发生，错漏的情况必然会发生。还会有冲突的情况，A的脚本没跑完，B就需要修改这个文件.....
• 部分server脚本运行失败时，手工干预麻烦。试想如果1000台中有80个server运行失败了，你怎么办呢？一台台登陆上去再跑一次脚本？
• 其他未知问题.....
  

所以我比较推崇使用已经成熟的管理工具，我目前用的是CFEngine。Puppet我没用过，各有优势吧。目前puppet貌似还不支持修改文本文件，要更新某个文件只能完整copy。

使用这种工具的好处：

• 只需要学习一种知识。只需要学习CFEngine的语法，就能看懂并且管理所有的控制文件。
• 安全和效率有保障。像CFEngine之类的管理工具，server 和 client之间的交互支持加密，文件的copy只需要再checksum不匹配的情况下发生。也可以很简单的修改配置文件中的某一行。
• 无痛实现server的增删改。定义好role和对应的policy之后，新增的server只需要加入到这个role，所有的policy自动下发实现。
• 策略应用失败自动报告。这类工具一般都内置汇报机制，policy运行失败，自动发送邮件通知（或其他方式）。
• 提供成熟的配置检查方法，根据进程，文件（目录）内容、权限等检查的结果，自动运行对应的策略。
  

个人觉得第一条最重要了。确保了知识的有效传递。对公司、工作和自己的职业道德都是负责任的表现。

当然脚本批量化也不是不能用，在处理突发事件时，脚本批量操作是非常有效和及时的。

先说这么多，等待同学们拍砖！

-----------
对了，上面只说了 system admin 的工作。
实际上，还有业务部署这块的内容，也是自动化的一个主题。比如web game需要发布一个新版本到所有web server上去，那就要从代码库里面取出代码，然后打包、部署到所有server、校验，解包，复制、改权限、重启web service等等。可能需要另外一套工具来实现。
-----------

flw

busyant 发表于 2012-07-10 11:56
个人的理解，欢迎探讨指正。

首先，上千台server规模已经很大了，个人觉得一个管理员能support的服务器上 ...

讲的很不错！
但是仅限于没有研发能力的小公司。
就是说，有开源的，能用就好，不希望自己投入开发的，就是这个思路。

jiaolt

busyant 发表于 2012-07-10 11:56
个人的理解，欢迎探讨指正。

首先，上千台server规模已经很大了，个人觉得一个管理员能support的服务器上 ...

1:太过依赖管理员技术水平，不利于知识的传递。shell script很牛的人，可能不懂perl。perl很牛的人可能不懂python，python很牛的人可能从来没用过expect。有人可能会开玩笑说这样子公司就不敢开你了，但是，如果你是升迁呢？找个和你一样牛的人真的很难的，你会发现工作交接真的很头大

   CFEngine 语法也很麻烦，你要研究的深入，才能灵活控制，比如更新失败之类的，还需要有检查之类的，一点也不简单

2 维护工作千变万化，脚本随时可能做修改，调试成本高，出错的风险也大。一次错一千台，看老板怎么骂死你！

   CFEngine  不同的需求，执行的命令也是不一样的，这个出错的风险，你用什么也避免不了，批量更新的时候，不管你使用cf也好，脚本也好，肯定都要先测试一下。

3 随着时间的推移，脚本会越来越多，越来越长，工作交接的问题又来了。最后你可能自己都记不清test_run.sh 是用来干嘛的了
   cf保留很多配置文件不都是一样的么？
。。。。。
就不一一反驳了，
工具这个东西，自己写的脚本好控制，灵活,用cf的话，出了问题，还要深入研究，不如自己来写。非常灵活，满足你各种需求.

无风之谷

回复 74# busyant


    多谢分享！:wink:

无风之谷

回复 75# flw


    呵呵 FLW大牛 期待你的分享啊:wink:

hmilymb

svn delete xxx，svn add xxx;

然后所有服务器svn up
不用考虑是否覆盖成功的问题。。

busyant

回复 76# jiaolt


    谢谢你的回复，以下是我的见解：

CFEngine 的好处在于，只需要学习一个工具、和语法。只要熟悉了，出错的机会会越来越少。当然谁也不敢保证不会写错，多一个括号，少一个空格什么的。
而脚本的灵活性带来的问题就是太多变数，每个管理员有自己的实现习惯，有的人可以写得很精炼但是新手可能一下看不懂。
所以，CFEngine之类的工具优势在于知识的传递有保障，别人不会看不懂，就算看不懂，参考官方的手册就可以了，很简单。

对于调试，的确是这样，任何一个刚改都需要前期的调试。CF的调试也很麻烦，我用的还是CF2版本，有时候错误输出很莫名。用脚本不错，可以自己添加调试输出。

遗留的CF配置文件，我认为不是问题，既然在用CF，那你就必然一直在使用，语法不会忘记。只要打开来看一眼就明白了。而脚本则不一定，特别是没怎么加注释的脚本，又特别是看别人写的脚本的时候，问题又回到知识的传递上了。棒要交接到位。
CF的配置也有特点，就是可以用简单的几句话来实现，比如，要在配置文件里面加一行文字 ：

gi::
        {   /etc/sudoers
            Backup "off"
            DeleteLinesMatching "jl        ALL = NOPASSWD: /etc/init.d/mysql, /bin/su - serv"
            AppendIfNoSuchLine "jl        ALL = NOPASSWD: /etc/init.d/mysql, /bin/su - serv, /bin/rm -rf /opt/tmp/*"
        }

而用shell script 则需要

• 先grep
• 判断返回值
• 用sed或者其他方法删除 第一行
• 再grep
• 判断返回值
• 用sed或其他方法追加第二行
  

一个使用类似自然语言，一个使用command，易读性的对比，不言而喻。


前面我也说了，脚本的确是好东西，我自己也经常用脚本来批量查询服务器信息。但需要固化下来的操作流程，用CF之类的工具是不二之选。
当然CF也有它的问题，语法上手比较难，前期架构设计需要花大力气。配置文件多了后冲突的检测也需要投入精力。我现在用的是 CFEngine 2.x 语法本身就有问题，据说CF3 有了长足的进步，变成类似面向对象的语法了，应该容易一些，我没有测试过。


欢迎继续探讨。




----------
题外话：
兄弟你潜水够厉害，2005年注册，7年帖子一共才16个！ 佩服佩服！