[No Audio]
[Background Music]
[No Audio]
From a third person's point of view, this may seem
like a funny story, but it can potentially cost
you your job. That's the prime reason why we need
efficient storage solutions with containers.
The logic is pretty simple, containers data needs to
be backed up somewhere as a permanent storage.
And a quick question that will come up in your mind
would be, what or which data should be backed up?
To answer that, we need to look back at the
layered structure of Docker Image and container data.
If you remember, we have two types of
layers, read only layers which hold permanent data,
and is never modified due to Copy-on-Write policy,
and Read/Write layers which hold temporary
or volatile data. If a container stops or dies,
the volatile data vanishes. So now we have our
answer, we need to backup the important data from
the volatile Read/Write layer of the container.
Now the next question is where to store the data?
Well, just anywhere. Do you want to store it on
some machine, which hosts Docker? Go ahead.
Do you want to store it to another server? Go ahead.
Do you want to store it on Cloud? Go ahead as well.
And the last and genuine question which comes to
my mind, is are there any type of storage objects?
Yes, there are. Most commonly used storage object
type is called a Docker Volume. In a Volume,
a container storage is completely isolated from the
host file system. Although the data of Volume is
sorted in a specific directory of the host, they
are controlled and managed by Docker command line.
Compared to other options of storage, which we
will visit soon enough, Volumes are more secure to
ship and more reliable to operate.
Let's understand Volumes. Volumes are storage objects of
Docker, which are mounted to containers. In terms
of implementation, Volumes are dedicated
directories on hosts file system.
If a containerized app is shipped along with the
Volume, people apart from the developer himself,
using the app will end up creating such a
directory on their own Docker hosts.
Container provides data to Docker engine and user provides
commands to store the data in the Volume or to
manage the data in the same.
Although what container knows, is just the name of the Volume,
not the path on the host. The translation takes
place on Docker machines end, so external
applications having access to containers will have
no means to access Volumes directly.
This isolation maintains the integrity and security of
hosts and containers.
Second option is Bind Mounts.
The exchange of information is pretty similar,
apart from the fact that instead of
creating a directory inspired by the name of Volume,
Bind Mounts allow us to use any directory
on Docker host to store the data.
While this might be convenient in some cases, it also exposes the
storage location of the container, which can make
dents on the overall security of the application
or the host itself. Apart from that, the other
users apart from developer himself may not have
such path on the host in creating so may not be
under their privileges or comfort.
Finally, we have tmpfs, or temporary file system.
Volumes and Bind Mounts let you share the files between
host machine and container, so that you can persist
the data even after the container is stopped.
If you're running Docker on Linux, you have a third option, tmpfs mounts.
When you create a container with tmpfs mount, the container can
create files outside the containers writable layer.
As opposed to Volumes and Bind Mounts, a tmpfs mount
is temporary and only persist in the host
memory not in storage.
When the container stops, the tmpfs mount is removed
and the file sitting there won't be persisted.
The only sensible use case
which comes to my mind for tmpfs, is to store
sensitive files, which you don't want to persist
once the application gets deleted, something like
the browsing history, which get deleted if we use the incognito tab.
tmpfs mounts have their limitations,
they can be created, not shipped,
and they won't work on non Linux environments
like Docker on Windows.