Gitlab Runner for CI

[girish]

@Beryllium Yes, you can run the gitlab runner in a separate VM and give GitLab the runner's credentials. The docs for this process are no different from running GitLab CI.

I can put some docs on the Cloudron side in any case.

[girish]

@Beryllium I have put instructions here - https://cloudron.io/documentation/apps/gitlab/#gitlab-runner-for-ci

[parhelium]

@girish Your documentation is great.

However is there chance there will be "gitlab runner" app in cloudron, so only few clicks and runner is running ?

My use case is following. I have bought 64 GB RAM server for cloudron and I would like to reuse it power for gitlab runner without messing with manual configuration.

[girish]

@parhelium Are you looking for the docker runner? The issue is that the docker runner requires complete access to docker. Which in turn means that a bug in the runner might nuke your entire Cloudron app installations. This seems very risky. It's best to run runner in VMs of their own. Is the 64GB server a dedicated server? If so, I recommend running something like Proxmox or some other hypervisor. Keep 1 VM as Cloudron and another as GitLab Runner.

[A Former User]

So I just got this working. Kind of in a Janky way though. So I run Cloudron on bare metal (no virtualization), so I just spun up an Ubuntu 20 VM on my Cloudron Ubuntu 18 server and ran gitlab runner on there. Nailed it. I do want to try and move my cloudron install to a VM as well but I anticipate that being incredibly difficult.

Screenshot: https://social.atrilahiji.dev/web/statuses/105347017032129546

Edit: Actually @girish with your experience would you suggest my current setup or running cloudron on a VM running on this server I have?

[girish]

@atrilahiji I think both approaches make sense. Generally, if you have a super beefy machine (compared to your Cloudron use), it makes sense to put Cloudron in a VM, so that you can play around with other things in other VMs. I think another consideration is if all the audio/video acceleration stuff work properly in a VM. I guess they need hardware pass through etc? (sorry, I don't have much experience with hypervisors, I run Cloudron on bare metal myself and apps like Emby have no problem)

[A Former User]

@girish ah fair enough. I mean I use the machine for cloudron exclusively so maybe my bare metal approach works better

[robi]

@atrilahiji if you want to play with sysbox, you'll be able to make machine image containers as an app soon.

[marcusquinn]

@robi Interesting, that's the first use-case I get, makes much more sense now!

[A Former User]

@robi For sure! As soon as thats ready I'll give it a shot. I like my current method except I cant manage resources from inside cloudron so this would be incredible.

[Rodny Molina]

@atrilahiji you may find this one interesting for your use-case. Let me know if any question.

[mehdi]

@girish is there a good reason that the Gitlab CI runner cannot be package as a Cloudron app currently, with the docker addon ? Or has it simply never been done ?

[girish]

@mehdi I think mostly I fear that a bug in GitLab CI or some CI script can nuke the cloudron app/addon containers. Granted we do have a docker proxy now since Cloudron 5, but I can't say that proxy is battle tested. That proxy was specifically tested against jupyter hub (which spins up each notebook as a container). It's also why installing apps that use docker addon requires superadmin perms. I think since Cloudron 5, we also tag containers properly to be "cloudron managed" or not, so it is definitely now more possible to make CI as an app than before.

My understanding is that in a sysbox world, we don't need this docker proxy since it can give a container it's own little docker world (like a VM). (I haven't played with sysbox)

[girish]

https://git.cloudron.io/cloudron/box/-/blob/master/src/dockerproxy.js is the proxy in question.

@mehdi In general, I don't want the CI or any other app for that matter to "pollute" the main docker with it's own containers and images. My understanding is the sysbox runtime can be set at a container level, so whenever some app wants docker addon, we can attach this sysbox runtime. Removing the app will also remove all the artifacts it created cleanly. (which is currently not done at all for jupyer hub because there is no clean uninstall hook).

[Rodny Molina]

@girish That's right. Sysbox can cohabit with other runtimes; you just rely on the "--runtime" flag to pick one or the other. And right, you won't need a docker-proxy with Sysbox runtime, which will also save you a few headaches due to the fact that the code/dockerfile that you are trying to build is typically in a different context than the docker instance building the image.

Btw, I fully agree with your approach: no user-facing app should have root-level access to the host.

[robi]

Someone got autoscaling docker machine working with Gitlab-runner using Sysbox.

"The interesting point is that the arguments to use the sysbox runtime are passed in the “--engine-insecure-registry”; this allows additional parameters that docker-machine does not support to be added"