最佳指南.jpg
这是”微服务一条龙“的项目第二篇，根据我们昨天第一篇说的使用Gitlab-Runner和Supervisor一起来部署我们项目的事情以及在部署过程中发生的问题。
- 事件还原
我们引用一下昨天遗留下来的问题和今天刚刚发现的BUG，好，我们来回忆一下，我们使用Gitlab-Runner来作为项目持续集成的工具，然后使用Supervisor来作为服务管理的工具，经过一系列的测试，我们发现一个问题：
（1）为什么root启动的Gitlab-Runner服务无法获取到最新的task，而非root启动的Gitlab-Runner服务却可以接受到呢？
（2）我们新发现的BUG，昨天明明运行的好好的程序，今天却出现一系列权限不足的问题，WHY？
- 事件分析
（1）我们整个过程使用非root的地方就是注册runner的时候、以及启动runner的时候使用了非root的用户的config文件，也就是目录/home/user/.gitlab-runner/config.toml，我们之前一直在纠结启动的时候使用-c来引用非root的用户的配置文件，这点毋庸置疑，但是，我们是不是忘了在注册runner的时候我们依然是使用非root的用户来注册的，所以我们使用root用户来启动Gitlab-Runner的时候，runner却是由非root的用户来注册的，这样我们就接收不到任务。（2）权限不足，应该是哪里使用了root来创建，我们无法访问到，我们查找下，发现我们在启动Gitlab-Runner的时候，我们是需要引用/etc目录下的某些文件，也就是说，我们普通用户并没有权限去访问，这个问题的根源应该是来自于这里。
- 解决问题
（1）我们通过创建不同的几个普通用户，分别注册各自的runner以及启动各自的Gitlab-Runner服务，测试之后发现，任务只能发给有对应tag，并且对应tag对应绑定的runner才能接收。（2）我们启动Gitlab-Runner服务的时候需要在我们的Supervisor配置文件中制定user=root或者是不指定user，会默认以root用户去执行，这杨的话就可以顺利接收到任务了。
- 总结
经过我们两天不断的折腾Gitlab-Runner和Supervisor，我们最后总结一下两者结合使用的最佳方法Gitlab-Runner以root用户去执行，执行命令是gitlab run -c config -u user这样我们就能保证又有完整的权限，又能够保证runner的权限最低，两全其美。