Is it possible to add attach function to fig?

[0xcb49]

For example, Using command "fig attach appname" to enter the container which was created by fig.
I think this may be helpful in some cases. Now I know that nsenter can attach a new bash shell on
a running container, but I don't know if it's possible to intergrate it with fig. Thanks.

[shuron]

Need it too!

[marksteve]

docker-enter (https://github.com/jpetazzo/nsenter/blob/master/docker-enter) is just a bash script.
I supposed you can base on that to write a fig-enter script.

[0xcb49]

Maybe it's more convenient to use alias below in your terminal.
alias attach='bash -c "nsenter --mount --uts --ipc --net --pid --target docker inspect --format \"{{.State.Pid}}\" \$0"'
Then you can use attach container_name to enter a container.

[dnephin]

It shouldn't be too difficult to add this using dockerpty, which is what fig is using right now to handle fig run, I think.

[thaJeztah]

@bcheng049 the docker-enter script also handles some edge-cases (e.g. If you're not using bash as your shell), and makes sure to set up the environment variables of the container and not your host environment. The alias you're suggesting, won't handle those.

[erickbrower]

This would be huge for my team also

[0xcb49]

@thaJeztah Yes, it is just a snippet to avoid inputing many commands without installing a script.

[thaJeztah]

Just wanted to clear that up to prevent people trying to solve problems that are already solved in the docker-enter script. Adding this functionality to fig would be a nice addition though (still hoping Docker itself will support this natively).

In the short run, I'd really advice people that want to have it now to install jpetazzo's script. Installing it is just a one-liner as explained in the readme; https://github.com/jpetazzo/nsenter

After installing, entering a running container is just simply docker-enter [container-name]

[tristanz]

There's two issues here: 1) being able to enter with nsenter and fiddle around with a running container, and 2) a way to get docker run web bash behavior but also bring up the entire stack not just direct links. The first is great for debugging and the second is great for development workflows with volumes mounted into containers. Just bringing up links is not enough for many stacks.

[dnephin]

I think fig up -d, fig run solves 2, but I'm not really clear on why you'd need to bring up services if they aren't linked. A container doesn't need to be running to share volumes.

[tristanz]

The set up I have in mind is proxy -> web -> db. I'd like to be able to bring this stack up, but develop in web using a bash prompt. I haven't found an easy to to do this, such that all the links work.

[robsonpeixoto]

attach and interactive is very useful to debug the running software using tools like python pdb.

[baptistedonaux]

It's an essential feature to configure docker container. When this feature are release ?

[aanand]

I agree that fig attach and fig exec, analogous to their docker counterparts, would be good to have. Is anyone here asking for anything other than those?

[Stono]

It would be nice if attach was exposed in fig.yml, so that we could specify which one we want to attach to interactive tty on "fig up"

[Stono]

@aanand Any update on when this may be available?

[MrMMorris]

this would be lovely!

[aanand]

I'm strongly against the idea of doing an interactive attach on fig up - it's overloading its purpose.

The correct way to bring up an interactive container with its dependencies is fig run. We just need to get port mapping implemented (see #485, which I'll get to soon).

[itoed]

Aanand, you said:

I agree that fig attach and fig exec, analogous to their docker counterparts, would be good to have. Is anyone here asking for anything other than those?

I believe just those two will make a lot of people happy.

I don't use fig scale and I'm not sure if you have considered how fig attach and fig exec would work with those. I suppose if I were to use fig scale I wouldn't care which container was used.

Will this issue address both fig attach and fig exec, or would it be better if a separate issue was logged?

[dnephin]

oops, wrong key, sorry

[michaelsbradleyjr]

@aanand even if it doesn't make sense in the context of fig up to have an "interactive" container/s, would it be reasonable to allow a service to allocate a pseudo-TTY, i.e. to have a fig.yml key which has the same effect as docker cli's run -t flag?

[aanand]

@michaelsbradleyjr that might make some sense, in that there have been reports of software that complains if it can't find a tty.

Still, I'm worried that such an option might confuse people into thinking that fig up will be interactive. Maybe if it's called pseudo_tty, that won't be an issue.

[koddo]

@aanand, @michaelsbradleyjr, I second that. When I do fig up, I can't get an erlang shell on a remote node. I have to do 'fig run' and then something like this works:

$ docker exec -it foo_web_run_1 erl -remsh '[email protected]'

I'd like to be able to get the repl even in production environment.

[michaelsbradleyjr]

@koddo I've been doing something similar. By the way, there's a tty-related bug in docker exec:

moby/moby#8755

The documentation and help output don't mention it, and it can be tricky to figure out what's going on if you don't' think to check the output of the tty command. Anyway, I just wanted to give you a heads up in case you weren't aware of the bug.

[thomasf]

Just to help anyone looking here out I just found a simple solution that works for me.

docker-compose.yml now supports this:

app:
  tty: true
  stdin_open: true

This also makes it possible to after the containers are up do docker attach project_app_1 which seems to work fine.

I have no idea when this started getting possible but it works for me using docker 1.8.2 and docker-compose 1.3.3. Very thankful for this, it has been my major turnoff for developing using compose and python with pdb.

Just wanted to make this clear because I did not get that it was this easy at all by reading this issue conversation.

Mirroring the attach from docker in docker-compose would also be nice but for me it isn't a requirement as long as the procedure is simple.

[cameron]

@thomasf to the rescue!

[jaccarmac]

tty: true
stdin_open: true

does not work for me. It may be because I'm on Windows, or it may be a bug in a newer version of Compose. I'm on 1.6.0.

[kaiomagalhaes]

Thanks @thomasf, you made my day

[gkop]

Curious, what is different between docker-compose up <service> and docker-compose up -d <service> followed by docker attach <service-instance> that @thomasf' solution for interactive debugging works with the latter but not with the former? (using pry, with the former, execution stops, but standard input doesn't seem to make it to the container).

[aanand]

'up' does not hook up the terminal stdin. It's not designed for interactive
use, because it usually operates on multiple containers.

On Tue, 17 May 2016 at 00:02 Gabe Kopley [email protected] wrote:

Curious, what is different between docker-compose up and docker-compose
up -d followed by docker attach that @thomasf
https://github.com/thomasf' solution for interactive debugging works
with the latter but not with the former? (using pry, with the former,
execution stops, but standard input doesn't seem to make it to the
container).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#423 (comment)

[k2nr]

Because I also wanted to attach to a running rails server process to communicate with binding.pry, I am using the following simple script, which works well for me.

#!/usr/bin/env bash
docker attach $(docker-compose ps -q $1)

Name it docker-compose-attach and then run docker-compose-attach <service>

But I believe it's better for docker-compose to have attach subcommand

[gkop]

Our team has observed that while the config suggested by @thomasf does work nicely to permit interactive debugging of running containers, tty: true causes strange and unfortunate side effects when running docker-compose logs: the timestamps are missing from the logs and we get disconnected after 1 minute.

@k2nr first of all, thank you for the alias - it is certainly handy for myself and my team, as attach is a viable workaround in the face of the issue with the logs ^^ . I don't think however it belongs as a proper subcommand to docker-compose because it assumes that you only have one docker instance of the service running, which is not realistic in many cases.

[gkop]

@dnephin I think what we're observing in first paragraph above ^^ might be an incident of #3106 (comment) - it's apparently tty that's triggering the timeout and missing timestamps in docker-compose logs.

Should I create a separate issue for this?

/cc @thaJeztah

[shin-]

With #3106 fixed and exec and run implemented, I believe this can be closed. I don't think there's a scenario where attach makes a lot of sense (especially over the two other subcommands).

[JamesLivengood]

@thomasf That worked for me to get into a debugger, but it doesn't let me type anything - like typing in c, or n to continue through doesn't work (I have to ctrl + C and close the server to get out of it)