What is Docker storage? Learn Everything about Docker storage (Theory)

In order to understand the whole docker storage concept and its types, we have a tree describing all the components for the same. Below is a picture, in which each and every component is mentioned as per the current version, which is 18.09.4, further we are going to understand each and every component of this tree.

To learn more about docker, follow -> Learn Docker

Question: Why do we even need special storage types for the docker containers?

Answer: By default, if any data is created inside a particular container, it is going to be stored in the R/W layer of the container. As a result, we have the following drawback:

• If any precious data is generated inside a container, then as long as the container is not deleted, data is there. But if the container is deleted then all the data it is holding is going to be deleted.

Before going further, let us understand about each type of storage with the help of a diagram, which is shown below:

Docker Storage Types

There are two types of docker storage:

1. Ephemeral / Non-Persistent
2. Persistent

We will be discussing them one by one, Let us start now.

Ephemeral / Non-Persistent

Note: People on the internet often use the terms interchangeably.

It is again of two types:

1. tmpfs
2. Anonymous

tmpfs

This type is called “tmpfs” stated to “temporary file system“, any data created by the container if it is stored using the “tmpfs mounts” that means the data is currently stored in the “RAM” of the host system on which the “docker engine” is installed.

Anonymous

This is the default behaviour of container storage, which means that any data created in the container is stored in the R/W layer, then that data by no means can be seen in the host system, unless and until we login into the container and then access that data. That is why this type of storage is called Anonymous.

To learn more about non-persistent storage, follow -> Docker Non-Persistent Storage

Persistent

It is again of two types:

1. Bind Mounts
2. Volumes

Bind Mounts

• The data can be stored anywhere on the host file system.
• Non-docker processes running on the “docker engine host” can modify them.
• They have limited functionality compared to “docker volumes”.
• File or directory mapped can be created on demand, if it does not already present on the host’s file system.
• In this, a file or directory from the host’s file system is mounted into the container.
• It is not necessary that a file or directory has to be already present on the host’s file system.

Question: Why in the first place do we require “bind mounts“?

Answer: For sharing configuration files from the host machine to the container.

Question: How docker provides the DNS resolution to the containers by default?

Answer: By creating a bind mount of “/etc/resolv.conf” from the host machine to the container.

To learn more about docker bind mount, follow -> How bind mount works in docker

Volumes

• These are managed by docker in the special and non-compromised area on the “docker engine host” itself.
• A non-docker process should not or unable to modify this part of the file system, unless and until it has root permissions (Linux only).
• Currently, it is the best way to persist data from docker containers.

Following is the flowchart of how volumes manage data in a docker system:

• Multiple containers can mount the same volume simultaneously.
• Helpful, when we want to store “container’s data” on a “remote host” or a “cloud provider” using appropriate “storage drivers“.
• These can be safely shared among the containers to shared sensitive information.
• Whenever we want to “backup“, “restore” or “migrate“, using volume is the best option.
• New volumes can have their content pre-populated by a container.