1
likuku 2013-07-09 01:14:25 +08:00 4
shell 语法很怪异,不同shell语法变化差异巨大,另外,不同系统(gnu vs bsd)/发行版默认shell不同。
还有即便都叫做/bin/sh ,但不同发行版可能是完全不同的实现。 甚至,还有同一个发行版 的 /bin/sh 在不同的历史时期是完全不同的实现(openbsd就是例子)。 如此这般,不精分才怪。 稍微复杂点,带比较/条件/选择/循环,的话,shell/bash 写起来就要死了,各种诡异的写法,和即便是 最基本的 比较 都可能需要用到shell以外的独立程序。 例子:最近还记得的就是 自己写 python 脚本处理下载的电影字幕文件,因为有的字幕文件格式很怪异,让自己常用的播放器(XMplayer,射手播放器,XMBC) 不能正常显示。折腾过编辑器+正则来搞,很痛苦,总失败,遂写几行 python 解决,连带测试不到15分钟。 |
2
likuku 2013-07-09 01:20:55 +08:00
再啰嗦下:python 在运维中,的优势:
很多发行版都默认装了python; 语法相较各种精分/变态的shell,python就是一次写好,到处运行; python 可以很轻易的与shell等linux资源混搭(os.system(),commands.getoutput(),也可以用shell的管道给py程序传输入信息); list/set 等很便利的类型,手册完备,学习容易,好记好用(精分的shell会死人的); |
3
BOYPT 2013-07-09 09:06:16 +08:00
普通运维上精通bash效果更加明显,操作效率明显高得多。
在涉及复杂环境时候python可以作为一个很好的补充。 bash处理精确字符时候需要sed/awk(虽然适合的时候他们要比别的东西好用多了),比如需要动态生成配置文件,bash做起来就很吃力了。 |
4
glancesx 2013-07-09 09:09:50 +08:00
往往写一些比较'大型'的工具会体现出来.优势就是库丰富,能做到你想不到,shell做不到的事情.
|
5
tinytub OP |
6
julyclyde 2013-07-09 10:37:03 +08:00
/bin/sh 如果你不用bourne shell之外的扩展语法的话还是可以保持通用的
只不过shell这种语法的表达能力不算特别强而已 另外在shell里,不同行之间想维护“状态”不太容易,因为其变量能保存的东西也有限。很多时候依赖管道 |
7
tinytub OP @BOYPT 现在动态生成配置文件倒是直接用puppet的erb模板能够解决,确实很方便,不过实现方法是通过ruby.说到ruby,之所以不想学,是因为被ruby各种模块的小版本不兼容给搞烦了...唉唉,我果然不适合做开发.
|
9
slickqt 2013-07-09 10:52:52 +08:00
换个想法,会有那些应用可以用python来做可能会做得更好,更适合.
落到实处才更有体会. 如果你现在的工作不需要python也完成得很好了,其实真没必要非得python来着. 想想那个当你手上是锤子的故事,只是现在你手上的锤子是python而已. |
11
ry_wang 2013-07-09 11:18:12 +08:00
其实我最想吐槽的是,为什么要抛开fabric此类运维工具。这些不恰恰是Python在运维领域强大最好的证明么。
另外shell写出来的是脚本,python写出来的才叫工具。 |
12
tinytub OP @ry_wang 呃,多谢吐槽.
我并没有说python在运维领域不强大.只是想更多了解一下python在运维中能做哪些事情,如果要讨论fabric的使用和技巧我会单开个帖子询问.也因为目前部分生产环境中正在使用fabric,所以在这里要抛开fabric不谈,希望这里的前辈能给一些运维基于python其他方向的看法. 当然上面几位前辈已经给出了不错的见解.同时也谢谢你的回复. |
13
likuku 2013-07-09 13:34:47 +08:00
关于 shell 和版本的话题,再加点料...很好玩的:
关于双中括号的问题 - FreeBSD China : https://www.freebsdchina.org/forum/viewtopic.php?t=56452 「 loader: 文章发表于: Mon 2013-01-21 21:54:20 发表主题: 引用并回复 door10000 写到: 看来openbsd和freebsd的默认sh都不相同的。。 欢迎你来地球玩... 等我开始用 OpenBSD 的时候已经是默认 ksh 了 原来曾经有过 NetBSD 的 ash 引用: ---------------------------- revision 1.9 date: 1997/08/20 23:43:47; author: deraadt; state: dead; lines: +1 -1 this has not been used for a while ---------------------------- revision 1.8 date: 1997/01/05 08:17:31; author: deraadt; state: Exp; lines: +2 -2 HOSTCC; from rahnds ---------------------------- revision 1.7 date: 1996/10/20 00:54:41; author: millert; state: Exp; lines: +4 -4 Sync with NetBSD. Adds better POSIX compliance amongst others. ---------------------------- revision 1.6 date: 1996/10/12 01:12:02; author: deraadt; state: Exp; lines: +2 -2 use HOSTCC; from dale ---------------------------- revision 1.5 date: 1996/09/16 10:51:33; author: downsj; state: Exp; lines: +3 -1 These should always be static. ---------------------------- revision 1.4 date: 1996/06/23 14:21:05; author: deraadt; state: Exp; lines: +1 -1 update rcsid ---------------------------- revision 1.3 date: 1996/03/03 12:32:57; author: niklas; state: Exp; lines: +6 -9 From NetBSD: Fix problems with the way init.o is built: * Prevent gratuitous rebuilds when nothing has changed. * Make sure it is rebuilt if a .h file is updated. ---------------------------- revision 1.2 date: 1995/12/14 01:22:27; author: deraadt; state: Exp; lines: +6 -1 update from netbsd, including: Fix PR/1760, where 'cd -' before any other command could cause a reference to an uninitialized pointer. Use getcwd() to get the current working directory, instead of forking /bin/pwd [per Scott's suggestion] ---------------------------- revision 1.1 date: 1995/10/18 08:37:21; author: deraadt; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 1995/10/18 08:37:21; author: deraadt; state: Exp; lines: +0 -0 initial import of NetBSD tree 」 Bash这门UNIX下的壳语言 - FreeBSD China : https://www.freebsdchina.org/forum/viewtopic.php?t=58262 若看完精分/精分加重,那么恭喜了,嗯,不用谢! |
14
likuku 2013-07-09 13:38:10 +08:00
不好意思,上面的忘记引用重要的一段:
关于双中括号的问题 - FreeBSD China : https://www.freebsdchina.org/forum/viewtopic.php?t=56452 「loader 发表于: Mon 2013-01-21 20:08:27 发表主题: 一开始我以为 分不清哪些功能是 bashism 哪些不是的是 Linux 用户 用了 bashism 功能却从不标明 bash 的是 Linux 用户 认为用 sh 运行就能符合 POSIX 行为的是 Linux 用户 直到后来我才知道 Bash 的 POSIX mode 得按照说明来 http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html#Bash-POSIX-Mode 比如里面明确说明 26. Process substitution is not available. 那么 <() 在 Bash POSIX mode 就不能用了, 而 [[ 这种没提到的就算开了 POSIX 也照样能用 FreeBSD 里的 /bin/sh 是 ash http://www.in-ulm.de/~mascheck/various/ash/ 对照 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html ash 也另外增加了些东西,不过 BSD 用户当然以 base 里的 ash 为标准, 凡是 ash 能用而 POSIX 里没定义的是 feature, 凡是 ash 不能处理的肯定是 bashism XD 另外,前些年有些发行版为了换成 dash (debian ash) 网上有过好多各种械斗 https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 」 |
15
BOYPT 2013-07-09 13:48:34 +08:00
不是有这样一本书么:
http://book.douban.com/subject/4031965/ 《Python UNIX 和Linux 系统管理指南》 你看里面的目录,主要还是发挥python的数据解释处理、通信、集成等等的能力。但真正运维操作里面的批处理,简单说批改文件,真心没sed好用;做文件处理,一句tar总比里面import这import那方便吧;查找文件,没find好用吧;搞fabric,加个公钥认证还重载这个那个,我觉得还不如我while cat read然后parallel ssh给远程方便。 所以我认为Python,主要是在把运维任务模块化包装,以便留下接口供其他系统使用时候,作用很大;但是对于给个人的运维任务来说,了解shell的功能更加重要。 |
16
clino 2013-07-09 14:23:18 +08:00
我很讨厌shell/perl这种可读性上比较恶心的东东,所以大部分工具都是用 python 写的,shell大部分只用到直接列出命令这种简单的方式
另外运维工具推荐ansible,比fabric强大和易于扩展 |
17
cicku 2013-07-09 15:08:33 +08:00
围观各种 py 优越党
|
18
TankyWoo 2013-07-09 20:46:13 +08:00
我给Nagios写的插件都是python写的,shell在代码量过大后,因为一些复杂结构上的问题,肯定会稍显不足,而且你写的代码以后肯定还要有其他人看,除非你们大家都是用shell写的。。。
perl我就不评论了,不了解 |
19
terry 2013-07-10 09:19:38 +08:00
Shell (Bash) 语法比较诡异,一直要翻手册,得考虑兼容性(比如碰到 Linux 上写的脚本到 Solaris 上跑步起来这种问题,头疼死)调试起来够呛。相对于 Python 它离开内核更近(更底层)执行效率高。除非超过100行,否则不考虑用 Python / Ruby 之类的。
我所接触的 IT Infra 中,用 Python 写脚本来做简单的自动化非常普遍。大部分 *NIX 系统自带 Python 2.x 版本,方便,其代码可读性和可维护性比也 Shell 好。 目前 DevOps 任务主要是用 Shell + Ruby (加少量遗留下来的 Python 脚本)的组合,用 Ruby (用不到 Rails ...)主要是早期用了 Vagrant + Chef Solo 后来又选择用 Chef 来做自动化和配置管理原因,用它来做 Shell 的补充不错。而且既然学了 Ruby 就不再去深入学习 Python 了,反正同事会互补;-) BTW: Python 写的 ops 工具太多了,都很牛!比如 ansible / salt / fabric / sunzi / graphite 等等,不胜枚举。 @clino Ansible 已经不仅仅是个 parallel execution 框架/工具了,有了自己的 Playbooks 和 Chef 差不多,可以做配置管理了。不过个人感觉暂时还没法和 Chef 比。 @TankyWoo perl ...... |
20
clino 2013-07-10 10:22:10 +08:00
@terry ansible 的 playbooks 我基本没用,我都是直接全 python 写脚本的方式来用的,这样更灵活些,另外自己也扩展了 library里的不少module.目前用起来感觉不错.
其实对其他的运维工具了解不够多,所以不知道比较起来怎么样. |
21
terry 2013-07-10 12:00:49 +08:00
@clino Ansible 已经算是成熟好用的工具了,成立商业公司之后模块一下子多了起来。但实际应用中会发现直接通过 SSH 操作大量机器是会出现问题的,这时候有中间件(Message Queue)的并行执行工具就要出场了,比如 MCollective 和 Salt 用 ActiveMQ / RabbitMQ 做消息队列来保证一致性和可靠性。
BTW: Ansible 提供 SSH 和 Paramiko (一个 Python SSH 实现)两种连接方式,不知道后者是否也是基于上面提到的场景的考虑。 |
22
dcoder 2013-07-10 14:16:52 +08:00
以前被各种shell折腾惨了,现在基本只用Python写*nix上的脚本。
问个可能很弱的问题,那个维护得很好的 oh-my-zsh 不是支持很多版本的*nix么, 如果大家都用这个zsh,有希望统一各种不同的shell吗? |
23
clino 2013-07-10 14:29:29 +08:00
@terry "但实际应用中会发现直接通过 SSH 操作大量机器是会出现问题的"
这个有没有具体的信息? "Ansible 提供 SSH 和 Paramiko (一个 Python SSH 实现)两种连接方式,不知道后者是否也是基于上面提到的场景的考虑" 这个我估计没有吧,因为服务端是一样的 ssh server,协议要一致吧.用ssh有个不好的是前面连接到能执行命令需要一段时间.好处是不用另外部署服务端. |
25
terry 2013-07-12 10:07:34 +08:00
@clino 用 Ansible 操作10个服务器就有点慢得受不了了。
若同时操作100个服务器,Ansible 的并行执行是顺序执行的(不是多线程的),碰到网络问题,目标节点问题都不得不等待 timeout 浪费大量的时间。根本不可靠,甚至没法用。 所以出现了 MCollective / Salt 这样在中间放中间件(message broker/queue)的工具,来提高效率和可靠性。 BTW: 对 Ansible 理解有限,有错误请指出。 |
26
clino 2013-07-12 10:43:40 +08:00
@terry 我这里已经同时操作 170+ 台服务器了,没有发现你说的 "用 Ansible 操作10个服务器就有点慢得受不了了"
"若同时操作100个服务器,Ansible 的并行执行是顺序执行的(不是多线程的)" 多少线程可以配置的吧... "目标节点问题都不得不等待 timeout 浪费大量的时间。根本不可靠,甚至没法用" 实在是没有碰到过这种问题... |
27
terry 2013-07-12 17:06:32 +08:00
@clino SHIT 当时看 Ansible 文档的时候(还是 ansible.cc 这个域名)没有看到有 -f 这个参数。你说的设置多线程是这个 fork 进程方式?
|
28
clino 2013-07-12 17:49:48 +08:00
@terry 我没有用playbook,所有的都是在python里给的参数,例如:
runner = ansible.runner.Runner( host_list=hl, module_name='command', module_args=options.cmd, remote_user='root', pattern='all', forks=len(hl) ) 我经常是很暴力的用了forks=len(hl),如果有100个host就直接开了100个线程(进程?)了 |
29
goinaction 2013-07-13 14:43:56 +08:00
@clino fork应该是开了100个进程
|
30
likuku 2013-07-13 15:54:26 +08:00
|
31
clino 2013-07-14 19:23:46 +08:00
|
32
terry 2013-07-16 13:39:56 +08:00
Ansible -f 的并行是用的是操作系统进程实现多线程的,据说效率不是很好的样子...
没学过 python 但还能看懂一些,源代码里挖到这一块,应该就是了... workers = [] for i in range(self.forks): new_stdin = os.fdopen(os.dup(sys.stdin.fileno())) prc = multiprocessing.Process(target=_executor_hook, args=(job_queue, result_queue, new_stdin)) prc.start() workers.append(prc) 机器分布在几个大洲这样操作起来够呛... |
33
clino 2013-07-16 16:35:07 +08:00
@terry "Ansible -f 的并行是用的是操作系统进程实现多线程的,据说效率不是很好的样子..."
不知道你说的效率不好体现在哪里,linux下进程的开销和线程差不了多少 "机器分布在几个大洲这样操作起来够呛..." 从论据怎么得出的这个结论,不是很明白啊 |
34
shanks 2013-07-17 17:32:03 +08:00
自从学了bash script之后,一直觉得语法严谨到蛋疼的程度。超过100行就比较难维护了。还老是记不住那些语法细节,不知何故。。。 QAQ
|
35
sykp241095 2013-12-17 15:32:44 +08:00
额,ansible 方面的话,推荐自己写的:https://github.com/douban/farmer
|
36
dennyzhang 2016-09-14 08:42:42 +08:00
考虑将 Bash 的运维脚本换成其它。在纠结是选 Python 还是 Golang.
|
37
lmx07 2017-10-03 16:21:21 +08:00
大家好,在下的拙作《 Python Linux 系统管理与自动化运维》正式发布了,大家可以看一看。
书籍的完整目录: https://github.com/lalor/python_for_linux_system_administration.git 书籍介绍:本书以 Linux 系统管理为线索,以 Python 语言为载体,从工具、脚本、方法等多个方面讲解了如何在 Linux 系统管理和自动化运维中使用 Python 来解决各种问题,包含大量案例和最佳实践。 |