Gitlab Runner - OK on the same machine?
-
I read this post (https://forum.cloudron.io/topic/1373/gitlab-runner-for-ci) as well as the docs (https://docs.cloudron.io/apps/gitlab/#gitlab-runner-for-ci) and it seems to suggest it's possible to install a runner directly on the same Cloudron machine. I've read in other topics that we should not use regular docker images for apps on Cloudron because it can conflict with Cloudron's special packaging approach.
Is it OK to follow the instructions in the docs on my Cloudron machine directly? Where is the line that I shouldn't cross when it comes to running custom Docker images or installing extra packages?
-
I had this running like this a while back. It works fine if you feel comfortable spinning it up manually on your server. Something to remember is to backup this stuff manually as obviously it will not be part of any automatic cloudron backups.
I did run it using the docker in docker mode which means you have to mount the docker sock. Maybe not the best idea to give a build agent access to the docker system running your production cloudron images.
Hence I have abandoned this eventually and running now a gitlab runner as a custom cloudron app. Has some downsides as well, like docker in docker not working (at least didn’t figure out how to do this). -
I had this running like this a while back. It works fine if you feel comfortable spinning it up manually on your server. Something to remember is to backup this stuff manually as obviously it will not be part of any automatic cloudron backups.
I did run it using the docker in docker mode which means you have to mount the docker sock. Maybe not the best idea to give a build agent access to the docker system running your production cloudron images.
Hence I have abandoned this eventually and running now a gitlab runner as a custom cloudron app. Has some downsides as well, like docker in docker not working (at least didn’t figure out how to do this).@klawitterb if you use sysbox from Nestybox as the docker runtime, it makes DinD easier.
Simple change documented elsewhere on this forum and the Nestybox docs.
-
I had this running like this a while back. It works fine if you feel comfortable spinning it up manually on your server. Something to remember is to backup this stuff manually as obviously it will not be part of any automatic cloudron backups.
I did run it using the docker in docker mode which means you have to mount the docker sock. Maybe not the best idea to give a build agent access to the docker system running your production cloudron images.
Hence I have abandoned this eventually and running now a gitlab runner as a custom cloudron app. Has some downsides as well, like docker in docker not working (at least didn’t figure out how to do this). -
@klawitterb if you use sysbox from Nestybox as the docker runtime, it makes DinD easier.
Simple change documented elsewhere on this forum and the Nestybox docs.
-
@robi but this would mean I’d have to change the container runtime on my cloudron server to achieve that, or am i mistaken?
@klawitterb That is correct, all the benefits (security), and none of the drawbacks.
-
We use GitLab CI as well but the runners are on separate machines. As @klawitterb warned, running this on Cloudron server itself means the CI runner has access to all your containers (apps, data). In general, this is dangerous. A bug in the CI code can wipe out your system. A CI runner can run tasks as root. CIs can do all sorts of stuff - setup temporary databases, do builds, run so many "external" things which we cannot control.
Ultimately, a VM is like 5 bucks, so please take this cost into your consideration.
-
Somewhat unrelated, because I'm not using GitLab: Has anyone tried or knows if it's possible to have one machine for runners that can be accessed by multiple Cloudrons/GitLabs/Drone Agents? As in, can you fire up the same runner multiple times with different secrets for each Git?
-
We use GitLab CI as well but the runners are on separate machines. As @klawitterb warned, running this on Cloudron server itself means the CI runner has access to all your containers (apps, data). In general, this is dangerous. A bug in the CI code can wipe out your system. A CI runner can run tasks as root. CIs can do all sorts of stuff - setup temporary databases, do builds, run so many "external" things which we cannot control.
Ultimately, a VM is like 5 bucks, so please take this cost into your consideration.
-
But anyway, it's up to you if you feel comfortable and are aware of the repercussions of installing things give access to all your containers.