How to start docker container as server

Question

I would like to run a docker container that hosts a simple web application, however I do not understand how to design/run the image as a server. For example:

docker run -d -p 80:80 ubuntu:14.04 /bin/bash 

This will start and immediately shutdown the container. Instead we can start it interactively:

docker run -i -p 80:80 ubuntu:14.04 /bin/bash 

This works, but now I have to keep open the interactive shell for every container that is running? I would rather just start it and have it running in the background. A hack would be using a command that never returns:

docker run -d -p 80:80 {image} tail -F /var/log/kern.log 

But now I cannot connect to the shell anymore, to inspect what is going on if the application is acting up.

Is there a way to start the container in the background (as we would do for a vm), in a way that allows for attaching/detaching a shell from the host? Or am I completely missing the point?

Answer 1

The final argument to docker run is the command to run within the container. When you run docker run -d -p 80:80 ubuntu:14.04 /bin/bash, you're running bash in the container and nothing more. You actually want to run your web application in a container and to keep that container alive, so you should do docker run -d -p 80:80 ubuntu:14.04 /path/to/yourapp.

But your application probably depends on some configuration in order to run. If it reads its configuration from environment variables, you can use the -e key=value arguments with docker run. If your application needs a configuration file to be in place, you should probably use a Dockerfile to set up the configuration first.

This article provides a nice complete example of running a node application in a container.

Answer 2

Users of docker tend to assume a container to be a complete a VM, while the docker design concept is more focused on optimal containerization rather than mimic the VM within a container.

Both are correct however some implementation details are not easy to get familiar with in the beginning. I am trying to summarize some of the implementational difference in a way that is easier to understand.

1. SSH

SSH would be the most straight-forward way to go inside a Linux VM (or container), however many dockerized templates do not have ssh server installed. I believe this is because of optimization & security reasons for the container.

2. docker attach

docker attach can be handy if working as out-of-the-box. However as of writing it is not stable - https://github.com/docker/docker/issues/8521. Might be associated with SSH set up, but not sure when it is completely fixed.

3. docker recommended practices (nsenter and etc)

Some alternatives (or best practices in some sense) recommended by Docker at https://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/

This practice basically separates out mutable elements out of a container and maps them to some places in a docker host so they can be manipulated from outside of container and/or persisted. Could be a good practice in production environment but not now when more docker related projects are around dev and staging environment.

4. bash command line

"docker exec -it {container id} bash" cloud be very handy and practical tool to get in to the machine.

5. Some basics

   • "docker run" creates a new container so previous changes will not be saved.
   • "docker start" will start an existing container so previous changes will still be in the container, however you need to find the correct container-id among many with a same image-id. Need to "docker commit" to suppress versions if wanted.
   • Ctrl-C will stop the container when exiting. You will want to append "&" at the end so the container can run background and gives you the prompt when hitting enter key.