Support `docker exec`

[xpayn]

This would be really useful to my project. I don't know if you have any plan for this, maybe it's out of scope for cage. I tried to give a quick look at docker's client source code, but wasn't able to find where magic really happens.

[emk]

Thank you for the interest! Cage uses docker-compose run and docker-compose exec as necessary, because it's trying to maintain compatibility with Docker compose. We'd love to have a feature like this directly in boondock but we're unlikely to implement it ourselves any time soon. But if you figure out how to implement it, we're always happy to look at PRs with test cases!

[xpayn]

I might take a look at it, but i'm not sure to have time and skills for it.

[xpayn]

@emk i'm currently looking into it and i'm struggling with the REST api it seems exec needs a post request with a json payload. it wasn't really hard to do, but the daemon responds with an internal error and nothing in the logs. i'd like to be able to see what docker cli sends to the daemon in order to see what's missing in my calls do you have some advice?

[emk]

Yuck. OK, so I can think of three ways to tackle this:

1. Switch your Docker daemon to use HTTP over TCP (instead of Unix streams), and try to use Wireshark to dump the HTTP requests. But if Docker is using HTTPS, this will be annoying difficult because you'll need to give Wireshark access to the SSL certs.
2. You could recompile the Docker client or Docker daemon to dump the HTTP message.
3. You could look for debugging flags on the Docker client and Docker daemon, and turn them up to the max.

[xpayn]

i already tried to use a tcp socket inside an ubuntu VM and it works. not sure if it's possible with docker for mac anyway, thanks, i should have waited a little before bothering you

[emk]

No, it's fine. I'm happy to answer questions! I'm just overloaded with a bunch of different Rust stuff, so it may sometimes take a while for me to respond, though. I definitely appreciate your efforts to get docker exec working!

[xpayn]

i currently have something for detach mode, but the real deal is when you want to get process' output. Docker seems to do voodoo things (if i understand correctly): the http connection is closed but the underlying tcp socket is kept open and used to send process' output (they call it 'hijack' which seems appropriate). They also do things to modify/restore the terminal, but i think it's out of boondock's scope.

To continue advancing on this issue, i will need help from the docker team to help me understand what's really going on and then from @seanmonstar to see if sech things are doable with hyper 0.9

Do you know what's the best way for both projects to get some help ? IRC ? Gitter ?

[tshepang]

That probably explains why exec doesn't return anything on shiplift. Note that the version with that feature is not yet released.

[kpcyrd]

I found this issue while looking for docker run -it, which would probably have the same issue.

As far as I can tell boondock would need to create the tcp/unix socket itself, then borrow it to an http library for the request and then take the socket back, as the processes stdio seems to be connected to the socket at this point.

I think we're hitting boundaries here, as the docker api doesn't seem to be a REST api (eg. /images/create is supposed to be streamed to display progress) :)

I'm not sure I can help here, but I would love to have this implemented!

[emk]

Yup, for some of these operations like run -it, it may honestly be easiest to invoke the docker CLI tool. That's how cage handles these issues—boondock for getting machine readable information, but docker for some of the trickier exec commands.

I'd certainly love to have support for these features in boondock, and I'd be happy to review PRs, but it's unlikely that I'll have time to work on these features myself.