add run command

[brancz]

Mimicking the docker-compose run command in form of

$ libcompose <service> <command>

Signed-off-by: Frederic Branczyk [email protected]

[aanand]

We should reuse the docker client's code for attaching to containers, rather than re-implementing it - it's a really complex process.

[brancz]

I agree. Maybe I'll take a look at the docker client once I have some more time on my hand, for now we'll just keep it line by line.

[brancz]

I revised all my commits and squashed them. Now the only thing I would like to improve is to really attach the container instead of just printing the log output. As @aanand mentioned, I'm going to try and reuse docker client code for this.

[brancz]

@aanand Do you think it would make sense to essentially instantiate the docker cli and call the attach command?

[aanand]

@flower-pot Yeah, essentially, though instantiating a CLI object is going to be ugly.

It might be worth trying to extract that code so it's more reusable and submitting it as a PR to docker/docker.

[brancz]

I agree. I'm going to take a look at how we can do that. The thing is, the attach command heavily relies on the hijack function which is only accessible for the cli object and package internal. And come to think about it, instantiating the cli object is really bad, since we also have to handle all settings like TLS and everything. The problem we have here is really that the docker cli is not built to be used as a library, right? Maybe the attach functionality should be added to samalba/dockerclient? (it seems like a previous attempt has failed samalba/dockerclient#3 and looks pretty complicated) To be honest, I'm really unsure on which path to continue; help appreciated 😄

[ibuildthecloud]

@flower-pot I agree the CLI functionality should be pulled out. It would nice if we could find out what the status of moby/moby#15188 is. Basically there was supposed to be an effort to refactor a lot of the CLI code.

I've been down this path before with other projects I've written and agree that instantiating the docker CLI is a nightmare. I think the correct first steps would be to figure out how to refactor the code in docker/docker to put the attach logic we need into a reusable pkg. It's just all the dirty TTY handling that we need. It can probably be encapsulated pretty well.

[brancz]

Do you think the core team is going to take care of that? It seems pretty time consuming and I'm probably not the right guy to tackle this as I'm not very familiar with the docker codebase.

[brancz]

Alright ported to the new dockerclient and now using its attach functionality. What do you think? I'm not entirely sure how to test this though.

[vdemeester]

@flower-pot Sorry for the late review. Thanks for the PR, few consideration/comments :

• docker-compose run supports more flags than this but I think it's good to focus on the main behavior and then the additionnal flags (I'll create an issue to keep track of diff between docker-compose and libcompose). We'll update the commands in PRs to follow.
• By default docker-compose run start the container with stdin and a pseudo-terminal (something like -ti in the docker cli). This is not the case in this PR — when I do a libcompose-cli run myservice /bin/bash, I can't do anything in it.

I'll take a look at the code too 😉

[cpuguy83]

Here is swarm's hijack implementation: https://github.com/docker/swarm/blob/894d1abd639eedb8234caf63fbc458a6791563bb/api/utils.go#L133

It's a bit cleaner.

[cpuguy83]

It's a little different because it's proxying, but probably useful.

[brancz]

@vdemeester no problem, I haven't had time to revise it either. I think I had the problem that when opening stdin that the stream would never close therefore the execution never ended. But I have to take another look to make sure that's the case.

[vdemeester]

@flower-pot still willing (or having time) to work on that ?

[brancz]

I don't really have the time for it right now. If you don't want to use my changes you can close the PR.

[vdemeester]

@flower-pot ok, I'm gonna carry it then 😉, keeping your commit and iterate on it 👍

Thanks for the hard work so far, really appreciated 🎅

[brancz]

@vdemeester Glad I could help :)

[vdemeester]

Carrying in #133.