A container's lifecycle is pretty much similar to a
process's lifecycle in Linux. Because after all,
a container is just a running process instance of a Docker Image.
We start with the Created stage,
which can be a part of docker run command, or can
be explicitly caused by docker create command.
If it is a part of run command, it will automatically
lead to the next stage, which is Running stage.
It means that the created container or the sheduled
process is running and resources are being
actively used by it. Alternatively, if a container
is explicitly in Created stage, it can be sent to
running state with Start command. Next is Paused stage
which won't occur on its own for the most part,
you can strategically cause it with Docker
container Pause command and resume it similarly
with Unpause command. The container process will
go to Pending stage and once resumed, it will be
back to being up and running. Next is Stopped stage,
which means the process of the container is
terminated, but the container id still exists.
So it can be rescheduled without creating another
container and registering its id.
This can be due to multiple reason, it can be caused by an error,
restart policy, or simply container having
finished its run to completion task.
We can manually stop and restart containers with docker
container stop and restart commands respectively.
Finally, we have Deleted stage where the
terminated container is removed and its id is freed up,
it will stop appearing in the list of containers.
To expand further on multiple
containers from single image, consider this diagram.
The read only layer is common and the
read/write layers are fetching data from it.
This does not cause any data corruption since the data
of Read only layer is not going to be modified in
the first place. And the system just has to
perform multiple read operation on the same data.
This optimizes storage of Docker host whereas the
number of running containers from the same or
different image on a single host will always
depend on host architecture limitations like
memory and processing speed.
Another important aspect of containers is their Copy-on-Write mechanism.
What's that? Well, it's pretty simple.
Till now we have seen that writable layer of
container is mounted to the readwrite layer of Docker Image.
Well that was true, but it has a
little secret to it. The Read only layers file
themselves are untouched. A copy of them is
created and read/write layer is mounted on that
copy, which makes it easier to recover the layers,
in case any unauthorized host file system access or content damage