Difference between Running and Starting a Docker container
DockerDocker Problem Overview
In practice to start a container I do:
docker run a8asd8f9asdf0
If thats the case, what does:
docker start
do?
In the manual it says
> Start one or more stopped containers
Docker Solutions
Solution 1 - Docker
This is a very important question and the answer is very simple, but fundamental:
- Run: create a new container of an image, and execute the container. You can create N clones of the same image. The command is:
docker run IMAGE_ID
and notdocker run CONTAINER_ID
- Start: Launch a container previously stopped. For example, if you had stopped a database with the command
docker stop CONTAINER_ID
, you can relaunch the same container with the commanddocker start CONTAINER_ID
, and the data and settings will be the same.
Solution 2 - Docker
run
runs an imagestart
starts a container.
The docker run
doc does mention:
> The docker run
command first creates a writeable container layer over the specified image, and then starts it using the specified command.
>
> That is, docker run is equivalent to the API /containers/create
then /containers/(id)/start
.
You do not run an existing container, you docker exec to it (since docker 1.3).
You can restart an exited container.
Solution 3 - Docker
Explanation with an example:
Consider you have a game (iso) image in your computer.
When you run
(mount your image as a virtual drive), a virtual drive is created with all the game contents in the virtual drive and the game installation file is automatically launched. [Running your docker image - creating a container and then starting it.]
But when you stop
(similar to docker stop) it, the virtual drive still exists but stopping all the processes. [As the container exists till it is not deleted]
And when you do start
(similar to docker start), from the virtual drive the games files start its execution. [starting the existing container]
In this example - The game image is your Docker image and virtual drive is your container.
Solution 4 - Docker
run
command creates a container from the image and then starts the root process on this container. Running it with run --rm
flag would save you the trouble of removing the useless dead container afterward and would allow you to ignore the existence of docker start
and docker remove
altogether.
[![enter image description here][1]][1]
run
command does a few different things:
docker run --name dname image_name bash -c "whoami"
- Creates a Container from the image. At this point container would have an id, might have a name if one is given, will show up in
docker ps
- Starts/executes the root process of the container. In the code above that would execute
bash -c "whoami"
. If one runsdocker run --name dname image_name
without a command to execute container would go into stopped state immediately. - Once the root process is finished, the container is stopped. At this point, it is pretty much useless. One can not execute anything anymore or resurrect the container. There are basically 2 ways out of stopped state: remove the container or create a checkpoint (i.e. an image) out of stopped container to run something else. One has to run
docker remove
before launching container under the same name.
How to remove container once it is stopped automatically? Add an --rm
flag to run
command:
docker run --rm --name dname image_name bash -c "whoami"
How to execute multiple commands in a single container? By preventing that root process from dying. This can be done by running some useless command at start with --detached
flag and then using "execute" to run actual commands:
docker run --rm -d --name dname image_name tail -f /dev/null
docker exec dname bash -c "whoami"
docker exec dname bash -c "echo 'Nnice'"
Why do we need docker stop
then? To stop this lingering container that we launched in the previous snippet with the endless command tail -f /dev/null
.
[1]: https://i.stack.imgur.com/mxSq2.png
Solution 5 - Docker
daniele3004's answer is already pretty good.
Just a quick and dirty formula for people like me who mixes up run
and start
from time to time:
docker run [...]
= docker pull [...]
+ docker start [...]