0

Here is another question from a Docker newbie. I currently run my Docker image in "debugging mode" with bash so that I can docker attach to the running instance to enter a shell where I can inspect the application’s OS environment, etc., at runtime.

docker run <image-id> -d -it bash -c “<start application in background>; bash”

I am wondering whether I should have bash always included, i.e. change the CMD inside Dockerfile from CMD <start application in foreground> to CMD <start application in background>; bash.

Would this be inappropriate in "production mode"

  1. for security reasons -- Who is allowed to attach to a running instance?,

  2. in light of Docker being an application isolation tool, not an OS virtualization tool,

  3. for other reasons?

Community
  • 1
  • 1
Drux
  • 11,992
  • 13
  • 66
  • 116
  • 1
    Don't do this in production. What are you running in the app? You generally want your app to be the front-most process (PID 1), not `bash`. You want to get used to treating containers like set-and-forget -- or at least not something you need to access manually once it's in production. The whole [Cattle vs Kittens](https://www.google.com/search?q=docker%2Bcattle%2Bvs%2Bkittens) thing. – ldg Jul 18 '16 at 05:39
  • 2
    Additionally, you ideally want your dev containers to be the same as your production ones, so I wouldn't even use that `bash` approach in dev other than for a temporary testing situation. You can always `docker exec ...` into the container later if need be. – ldg Jul 18 '16 at 05:45
  • @ldg Excellent. (As a newbie I did not yet know about `docker exec`. If you want to write up your comment as an answer I shall promptly accept it. – Drux Jul 18 '16 at 09:36

1 Answers1

3

Don't do this in production.

You want your app to be the front-most process (PID 1), not bash.

Ideally your dev containers would be the same as your production ones, so I wouldn't even use that bash approach in dev other than for a temporary testing situation. You can always docker exec into the container later if need be. E.g.,

docker exec -it {container-name} /bin/bash

Where:

>   -i, --interactive    Keep STDIN open even if not attached
>   -t, --tty            Allocate a pseudo-TTY

Change the name of the executable as needed (e.g., /bin/sh, etc.). You many need to set the TERM environment variable for some containers. (e.g., export TERM=xterm).

To just return a result and close, leave out the -it like:

docker exec {container-name} ifconfig

You want to get used to treating containers like set-and-forget -- or at least not something you need to access manually once it's in production.

ldg
  • 9,112
  • 2
  • 29
  • 44