feat(helm): move dind to sidecar

[velkovb]

Run dind container as a Sidecar

Currently, in dind mode we run 2 containers in the pod. This results in them having their own lifecycles. In the case of dind this could lead to issues as the process in the runner container depend on the docker socket from the dind container. We hit that multiple times were we wanted to wait for jobs to complete and the runner container stays alive as we handle the SIGTERM manually but dind dies and the jo fails. When running as a Sidecar container dind stays alive as long as the pod is alive and we don't need to do custom SIGTERM handling there.

Since 1.29 Sidecars are enabled by default so this PR moves the dind container as a Sidecar if the version is above 1.29.

[chadxz]

I think this may fix an issue i'm seeing sometimes with our runners. In some jobs, we were seeing this error message in the "Initialize Containers" workflow step:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

[velkovb]

I think this may fix an issue i'm seeing sometimes with our runners. In some jobs, we were seeing this error message in the "Initialize Containers" workflow step:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

@chadxz This exactly the issue we were seeing and it helped us fix it.

[chadxz]

I tried using this but realized it conflicts with my manual dind setup in values.yaml. However I was able to move my dind container from “containers” to “initContainers” and set ‘retryPolicy: Always’ to replicate this behavior.

worked!

[velkovb]

I tried using this but realized it conflicts with my manual dind setup in values.yaml. However I was able to move my dind container from “containers” to “initContainers” and set ‘retryPolicy: Always’ to replicate this behavior.

worked!

Probably the case for most people. It is in the custom dind for us as well but I believe it should be the default option actually