GitLab CI和分布式构建混乱

时间:2014-02-26 22:21:16

标签: gitlab gitlab-ci

我对持续集成服务器比较陌生。我一直在使用GitLab(v6.5)来管理项目,但我想开始使用GitLab CI来确保测试通过并且构建成功。

我的测试设置包括两个虚拟机:一台用于GitLab,另一台用于GitLab CI(和跑步者)。但是,在生产中我只有一台机器,它正在运行GitLab。 GitLab团队发布了interesting blog post一段时间,强调:

  

如果您在CI服务器上运行测试,那么您做错了!

这是一个非常翔实的帖子,但我并没有感觉到我理解这个特定点。这是否意味着不应该在同一台服务器上运行GitLab和GitLab CI?这是否意味着不应该在同一台服务器上运行GitLab CI和GitLab CI运行器?或两者兼而有之 - 我是否需要三台服务器,每项任务一台?

来自同一篇文章:

  

任何可以推送到CI服务器上测试的分支的人都可以轻松拥有该服务器。

这对我来说意味着跑步者是安全风险,因为他们可以运行提交中包含的东西。如果是这种情况,那么典型的实施是什么?把GitLab和GitLab CI放在同一台机器上,但是跑步者在一台单独的机器上?如果跑步机受到损害,它还不会吮吸吗?那么只要他们的代码机安全,人们就可以失去他们的跑步机吗?

我真的想更多地理解这一点 - 绝对在我在生产中实现它之前。有没有可能安全的方法在同一台机器上实现GitLab,GitLab CI和GitLab CI运行器?

1 个答案:

答案 0 :(得分:5)

理想情况下,你可以在同一台主机上运行gitlab-ci和gitlab。其他人可能不同意我,但是orechestrator(gitlab-ci节点)并没有做任何繁重的工作。它严格的工作元IO和仓储结果。

话虽如此,我会将跑步者放在同一台机器上。 Gitlab-CI Runners是资源密集型的,无论您将它们放在哪台机器上,它都会全面执行。如果你在生产中运行将这些放在现场实例上以帮助控制运行常常需要cpu /内存的内存的一些成本,那么这是一个好主意 - 但是因为你的实例并不总是在这一点上,所以这是不切实际的。

我在gitlab-ci跑步者的数字海洋中处理小型实例时取得了一些成功。我没有做过巨大的构建,但我的想法是将工作负载分配给多个服务器,以便你的CI服务器:

  • 有回应
  • 可以一次构建多个项目构建
  • 可以运动隔离(这在列表中是任意的)

以及其他一些不会马上想到的事情。

希望这有帮助!