Add `docker compose attach`? (to support STDIN)

[g0t4]

Description

Similar to docker container attach, would docker compose attach be a reasonable thing to add? I'd like to attach to STDIN/OUT simultaneously and send input to my service container(s) and see their output. AFAICT, docker compose up only attaches STDOUT.

For example, I have a compose project w/ a single service that runs dotnet watch. If changes can't be hot reloaded then I can send Ctrl+R to the dotnet watch process to trigger a rebuild.

I can use docker container attach to send Ctrl+R currently as a workaround with stdin_open: true and tty: true in my service definition.

Ideally this would also be combined with docker compose up to bring up and then attach STDIN right away.

• perhaps docker compose up -i/--interactive?
• and either a single service limitation
• or if multi service then broadcast to all STDIN
• I would also understand if this is too confusing to merge with up in which case attach alone would be great

[ndeloof]

I don't have any objection to a new docker compose attach command.
Adding --attach to up would introduce requirement to select a single service and then would break the logic of the command IMHO, better have a dedicated one (not to mention code would be easier to read then :P)

[g0t4]

I'll take a stab at the new subcommand and see where I can get with it.

[g0t4]

Nevermind for now, I just found an existing attach service in docker/compose, I'll see if it works for my use case before we worry about using docker/cli's impl

@ndeloof I noticed for docker compose exec you modified docker/cli to make RunExec public: docker/cli@2d26839

Given that runAttach in docker/cli(https://github.com/docker/cli/blob/814f70749abd0e131da6456d8895b5695950a4af/cli/command/container/attach.go#L73-L74) is not public, what would be the best course of action to implement docker compose attach? How long would changes to docker/cli take to get through to docker/compose?

[g0t4]

@ndeloof got a first pass working!

main...g0t4:compose:11153-compose-attach

IMO the best course is to make docker/cli's runAttach => public as RunAttach and invoke that from compose attach. Just like compose exec defers to RunExec which is a very similar use case to attach in terms of I/O.

Doubly so I am convinced of this given docker compose attach ≈ docker container attach $(docker compose ps -q foo)

[ndeloof]

we for sure can make runAttach public for the same reason (and ideally update func to pass command context) to avoid too much code duplication. But if you have a short-term implementation that's also fine, just need to note this to be removed as long as docker/cli is updated for our needs.

[ndeloof]

see docker/cli#4637

[g0t4]

Thanks to your comment about command context... I just realized NewAttachCommand is already exposed and I got a prototype working with just that. I will start a new branch with that and submit a PR if that sounds good to you?

Here's the prototype commit: g0t4@41950d5

This can be a stop gap until we can call RunAttach or maybe this is preferred given it attaches to the stable contract of the docker container attach.

[g0t4]

@ndeloof Here we go, working great for my test cases, is this ready to start a PR and refine?
main...g0t4:compose:11153-compose-attach-override-container-attach-cmd

[ndeloof]

please open a PR

[ndeloof]

closed by #11181