最佳指南.jpg
这是”微服务一条龙“的项目第一篇，接下来的一段时间我会结合公司最近在做的小项目来给大家实际讲一下小项目如何使用上这两年流行的微服务，docker云部署，自动化集成这些让人感觉触不可及的东西。
- 项目背景
最近小组有个小项目，是将之前的Python的scrapy爬虫给做一下初步重构，由我和另外一位同事共同开发，我们分别实现爬虫的Worker端和调度系统的Scheduler端，大概意思就是给各个爬虫脚本至上包上一层“外套”，作为Worker，接收调度端的任务，调度对应的爬虫，具体的我们在接下来的一段时间会详细给大家来介绍，另外，如果大家有更好的想法，欢迎来一起讨论。
- 遇到问题
PS：今天刚刚完成了Worker的初版，前后大概用了两周，最终实现的还是一个很简单的功能，很惭愧啊！
说回问题，今天在做Worker部署时需要Worker动态加载Spider模块中所有爬虫模块（其实他们就是一些脚本，导入的时候使用了Python动态导入的功能），目前Spider目录只是通过Gitlab-Ci工具Gitlab-Runner来做一个自动集成，自动更新服务器上面的目录而已，很LOW是不是，是不是想吐槽。Gitlab-Runner部署测试好之后，就要思考一个问题，“Gitlab-Runner如何保证始终处于运行状态以及出错之后怎么自动重启”其实归根结底就是一个问题如何保证Gitlab-Runner稳定性。
于是想到了之前经常用的工具--Supervisor这个工具是由Python编写的一个可以将程序转化为系统后台程序的工具，有点类似于Systemctl将程序变为内置程序，由系统进行操作，启动或者结束，部署的过程很简单，按照官网的教程，一步步实现、安装。直到遇到问题，按照Supervisor启动的Gitlab-Runner程序不能接受新的任务，怎么回事？？？？
3.分析问题
（1） 直接启动Gitlab-Runner可以使用吗？
（2）Supervisor启动Gitlab-Runner的脚本是否有问题？
（3）Supervisor启动的Gitlab-Runner是否运行正常？
我们按照正常逻辑来考虑
首先这个由Supervisor启动的程序是否正常，运行supervisorctl status我们可以发现，它是正常运行的，我们再看看ps aux / grep gitlab中gitlab程序是否是正常，结果我们可以发现启动该进程的是ROOT用户，我们不知道这个是不是正常，但是可以先留着之后作为证据。
第二步，我们看看直接启动Gitlab-Runner可以接受任务吗，我们直接gitlab-runner run结果发现，这是可以正常接收任务的，我们再来看看进程情况，同样ps aux / grep gitlab，看看两次有何不同，结果发现了只是执行用户不同，不同的执行用户影响这么大？，我们看看官方文档，还是不太理解，为什么非ROOT用户起的进程就可以接受任务？这个问题其实一直没有解决，希望热心网友能够给解决一下，下面说一下我的处理办法，我是根据修改Supervisor的程序配置，也就是Gitlab-Runner的启动方式来修改使其成为非ROOT用户启动最终解决问题的，gitlab-runner run -c config.toml -u user这样的话，启动的程序自然是普通用户，不过最后疑问还是没解决。
