最佳指南.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
的权限最低,两全其美。