使用supervisor 进程管理工具来管理jenkins

使用supervisor 进程管理工具来管理jenkins

1.什么是supervisor

Supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启。它是通过fork/exec的方式把这些被管理的进程当作supervisor的子进程来启动，这样只要在supervisor的配置文件中，把要管理的进程的可执行文件的路径写进去即可。也实现当子进程挂掉的时候，父进程可以准确获取子进程挂掉的信息的，可以选择是否自己启动和报警。supervisor还提供了一个功能，可以为supervisord或者每个子进程，设置一个非root的user，这个user就可以管理它对应的进程。

不多说废话，一个粗暴简单的理解就是，这哥们可以把需要通过前台启动的方式启动的东东，变成一个类似一个后台常驻进程一样的玩意，就好像你使用 python xxx 或者node.js 开启了一个web 服务，按住ctrl+c 或者exit 退出时这服务就不见了，想再次调用时又需要 python xxx 再麻烦地执行一遍，使用supervisor ，你可以把这玩意变成一个后台进程，然后一直跑着，运行日志呢，通过配置，他将会去到他该去的地方。

（注意: 这哥们是给那些前台跑的进程提供方便的，注意这使用场景。任意通过前台跑的玩意，都可以由这哥们接管）

2.怎么安装

（以下是四种安装方式）

a. yum install supervisor(centos 等可用）

b.apt-get install supervisor(Debian/Ubuntu 等可用）

c.pip install supervisor

d.easy_install supervisor 

可能还有其他各种骚操作，反正就跟装个软件一样....，这个倒不是很难

3.怎么配置

环境有了，接下来便是怎么配置阶段了

重要配置文件:/etc/supervisord.conf

这玩意记录着supervisor.conf 这东东启用时需要的大部分东西

当然，对我们有用的信息也着实很有限，大部分高级玩法可能并不是很需要，记住几个东东即可:

1. 

这玩意跟你开启启动时发现启动不了报一个  unix:///tmp/supervisor.sock no such file 有关，解决方案其实也很简单，给它换个别的路径，比如把/tmp/ 换成/var/log/ 这样

2. 

这跟上面一样，如果改路径的话，这地方也要改

3. 

这个表示，supervisor 即将接管的子进程的配置，如图上这样配置，那就代表，我们即将使用supervisor 来接管 /etc/supervisord.d/ 下后缀名为 .supervisord 下配置的进程 东东

 

好吧..... 兜了一个大圈，其实这个问价，也就是配置一个入口，具体要怎么配置，还由include 下的files 指定那个路径下的文件来决定，看来重点还是在后头

4. 看看接管的子进程配置文件

以我配置的为例:这目录下有两个东东，一个是与 java 相关的jenkins ，一个是以python 相关的flask 

a. 先看看jenkins的:

[program:jenkins]
#配置的java启动环境
environment=JAVA_HOME=/usr/local/java/bin
#启动命令
command= /usr/local/java/bin/java -jar /root/app/jenkins/jenkins.war
#jar所在文件目录
directory=/root/app/jenkins/
#用户
user=root
stopsignal=INT
#自动启动
autostart=true
#自动重启
autorestart=true
#重启时间1s
startsecs=1
#错误日志
stderr_logfile=/var/log/jenkins_err.log
#标准打印日志,满50MB区分
stdout_logfile=/var/log/jenkins.log

[supervisrod]

好吧，其实也是很简单，大朋友们要配置的话把这玩意拷贝过去，改下命令的执行路径即可，即command 后面的 东东

，stderr_logfile 和 stdout_logfile 日志存储路径可以自定义下

简单的不多说了，这里说下一个蛋疼的坑，就是大伙看着别扭的，command 命令后 要写java 路径的那个玩意，其实是这样的，

supervisor 他不会读 /etc/profile i下或者啥啥啥文件（啥啥啥指的就是你自己配置环境变量的文件），不读？那岂不是跟你安装完java 确不配耳熟能详的JAVA_HOME 环境变量一样？ 没错，确实是这样的，所以，土一点的方法就是我上面这样玩喽，强行给它安排上，把java 的bin 目录搬出来.....

当然啦，就是丑了点......

还有一种玩法，那便是command: 先source /etc/profile 后再执行java jar xxx.war/jar  或者整得再像样点，在jenkins.supervisord 下的command 时呢，配置为:

然后对应的脚本:(最简单粗暴款，当然，你可以在shell 中做单例判断等等）

5. 下一步？

一般配置到这样的话，然后就可以了

这个时候千万别直接supervisorctl reload ，不然会直接报错

正确的做法是要先更新上，再reload

命令顺序应该是:  

1. supervisorctl update

2. supervisorctl reload

3. supervisorctl status 可以查看状态是否启动正常

6. 加入开机自启动

systemctl enable supervisorctl

（没了？？？不不不，你这是把supervisorctl 这个父进程加入到了开机自启动中，可不是把supervisorctl 管理的子进程加入到开机自启动中.......那为啥子进程就不行了，因为父子进程通信基于socket 通信的....前面那个supervisorctl.conf 文件中所说的第一小点，开机时会先删掉supervisor.sock 文件，既然supervisor.sock 文件没了，那也就 不会去拉supervisorctl 所管理的子进程拉.....）

所以，唉，那怕是又得骚操作一波了，其实好奇的朋友 可以ps 看下 supervisorctl 在启动时的进程叫啥.....，没错，你可以看到下图:

哦豁，计上心头....

那写个shell 脚本，这脚本就是开机时调用/usr/bin/python2 /usr/bin/supervisord -c /etc/supervisord.conf 这样，不就行了

然后再把他加到开机启动文件中.... pass

看来没错----实验结果,,,ok

如下所示:

不过这个时候你可能会发下还是不行，其实也很简单，因为我们刚刚systemctl enable supervisorctl 过一次了，可能会导致我们开机自启动中 调用脚本去拉supervisorctl 会整一个进程或者服务已存在（其实就是supervisorctl  这个父进程被拉起来了，其实没毛病，但这不等于我们要的他接管的子进程被拉起来~）,所以做法也很简单，反手一个 systemctl disable supervisorctl 即可，也就是开机时我们采用脚本形式来啦supervisor ....