12

I've been using nsenter for the last few months to get a shell running on a container for debugging purposes. I have heard about and used docker exec which was introduced in version 1.3. Docker exec seems to be the new best practice for the purpose of getting inside a container for debugging purposes, but I'm wondering if there are any drawbacks to using docker exec versus nsenter. Information comparing the two is scant. Are there any specific problems I should watch out for or avoid when using docker exec versus nsenter?

Community
  • 1
  • 1
L0j1k
  • 12,255
  • 7
  • 53
  • 65
  • If using docker 1.3 or later, I would go only with docker exec as it is now the supported way, and I suppose nsenter is no longer maintained. – user2915097 Jan 10 '15 at 10:00
  • Yes, I agree it's what was intended to fill that particular hole, and I have been and will continue using it, but I am wondering if there are any specific drawbacks to it versus nsenter. – L0j1k Jan 10 '15 at 10:02

2 Answers2

7

That is not entirely clear right now. But I would support the view that since docker exec is the official way, to go with that. The author of nsenter actually recommends using docker exec. If you encounter any drawbacks, he encourages you to report them though.

herrbischoff
  • 3,294
  • 1
  • 29
  • 50
6

docker exec versus nsenter

There are differences between nsenter and docker exec; namely, nsenter doesn't enter the cgroups, and therefore evades resource limitations. The potential benefit of this would be debugging and external audit, but for remote access, docker exec is the current recommended approach.

Only works on Intel 64 bits platforms. Arguably, this is the only officially supported platform for Docker; so it's not a big deal.

nsenter still needs to run from the host; it cannot run inside a container (yet).

ref: https://github.com/jpetazzo/nsenter/blob/master/README.md

user31986
  • 1,558
  • 1
  • 14
  • 29
  • 1
    A rather technical side note than an answer. OP asked for "specific problems […] to watch out for or avoid when using". You come to the same conclusion that docker exec is the recommended way for access and describe no "specific problems" for either approach. What's the reason for this post? – herrbischoff Jan 02 '16 at 15:26
  • 1
    Well those are useful details if you are looking from an engineer's perspective (and not a sysadmin's). – user31986 Mar 23 '16 at 00:51
  • I for one appreciate the 110% @user31986. There's always an edge-case hiding in the shadows that'll bite you, but then you just might remember ... – AJB Apr 12 '17 at 09:56