”微服务一条龙“最佳指南-解答篇:Supervisor和Gitlab-Runner终于并存

”微服务一条龙“最佳指南-解答篇:Supervisor和Gitlab-Runner终于并存 最佳指南.jpg

这是”微服务一条龙“的项目第二篇,根据我们昨天第一篇说的使用Gitlab-RunnerSupervisor一起来部署我们项目的事情以及在部署过程中发生的问题。

  1. 事件还原
我们引用一下昨天遗留下来的问题和今天刚刚发现的BUG,好,我们来回忆一下,我们使用Gitlab-Runner来作为项目持续集成的工具,然后使用Supervisor来作为服务管理的工具,经过一系列的测试,我们发现一个问题:
(1)为什么root启动的Gitlab-Runner服务无法获取到最新的task,而非root启动的Gitlab-Runner服务却可以接受到呢?
(2)我们新发现的BUG,昨天明明运行的好好的程序,今天却出现一系列权限不足的问题,WHY?
  1. 事件分析
(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. 解决问题
(1)我们通过创建不同的几个普通用户,分别注册各自的runner以及启动各自的Gitlab-Runner服务,测试之后发现,任务只能发给有对应tag,并且对应tag对应绑定的runner才能接收。(2)我们启动Gitlab-Runner服务的时候需要在我们的Supervisor配置文件中制定user=root或者是不指定user,会默认以root用户去执行,这杨的话就可以顺利接收到任务了。
  1. 总结
    经过我们两天不断的折腾Gitlab-RunnerSupervisor,我们最后总结一下两者结合使用的最佳方法Gitlab-Runnerroot用户去执行,执行命令是gitlab run -c config -u user这样我们就能保证又有完整的权限,又能够保证runner的权限最低,两全其美。
上一篇:在 Kubernetes 上安装 Gitlab CI Runner Gitlab CI 基本概念以及 Runner 的安装


下一篇:pycharm中设置pytest方式(Mac)