#Remote engine in kubernetes

1 messages · Page 1 of 1 (latest)

tame compass
#

Hi guys,
I'm evaluating using dagger for our CI/CD and trying to wrap my head around a possible implementation.
We have Gitlab CI with self-hosted kubernetes runners. We've moved our building approach away from docker-in-docker towards using kaniko, so I'd like to not use docker for the sake of security and difficult questions from management.
If i understand correctly, my only option is running a remote instance of dagger engine (still should be run as privileged?) with dagger-cli calling from CI pods spawned by gitlab runner. However, what I don't get is what the preferred way of doing so is.
The official doc suggests installing dagger-engine as daemonset - what is the advantage of running it that way and connecting over mounted unix socket over a simple deployment exposed via service and connecting dagger-cli over TCP with _EXPERIMENTAL_DAGGER_RUNNER_HOST=tcp:// ? Maybe some possible scaling issues i'm missing here.

jagged imp
#

If i understand correctly, my only option is running a remote instance of dagger engine (still should be run as privileged?) with dagger-cli calling from CI pods spawned by gitlab runner. However, what I don't get is what the preferred way of doing so is.

yes, this is correct. Have you see our kubernets guide? https://docs.dagger.io/237420/ci-architecture-kubernetes/ This gives you a high level overview about the two approaches we see users generally follow with either persistent of ephemeral nodes

#

_EXPERIMENTAL_DAGGER_RUNNER_HOST=tcp:// ? Maybe some possible scaling issues i'm missing here.

security mostly since the engine doesn't yet have TLS or authentication support. So anyone that has access to that TCP service could potentially run privileged workloads on that node. By using unix sockets you can guarantee that only workloads which have access to the unix socket can effectively talk to the engine

tame compass
#

That makes sense, thank you! I guess unix socket accessible only from the workload is indeed more secure than internal (ClusterIP) service. Now that engine will be running along with CI pod I just have to find out how what I should expect in terms of connection handling if autoscaler decides to scale down the node. But I don't think its within the scope of dagger here. Again, many thanks for you answer!