Hey folks. I was wondering if you had | Dagger | Page 1

deep plaza May 30, 2024, 3:13 PM

#

Pinging @south barn Who has been thinking about this sort of thing and blogging about it https://dagger.io/blog/argo-cd-kubernetes and @amber parrot

On-Demand Dagger Engines with Argo CD, EKS, and Karpenter - Dagger

Powerful, programmable CI/CD engine that runs your pipelines in
containers — pre-push on your local machine and/or post-push in CI

tranquil quail May 30, 2024, 3:39 PM

#

@fluid trail we're in the process of improving and clarifying those best practices. So be advised that 1) some of the best practices are still in flux, 2) it's improving rapidly (prod-readiness is our top priority internally)

#

The key is to think of Dagger as a specialized container engine. It plays nice with other engines (docker, podman), and you can even run it in a container, orchestrate it with kubernetes, etc. But fundamentally Dagger's job is to run containers, and it needs the privileges to do that.

#

So, it's definitely possible to mix Dagger engines with other workloads on a kubernetes cluster for example. But if you're looking for maximum isolation, you should consider running those engines on dedicated compute.

fluid trail May 30, 2024, 5:15 PM

#

That is a great post, I will share that with the team. Thanks for the information. My fundamental concern is that the priveleged dagger engine containers become compromised and since they have the host's socket mounted, that could potentially spread wider. Sounds like the best idea for now is to keep things isolated.

tranquil quail May 30, 2024, 5:18 PM

#

In doubt, I would say yes. We architected Dagger for much stronger isolation than Docker. So eventually, we will be able to guarantee that socket access does not mean unlimited host access. But today we can't make that guarantee (yet)

#

The big design difference if you're interested: Dagger-in-Dagger is a core concept, with proper nesting (similar to the unix process tree, aka "processes in processes"). Whereas Docker-in-Docker is a big hack and always will be

#

So the ideal architecture, eventually, will be:

Run dagger engine on dedicated compute
Run CI runners containerized inside dagger
CI runners get a scoped dagger socket inside their container: they can make dagger calls, without ever leaving their sandbox

#

At that point you can remove externally accessible socket completely: to be a dagger client, you need to be run by Dagger. Just like to make a Linux system call, you need to be run by that Linux kernel (there is no privileged remote access socket straight to the kernel)

#Hey folks. I was wondering if you had