Docker Community Forums

Share and learn in the Docker community.

Why Do Containers Still Exist After an Image Exits?


(Nobozo) #1

I’m learning Docker. One question I had right away after running the standard “hello-world” image is why the container that ran it still exists after the image exits. I had naively thought that maybe there’s some kind of caching going on so that the next time I run “hello-world” it would run in the same container, but that doesn’t appear to be true. I know I can remove a container by running “docker container rm XXXX” but why is that necessary? When would keeping a container around after the image it runs exits provide any value?

Thanks,
Jon


(Martin Terp) #2

In some cases, it could be nice to check WHY it exited, which you cant if you remove the container.
If you want it to delete, after it exists, you can add: --rm to your docker run command.

And yes, docker run would create a new instance of the image, if you want to start and exited container, you can use: docker run INSTANCEID/INSTANCENAME


(Raj Chaudhuri) #3

An image is a template, like a class in object-oriented programming. From a single image, you can create any number of containers. Each container can be started and stopped multiple times. An image is never “started” or “run”…it can only be used to create containers.

The confusion comes from the command docker run or docker container run, which both creates a container and also starts it. A better way to learn the concept is to use the docker create or docker container create command to create a container, and the docker start or docker container start command to start it.

A container that has been created (using either the create or run command) continues to exist even after the application in the container exits. It can be started again, any number of times, with the start command. When done with it, you can remove it using the rm command.

Each container maintains all its settings (passed as parameters in the run or create commands), it logs, and some state in its filesystem (the container storage layer) until it is removed.


(Nobozo) #4

Thanks for taking the time to reply.

I already understood the distinction between creating a container and starting it. What’s still not clear to me is what value there is in keeping a container in existence after the image it runs exits. Since containers can be created so quickly, is there really a need to “start” the same container over and over? Sure, as another person said, it can be useful to see why an image exited, but that’s probably not the common case.

Also, let’s say you’re doing something that results in lots of containers being created, and at the end of the day you have 100 containers not doing anything on your system. What resources does each container consume? I know each container is a process so each container consumes at least the same resources as a non-container process. Anything else?

Jon


(Raj Chaudhuri) #5

Each container can consume some disk space, called container storage. This can be used to persist state between different runs of the container. For example, a container that runs a shell might save history in container storage.

A started container is a process or group of processes. A stopped container is just metadata, and the aforementioned container storage - so no RAM or CPU cost.

It’s useful sometimes to start an existing container, with remembered state from the previous run, and all the extra settings and options applied at create time intact, rather than create new ones. This is especially true if the application in the container needs to go through a costly init process the first time it runs. In general, the recommendation is that we treat containers as if they are disposable. But having the option is good.