Skip to content

Add dial-stdio command - #2112

Merged
tonistiigi merged 1 commit into
docker:masterfrom
cpuguy83:dialstdio
Feb 10, 2024
Merged

tonistiigi merged 1 commit into
docker:masterfrom
cpuguy83:dialstdio

Conversation

@cpuguy83

Copy link
Copy Markdown
Contributor

This allows the buildx CLI to act a proxy to the configured instance. It allows external code to use buildx itself as a driver for connecting to buildkitd instances.

Instance and node selection should follow the same semantics as as buildx build, including taking into account the BUILDX_BUILDER env var and the --builder global flag.

Comment thread build/dial.go Resolved
Comment thread driver/docker/driver.go Resolved
Comment thread commands/dial_stdio.go Resolved
Comment thread commands/dial_stdio.go
}
defer conn.Close()

go func() {

@jedevc jedevc Nov 14, 2023 •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we extract the logic for dial-stdio in buildkit into a reusable function so we could just call that here after getting the conn? Ideally, we wouldn't end up with diverging implementations in buildctl/buildx (e.g. that would make it a pain to fix bugs in the future, etc).

We're also having the same thing in dagger, where we need dial-stdio for the connhelper, but don't really want to ship all of buildctl, so it would be cool to have just one implementation to call instead of needing to extract the relevant code.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One implementation of what exactly?
the main part of this is just wiring up copy operations.
I'm not sure its worth sharing an implementation of that?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I think I'm just confused by the differences in handling CloseRead/CloseWrite here versus in buildctl. Given that they seem to be doing the same thing, I'm not quite sure I understand why the code is so different.

@cpuguy83 cpuguy83 Nov 14, 2023 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda I'm curious on this case where its wrapping with a nop-closer.https://github.com/moby/buildkit/blame/5ae9b23c40a926615b6c3cc1da3f5457d2f61fd4/cmd/buildctl/dialstdio.go#L35

I don't think we necessarily need the stream to handle a half-close here, just that it s a little cleaner in terms of the connection semantics (hence why its implemented here).

Other than that I think the implementation is pretty much the same, just this is taking advantage of errgroup and buildctl is basically doing its own hand-rolled equivalent.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my memory, tty stuff didn't work correctly without handling half-close there

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to test for using tty as stdin/stdout but this broke http2.
Not sure how to check for this.

Fundamentally though, the only real change as compared to buildctl would be to not fallback to Close on when CloseRead is not implemented.

@cpuguy83
cpuguy83 force-pushed the dialstdio branch 7 times, most recently from 78aac86 to ea99e40 Compare November 16, 2023 21:27
@cpuguy83
cpuguy83 marked this pull request as ready for review November 16, 2023 21:27
@crazy-max crazy-max added this to the v0.13.0 milestone Dec 23, 2023
Comment thread commands/dial_stdio.go Resolved
Comment thread build/dial.go Resolved
Comment thread build/dial.go Resolved
Comment thread driver/remote/driver.go Resolved


<!---MARKER_GEN_END-->

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a bit more description/usage here. It isn't entirely obvious for new user what "dial stdio" means.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added extra docs.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what changed for this

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔
I wrote stuff... apparently I did not commit it somehow.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed up again.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I know what happened... I did docs the wrong way.

@cpuguy83
cpuguy83 force-pushed the dialstdio branch 3 times, most recently from dd3ca7c to 94f5985 Compare January 27, 2024 21:55
@cpuguy83
cpuguy83 force-pushed the dialstdio branch 4 times, most recently from 9b657e9 to 0c5390f Compare February 8, 2024 20:06
Comment thread docs/reference/buildx_dial-stdio.md Outdated

## Description

dial-stdio uses the stdin and stoud streams of the command to proxy to the configured builder instance.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stdout

Comment thread docs/reference/buildx_dial-stdio.md Outdated
# docker buildx dial-stdio

<!---MARKER_GEN_START-->
Dial stdio

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Proxy current stdio streams to builder instance"

Comment thread docs/reference/buildx_dial-stdio.md Outdated
## Description

dial-stdio uses the stdin and stoud streams of the command to proxy to the configured builder instance.
It is not intended to be used by humans, but rather by other tools that want to interact with the builder instance API.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"builder instance API." -> "builder instance via BuildKit API"

Comment thread docs/reference/buildx_dial-stdio.md Outdated
}()

client.New(ctx, "", client.WithContextDialer(func(ctx context.Context, s string) (net.Conn, error) {
return c2, nil

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use static instance here? I think it should invoke new command when dialer gets called.

func dial(...) (net.Conn, error) {
  _ = exec.Command()
  ...
}

client.New(ctx, "", client.WithContextDialer(dial))

Comment thread docs/reference/buildx_dial-stdio.md Outdated
cmd.Stdin = c1
cmd.Stdout = c1

if err := cmd.Start() {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err := cmd.Start(); err != nil

Comment thread docs/reference/buildx_dial-stdio.md Outdated

```go

client.New(ctx, "", client.WithContextDialer(func(ctx context.Context, s string) (net.Conn, error) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: remove the parameters variable names if they are unused

This allows the buildx CLI to act a proxy to the configured instance.
It allows external code to use buildx itself as a driver for connecting
to buildkitd instances.

Instance and node selection should follow the same semantics as as
`buildx build`, including taking into account the `BUILDX_BUILDER` env
var and the `--builder` global flag.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants