Gitlab Runner for CI

[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"