Hacker News new | ask | show | jobs
by ayufan 3746 days ago
You shouldn't be. Executing builds on Kubernetes is not the same as deploying an application :) We will solve that need with plugins :)

GitLab CI Lead

1 comments

That would be great, I'm not married to the implementation as much as the convenience of using the cluster manager we already have (kubernetes) to distribute builds.

I currently am using a VM with a docker runner, and there are two (somewhat obvious) issues:

* It requires root access to the machine to be able to spin up containers

* Every VM with a docker runner needs enough storage to handle every docker image used for builds, instead of centralizing the images. I really need to put in a cron job or something to clean these up.

Kubernetes should fix both of these, without introducing another technology in our environment like Docker Machine.

I understand your reasoning.

At this point it doesn't make sense to introduce support for another clustering manager. The GitLab Runner does support docker-machine (you can pretty easily configure it to create machines on-demand on any cloud provider). These machines will be pretty much self-managed. Soon the Runner will be also compatible with Docker Swarm, the implementation is already on separate branch.

From my perspective Kubernetes is great as platform for deploying applications, but I'm not so sure if it comes for distributing builds.

The problem with cleaning old images and caches is also addressed. You may be interested in checking out this application: https://gitlab.com/gitlab-org/gitlab-runner-docker-cleanup

What is important that GitLab Runner is being constantly improved and at some point with more convincing (for example coming from You) we can get back to native Kubernetes executor :)

GitLab CI Lead