Should I create a docker container or docker start a stopped container?

Question

From the docker philosophy's point of view it is more advisable:

1. create a container every time we need to use a certain environment and then remove it after use ( docker run <image> all the time); or
2. create a container for a specific environment ( docker run <image> ), stop it when it is not necessary and whenever it is initialized again ( docker start <container> );

Answer 1

I'm talking with regards to my experience in the industry so take my answer with a grain of salt, because there might be no hard evidence or reference to the theory.

Here's the answer:

TL;DR: In short, you never need the docker stop and docker start because taking this approach is unreliable and you might lose the container and all the data inside if no proper action is applied beforehand.

Long answer: You should only work with images and not the containers. Whenever you need some specific data or you need the image to have some customization, you better use docker save to have the image for future use.

If you're just testing out on your local machine, or in your dev virtual machine on a remote host, you're free to use either one you like. I personally take each of the approaches on different scenarios.

But if you're talking about a production environment, you'd better use some orchestration tool; it could be as simple and easy to work with as docker-compose or docker swarm or even Kubernetes on more complex environments.

You better not take the second approach ( docker run , docker stop & docker start ) in those environments because at any moment in time you might lose that container and if you are solely dependent on that specific container or it's data, then you're gonna have a bad weekend.

Answer 2

If you docker rm the old container and docker run a new one, you will always get a clean filesystem that starts from exactly what's in the original image (plus any volume mounts). You will also fairly routinely need to delete and recreate a container to change basic options: if you need to change a port mapping or an environment variable, or if you need to update the image to have a newer version of the software, you'll be forced to delete the container.

This is enough reason for me to make my standard process be to always delete and recreate the container.

# docker build -t the-image .  # can be done first if needed
docker stop the-container      # so it can cleanly shut down and be removed
docker rm the-container
docker run --name the-container ... the-image

Other orchestrators like Docker Compose and Kubernetes are also set up to automatically delete and recreate the container (or Kubernetes pod) if there's a change; their standard workflows do not generally involve restarting containers in-place.

I almost never use docker start . In a Compose-based workflow I generally use only docker-compose up -d , letting it restart things if needed; docker-compose down if I need the CPU/memory resources the container stack was using but not in routine work.