#Dagger-in-Docker should be possible with

1 messages · Page 1 of 1 (latest)

tame bane
#

I just found this from the Argo workflow:

        - name: "_EXPERIMENTAL_DAGGER_RUNNER_HOST"
          value: "unix:///var/run/dagger/buildkitd.sock"

That's different from what I'm doing... but this seems problematic. I specify the socket through DOCKER_HOST. If I'm specifying the socket through _EXPERIMENTAL_DAGGER_RUNNER_HOST, then how am I supposed to tell Dagger which container to use?

fossil dune
#

Hi! Dagger does not use Docker or Podman at all to run containers. It talks directly to the linux kernel, via an embedded buildkit/containerd/runc stack.

The only use of docker or podman is to provision the engine's own container.

Sorry if you already know all that.

#

Are you looking to configure the Dagger CLI automatically use podman to run the engine container? Or, have you already started an engine container manually with podman, and you want the CLI to connect to that container?

tame bane
#

Right, Dagger & Dagger is a bit vague. I'm trying to get Dagger CLI running inside of a container. It works if the container has Docker CLI installed, it doesn't otherwise. Seems like the CLI shouldn't need the Docker executable, just the socket.

fossil dune
tame bane
#

Thanks, I missed that. So it looks like the Docker CLI dependency is here to stay for the foreseeable future?

fossil dune
#

no, we plan on making it pluggable in the near future. I'd say by April it should be done or at least in development. We've been pulled in many directions recently, lots of new users lately 😁

#

in the meantime there are stopgaps

tame bane
#

Understood, it's certainly low-priority. docker-cli isn't big.

fossil dune
#

the main stopgap being: run the container yourself from our oci registry, using whatever tool you want. Then point the dagger CLI at it with the "_EXPPERIMENTAL_DAGGER_RUNNER_HOST" env variable. This works now.

tame bane
#

I am still a bit confused about something, though. What I'm doing right now is trying to get a test + publish pipeline put together for my C# SDK port. Seemed like the appropriate thing to do would be to implement it in that SDK itself.

Container containerWithPackage = dagger
    .Container()
    .From("mcr.microsoft.com/dotnet/sdk:8.0-alpine3.19")
    .WithExec(["apk", "add", "--no-cache", "docker-cli"])
    .WithUser("app")
    // add source files
    .WithDind() // C# extension methods very nice, no With(Foo())
    .WithEnvVariable("_EXPERIMENTAL_DAGGER_CLI_BIN", "/usr/bin/dagger")
    .WithEnvVariable("_EXPERIMENTAL_DAGGER_RUNNER_HOST", GetEnvironmentVariable("_EXPERIMENTAL_DAGGER_RUNNER_HOST")!)
    .WithFile("/usr/bin/dagger", dagger.GetHost().File(GetEnvironmentVariable("_EXPERIMENTAL_DAGGER_CLI_BIN")!))
// ;Console.WriteLine(await containerWithPackage.WithExec(["ash", "-c", "echo '{container{from(address:\"busybox\"){withExec(args:[\"echo\",\"hello\",\"world\"]){stdout}}}}' | dagger query"]).Stdout());
    .WithExec(["dotnet", "test"])
    .WithExec(["dotnet", "pack", "--include-symbols", "DaggerSDK/DaggerSDK.csproj"])
    // and it goes on to publish
#

What I'm running into now is the tests fail - "Connection refused (127.0.0.1:38005)" (and other random port numbers). Okay, I figure the port returned by dagger session is maybe allocated by the engine rather than the CLI, in which case the test container won't have access because I haven't piped port 38005 from the host (I can't because it's randomly allocated). If I take a look at what you guys have going on in the NodeJS CI pipeline (implemented in Go), the only main difference I notice is the Dagger Engine itself endpoint-service'd directly to the Node test container. So, maybe I just need to port this to Go and put it in the same project as the others. But then again, I've done dagger run node blah.js inside of containers and it works just fine - how is the Node SDK in that case connecting to the engine, if I've only bound the socket and no ports?

wanton sedge
#

👋 if I understood correctly you're trying to achieve Dagger-in-Dagger, is that correct?

#

you're basically using your C# SDK to test your SDK that requires a dagger engine to be present?

#

in that case there's a ExperimentalPrivilegedNesting flag in the WithExec spec which allows the steps running in your pipeline to access the parent dagger engine. This also mounts the dagger CLi automatically so you don't have to download it also

#

this works:

func main() {
    ctx := context.Background()
    client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stderr))
    if err != nil {
        panic(err)
    }

    client.Container().
        From("alpine").
        WithExec([]string{"sh", "-c", "echo '{container{id}}' | dagger query"}, dagger.ContainerWithExecOpts{ExperimentalPrivilegedNesting: true}).
        Sync(ctx)
}
tame bane
#

I just did a little test and found that the dagger CLI executable is, in fact, the process that opens DAGGER_SESSION_PORT, not the engine. So, my initial assumption about why the connections were refused is wrong, but that's also reassuring because I actually understand why things work when they do.

The Node.JS tests get by without ExperimentalPrivilegedNesting

_, err = nodeJsBase(c).
    WithServiceBinding("dagger-engine", devEngine).
    WithEnvVariable("_EXPERIMENTAL_DAGGER_RUNNER_HOST", endpoint).
    WithMountedFile(cliBinPath, util.DaggerBinary(c)).
    WithEnvVariable("_EXPERIMENTAL_DAGGER_CLI_BIN", cliBinPath).
    WithExec([]string{"yarn", "test"}).
    Sync(ctx)

I suppose ExperimentalPrivilegedNesting is a nice way to make my pipeline slightly less verbose. Although testing it out just now, the dagger query invocation hangs forever without completing. Perhaps because I'm on 0.9.4. I'll merge the latest and see where that gets me.

wanton sedge
tame bane
#

It turns out that experimentalPrivilegedNesting only works when the container user is root.

fossil dune
tame bane
#

No, dagger query just hangs indefinitely.