Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

GitLab CI and Distributed Build Confusion

I'm relatively new to continuous integration servers. I've been using GitLab (v6.5) for a while to manage projects, but I'd like to begin using the GitLab CI to ensure tests pass and builds succeed.

My testing setup consists of two virtual machines: one machine for GitLab and another machine for the GitLab CI (and runners). However, in production I only have a single machine, which is running GitLab. The GitLab team posted an interesting blog post a while back that emphasized:

If you are running tests on the CI server you are doing it wrong!

It was a very informative post, but I didn't come away feeling like I understood this specific point. Does this mean one shouldn't run GitLab and GitLab CI on the same server? Does it mean one shouldn't run GitLab CI and GitLab CI runners on the same server? Or both-- Do I need three servers, one for each task?

From the same post:

Anybody who can push to a branch that is tested on a CI server can easily own that server.

This implies to me that the runners are the security risk since they can run stuff contained in a commit. If that's the case, what's the typical implementation? Put GitLab and GitLab CI on the same machine, but the runners on a separate machine? Wouldn't it still suck if the runner machine was compromised? So people are okay losing their runner machine as long as their code machine is safe?

I would really like to understand this a bit more-- definitely before I implement it in production. Is there any possible yet safe way to implement GitLab, GitLab CI, and GitLab CI runners all on the same machine?

like image 254
kyrofa Avatar asked Feb 26 '14 22:02

kyrofa


People also ask

What style of pipeline should be used when working with a Monorepo or lots of independently defined components?

Child/Parent Pipelines: Good for monorepos and projects with lots of independently defined components.

Is GitLab a CI CD tool?

GitLab has CI/CD built right in, no plugins required.

Why should end users consider using stages in their GitLab CI Yml file?

The use of stages in GitLab CI/CD helped establish a mental model of how a pipeline will execute. By default, stages are ordered as: build , test , and deploy - so all stages execute in a logical order that matches a development workflow.


1 Answers

Ideally you're fine running gitlab-ci and gitlab on the same host. Others may disagree with me but the orechestrator (the gitlab-ci node) doesn't do any of the heavy lifting. Its strictly job meta IO and warehousing the results.

With that being said, I would not put the runners on the same machine. Gitlab-CI Runners are resource intensive and will be executing at full tilt on whichever machine you place them on. Its a good idea if you're running in production to put these on spot instances to help curb some of the costs of running the often cpu/memory hungry builds - but can be impractical as your instances are not always on at that point.

I've had some success with putting my gitlab-ci runner's in digital ocean on small instances. I'm not doing HUGE builds, but the idea is to distribute the work load against several servers so your CI server:

  • Is responsive
  • Can build multiple project builds at once
  • Can exercise isolation (this is kind of arbitrary in this list)

and a few other things that don't come to mind right away.

Hope this helps!

like image 131
lazyPower Avatar answered Sep 21 '22 23:09

lazyPower