#Use Dagger with Alternative OCI Runtimes...
cosmic nimbus
FWIW, we are looking at using the Go SDK for some other things, so if we can use Dagger here, that would be ideal. The gap is in knowing if I can exec a container into the background and then get the dynamic port. It looks like I would have to get more detailed (more code|options) via dagger, but that is not an issue if I don't have to worry about OCI runtimes
warm spindle
It's about being able to start the Dagger Engine container (which includes buildkit + other components), yourself with your favorite tools and container runtime; then configuring dagger CLI to talk to that engine instead of auto-installing one
In the case of podman, you can also trick the dagger CLI into using podman to auto-install (by symlinking podman to docker)
cosmic nimbus
So basically, because the three cli tools have the same "api", you can symlink and get the desired outcome without much fuss?
warm spindle
mmm which three?
docker and podman, yes (mostly)
no third tool in that situation that I know of
cosmic nimbus
nerdctl is the third
warm spindle
ah. possibly!
cosmic nimbus
it's in your docs lol
warm spindle
then yes! our docs are always right 😁
it is also possible to run the dagger engine container with any other container runtime, not just those cli-compatible with docker. It just involves a slightly different approach
- Approach 1: trick auto-installer with docker symlink
- Approach 2: run container manually, set
EXPERIMENTAL_DAGGER_RUNNER_HOST
full spire
warm spindle
man our private linear is leaking all over the place, sorry
cosmic nimbus
this sounds like where we are headed, where our approach 2 is "configure something you started elsewhere by adding this CUE"
We are using this for starting our formatting containers that hof relies on, and eventually some other hof containers, which it sounds like dagger is doing.
side note, this sounds like it answers my question about where the server that the SDK calls lives, next to the BuildKit container as another running container? (ignoring any advanced setups)
warm spindle
My advice is to let your own end user decide
by just passing through the default behavior
warm spindle
side note, this sounds like it answers my question about where the server that t...
the graphql router is an ephemeral local proxy that is spawned by the dagger CLI
cosmic nimbus
yeah, that jives with what we are thinking more generally. Today we only support Docker for those containers when auto-starting, but we can replace the Docker SDK with an exec, and in doing so support all three (docker, podman, nerdctl) by using the symlink hack
warm spindle
we plan on moving it eventually into the engine container. But not yet possible because the graphql API leaks information about its host - it cannot be sandboxed
cosmic nimbus
so if I use the Go SDK, does it also spawn a ephemeral proxy?
warm spindle
warm spindle
so if I use the Go SDK, does it also spawn a ephemeral proxy?
yes, all SDKs do
it allows vastly way more code reuse between SDKs
and makes SDKs way easier to develop
cosmic nimbus
yeah, totally makes sense, was unclear on the mechanics of that.
have you looked into auto generating the SDKs from the schema?
btw, are those the new GitHub mermaid diagram support in markdown on that issue?
warm spindle
SDKs are indeed auto-generated 😁