python在系统运维中都有哪些应用？

Python

运维中

运维

37 条回复 • 2017-10-03 16:21:21 +08:00

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

2013-07-09 10:34:47 +08:00

@likuku 多谢解答,由于我这边系统环境比较单一,所以没遇到过shell在不同发行版的区别.正如@yegle 在知乎上所说,没遇到过shell在不同版本的区别,怎么好意思说自己会写脚本(大概是这个意思.). 看来深入学习python还是很有必要的.

6

julyclyde

2013-07-09 10:37:03 +08:00

/bin/sh 如果你不用bourne shell之外的扩展语法的话还是可以保持通用的
只不过shell这种语法的表达能力不算特别强而已
另外在shell里，不同行之间想维护“状态”不太容易，因为其变量能保存的东西也有限。很多时候依赖管道

7

tinytub

OP

2013-07-09 10:37:09 +08:00

@BOYPT 现在动态生成配置文件倒是直接用puppet的erb模板能够解决,确实很方便,不过实现方法是通过ruby.说到ruby,之所以不想学,是因为被ruby各种模块的小版本不兼容给搞烦了...唉唉,我果然不适合做开发.

8

tinytub

OP

2013-07-09 10:38:26 +08:00

@julyclyde 记得之前带我入门的师傅说过.shell不过就是堆命令...咳咳.

9

slickqt

2013-07-09 10:52:52 +08:00

换个想法,会有那些应用可以用python来做可能会做得更好,更适合.
落到实处才更有体会.
如果你现在的工作不需要python也完成得很好了,其实真没必要非得python来着.
想想那个当你手上是锤子的故事,只是现在你手上的锤子是python而已.

10

tinytub

OP

2013-07-09 11:01:41 +08:00

@slickqt 当你握着一把大钉锤时，每个问题看起来都不过是一枚钉子而已。

刚去搜了一下这句,谢提醒.

11

ry_wang

2013-07-09 11:18:12 +08:00

其实我最想吐槽的是，为什么要抛开fabric此类运维工具。这些不恰恰是Python在运维领域强大最好的证明么。

另外shell写出来的是脚本，python写出来的才叫工具。

12

tinytub

OP

2013-07-09 11:36:20 +08:00

@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有个不好的是前面连接到能执行命令需要一段时间.好处是不用另外部署服务端.

24

tinytub

OP

2013-07-11 11:21:14 +08:00

@clino ssh在同时连接大量服务器的时候不稳定,有的时候可能会卡断.而且网络条件对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

@terry
@clino

或许网络环境不同，
上百台机器都在LAN内，批量ssh可能也秒杀。而10台在世界不同时区的机器就可能频断卡顿吧。

31

clino

2013-07-14 19:23:46 +08:00

@likuku @terry 这倒是有可能,我说的这 170+ 台机器有 3/4 是在异地城市的,不过之间都有专线连接,还算比较稳定,可视为在局域网内

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 来解决各种问题，包含大量案例和最佳实践。