-
@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.
-
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?
-
@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)
-
@girish ah fair enough. I mean I use the machine for cloudron exclusively so maybe my bare metal approach works better
-
@atrilahiji if you want to play with sysbox, you'll be able to make machine image containers as an app soon.
-
@atrilahiji you may find this one interesting for your use-case. Let me know if any question.
-
-
@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)
-
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).
-
@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.
-
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"
