github-developer / self-hosted-runners-anthos Goto Github PK

hi @imjohnbo
Got a chance to play around with this today - a couple of questions:

i) Is there a reason why we are not prebaking the runner into the Dockerfile? Runner will also auto update, so even if we bundle an older version, they can get auto updated. Current startup time for this image to become active per pod is 50-60s. I have a prebaked runner which is less than 5s.

ii) Do we have plans to support both an official "DIND" and "regular" version of the runner docker image?

I believe dind image was pinned to docker:18.09-dind because of this:

Starting in 18.09+, the dind variants of this image will automatically generate TLS certificates in the directory specified by the DOCKER_TLS_CERTDIR environment variable.

Source: Docker Hub

Without creating another volumeMount and volume for certs, we can ensure that 18.09+ doesn't run it's TLS cert script by overriding the entrypoint using command: ["dockerd"].

To disable this image behavior, simply override the container command or entrypoint to run dockerd directly (... docker:dind dockerd ... or ... --entrypoint dockerd docker:dind ...).

Source: Docker Hub

Although, I couldn't seem to get docker to run on port 2375 with this, but it avoided creating the certs and wasn't running on 2376. It seemed to just run off the sock and accept connections that way.

This could really be an issue with the docker image, but I just wanted to get some insight based on why the tag was pinned to docker:18.09-dind.

Thanks!

Hi @imjohnbo

I had originally implemented GKE Self Hosted Runner Deployment with Container Lifecycle Hooks which removes runners when pod exits as opposed to capturing SIGTERM/EXIT signal. I was wondering if one is more advantageous than the other as Container Lifecycle Hooks seems more k8s native.

Wanted to get your thoughts on this and happy to open a PR