Remote builder

[prisma wasp]

Short answer: not at the moment but there is an experimental setting that WILL break in the future

[dry wing]

Ok, not even if I define the environment variable BUILDKIT_HOST?

[prisma wasp]

correct. there is _EXPERIMENTAL_DAGGER_RUNNER_HOST which will work the same way. It works today but WILL break in the future once wr introduce the final version of this feature

[dry wing]

TL;DR I'm deploying a build system that is running on AWS ECS and can't run buildkit, so we deployed a CoreOS stack with buildkitd as a container in podman.... That is running on an internal DNS record. I'm looking to replace my custom Go program with Dagger

I mean, it will break in the final - but if I have some decent tests I should see that right? I'm running a test stack with a local docker-compose.yaml that runs both the Go program and buildkit...

Also, is there existing documentation on configuring the clients (other than the Go docs)?

[prisma wasp]

let me get to a real keyboard 🙂

[dry wing]

(btw, love what you are doing - I completely understand the speed and nature of the project - don't want to sound ungrateful)

[slow anchor]

There are docs here (with caveats mentioned above about being unstable, hence why they are hidden off in our repo and not on the website): https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md#connection-interface

I did just realize that I need to update that section as we support more connection types now, including podman-container://<name of container>

[prisma wasp]

What Erik said 👆

[dry wing]

Honestly, Dagger simplified almost all of my Go code... so that is 🥳

[prisma wasp]

Basically we are in a state of transition between architectural models. While we make the transition, we don't people to be stuck, hence the experimental setting.

[dry wing]

I'll probably just use that experimental feature and see if I can write a good integration test for if/when it changes

Yeah, I tried the alpha of Dagger and it was good - but this approach is a huge improvement

So 👏 on the work being done to the team

[prisma wasp]

@dry wing the important thing to understand is that, in the new model we are moving towards, dagger will not support swapping out buildkit. Going forward we consider buildkit to be an internal component. This is because some of Dagger's features require tight control over the version, build and configuration of buildkit to work properly.

So we will never support BUILDKIT_HOST for that reason. But we will support something equivalent

Another reason for this, probably most important: the dagger runner API may in the future extend to be not just a pass-through of the buildkit API, but a superset of it

[dry wing]

Hmmm, that is interesting... since its being considered an internal component... Doesn't that limit the deployment options for Dagger SDKs? Internal assuming that it needs to be installed on the same machine/container of the SDK?

[prisma wasp]

We ship the Dagger engine as an OCI image. So you can provision it yourself in the manner you prefer, then configure your clients to connect to it. This is the feature being developed now.

Of course under the hood it’s still buildkit plumbing so all works roughly the same

So buildkit is internal to that engine, not to the client SDK

[spark niche]

Note that AFAIK, this is already the case. The docs pointed to by @slow anchor explain how to provision the ghcr.io/dagger/engine image rather than buildkitd

Since the dagger image is a superset of the buildkit image (we build on top of buildkit, but we have extra stuff on top)

[slow anchor]

That ^ but you should still be able to use podman if you like, just need to run that image instead of moby/buildkitd.

Also, this PR documents podman-container:// (and a few other conn types if you are ever interested): https://github.com/dagger/dagger/pull/4352

[dry wing]

Ok, but when using the Go SDK... I'm not using the Dagger image... at least I have not reach the "deploy my code that uses the SDK" yet so maybe that is where I would using the image?

[spark niche]

At the moment dagger has its own OCI runner to inject its shim (used to support things such as dagger-in-dagger, grabbing stdout/exitCode from Exec() calls, etc). In the future the gap will broaden, hence why we don't support "vanilla buildkitd"

[dry wing]

Sorry if these questions seem kind of silly

[spark niche]

The Go SDK by default will provision its own engine locally, under the hood (you can see it in docker ps). That documentation file explains how you can provision one on your own, manually, and use the experimental ENV var to point the SDK to it (bypassing auto local provisioning)

If that makes sense

[dry wing]

I think I get it... right now I have a server running buildkit and exposing as a TCP service... I would instead replace that with a container running the dagger image, which internally houses buildkit as the internal dependency

[dry wing]

That makes more sense... because the Go SDK is running dagger behind the scenes in a container...

So really what I should be doing is dropping the buildkitd service and replacing it with a container exposing the Dagger container - then the Go SDK would use the remote builder option to connect and run the builds

If that is right, thank you all for the session - I also just finished the buildkit coreos build last night - easy enough to swap out though 😉

[dry wing]

Thank you @slow anchor - I am assuming those interfaces are supported right now but were not documented.

[spark niche]

Of course! This has been confusing for many, hopefully the instructions will help understanding what's going on. Please let us know if they make sense or need more clarification -- they're fresh from the press (merged yesterday)

[dry wing]

I'm browsing the docs now - thank you... I think the only thing I am missing is how to run the dagger instance as a container (e.g. exposing it over TCP). Buildkit has this section (https://github.com/moby/buildkit#expose-buildkit-as-a-tcp-service) but I'm not sure what the equivalent would be on the dagger image?

[slow anchor]

Correct, just hadn't updated the docs after support was merged yet.

[slow anchor]

I'm browsing the docs now - thank you... I think the only thing I am missing is how to run the dagger instance as a container (e.g. exposing it over TCP). Buildkit has this section (https://github.com/moby/buildkit#expose-buildkit-as-a-tcp-service) but I'm not sure what the equivalent would be on the dagger image?
Yeah that's currently where you'll have to be willing to engage in some DIY if you want to go that route. Currently the entrypoint to the dagger engine image is just buildkitd, so you can configure buildkitd to listen on a tcp socket with flags there (see buildkitd --help or those docs you linked to). That again is something subject to breakage at any point.

However, if it's possible for your use case, a likely better route would be to use a different conn type like podman-container:// (or docker-container:// orkube-pod://). If you use those, you don't have to change the buildkitd configuration at all. You can just start the dagger engine image in podman (or docker or k8s) and just point your client to it by the container name.

[dry wing]

Ok perfect, I'll just adjust that to use the flags I linked - thank you all again!!

[prisma wasp]

@dry wing while I'm at it, I'll flag an evolving best practice: you can wrap your dagger client with dagger run. For example dagger run python myscript.py or dagger run my-custom-tool. You can use this as a reliable way to "inject" the desired configuration into your dagger session.

For example:

_EXPERIMENTAL_DAGGER_RUNNER_HOST='podman-container://my-dagger-engine' dagger run my-tool

This will be the recommended way to run dagger clients in production going forward. We will add various configuration options, available not only by env variables but also CLI flags and config file.

It's not mandatory - you can also run your tool directly as you already do. But we anticipate that in the long run, it will be more practical and more reliable to use the dagger run wrapper, at least in production

[dry wing]

Since I'm using the Go SDK, I'm passing a flag to the program that tells me the address for the dagger engine - I'll set the env var using Go to make it easier - thanks!