“The Basics of Container Data Management” Getting Started with Docker Volumes

Docker containers are built to be immutable. That is, the code and data inside the container do not change. Immutability is useful when you want to ensure that the code running in production is the same code that passed QA testing, but it is less useful when you are writing data and need to persist it for the life of the application.

In most cases, the need for data persistence can be addressed by using an external database. However, there are times when an application in a container needs to use a local file system, or something that looks like a local file system.

The feature used here is Docker’s native mechanism for handling local storage. Docker volumesam. Docker volumes are a convenient way to allow containerized apps to write and retrieve files through a local file system or a file system-like interface. However, Docker volumes are not a panacea for state management, so they must be used judiciously.

How docker volumes work

Docker volumes provide a way to map file paths (mount points) inside a container to file system paths or file-like objects outside the container. Anything written to a Docker volume is stored externally and therefore persists for the lifetime of one or more containers. Multiple containers can also access the same volume simultaneously (if some conditions are met).

Docker volume is volume driverUse to control where data is stored. for example BlockbridgeProvides direct access to iSCSI targets through the volume driver layer. A bolder example is one that works across a variety of storage vendors and standards. REX-Ray It is a storage engine. Rex-Ray is Docker’s volume plugin system, or the more general Container Storage Interface SpecificationProvides connection through.

Creating Docker volumes manually

The most basic way to create a volume is to include the -v or —volume flag, mount point, and target when starting the container, like this:

$ docker run -P —name websvc -v /websvcdata myorg/websvc python app.py

This creates an “anonymous” volume with the mount point websvcdata and stores the data in a randomly created directory used by the Docker process.

The same result can be achieved by including a VOLUME command in the Dockerfile that describes the location of the volume.

FROM ubuntu: latest VOLUME /websvcdata

This is a good way to create a convenient processing station for handling data during a given container session, but it is not useful for maintaining state across container sessions because the names of the volumes are not known in advance and the volumes cannot be reused efficiently.

Using Docker Volume API

A better solution to this problem is to use Docker’s volume API to create a named volume. Named volumes can be easily attached to one or more containers and are therefore much easier to reuse.

$ docker volume create websvcdata

This command creates a Docker volume with the name websvcdata. However, since the container does not yet have a mount point, the container cannot access the volume by default. To create a mount point, you need to run the container using the following command:

$ docker run -P —name websvc -v websvcdata:/websvcdata myorg/websvc python app.py

This command is the same as the previous docker run example, but instead of creating the volume anonymously, it is created on the host with the name websvcdata. You can verify that the mounts were as intended by running docker inspect on the container and reading the “Mounts” section in the resulting dump.

Because a name for a Docker volume must be specified at runtime, you cannot create a named volume with a Dockerfile. This is intentional designall. This is because Dockerfile cannot assume the existence of a given host and its volume path. That is, it is designed to run on any system, on any set of volume paths. The volume specified in the Dockerfile is created in a location that supports persistence of the data it stores during the life of the container.

Flags for Docker storage driverWhen you run docker volume create, you can specify several options for volume creation. For example, a local file system driver can describe where the volume will be placed, what device or file system to use (for example, an NFS share or a temporary file system), and many other control factors that determine which device is best suited for a particular use case. Volumes can be placed in .

useful tips : When you create a volume and bind this volume to a path in the base image that already contains data, the data in the base image is copied to the volume at the time of binding. This is the data set you want to use as a starting point. Convenient for pre-filling the volumedo. (Note that it is your responsibility to clean up filled volumes.)

Share Docker volume across multiple containers

To attach two or more containers to the same Docker volume, simply create a volume and attach it to multiple containers as follows:

This creates three containers from instance1 to instance3, and DataVoll is connected to each container. In the instance3 container, DataVol1 is mounted as read-only according to :ro after the volume name.

It is important to note that Docker does not automatically mediate conflicts between containers sharing the same volume. This is something you need to do in your application. (More detailed below)

Remove Docker volume

When a container is removed, volumes are not automatically removed from disk. This is by intentional design. This is because there is a possibility that it will be used in the future by other containers that have not been used yet. This means that unmounting volumes and cleaning up disks is your responsibility.

Docker provides basic tools to facilitate volume cleanup. The docker volume command has a subcommand called docker volume prune, which removes all volumes that are not in use by one or more containers on the system. You can also modify the deletion range. For example, you can remove all volumes attached to a specific container by passing a command line flag.

Limitations of Docker volumes

Docker volumes are not a panacea for local persistence. Because of the way containers interact with local file systems, Docker volumes can cause more problems than they solve.

One important limitation is that Docker does not handle file locking on volumes that are used by multiple containers. Therefore, this part must be handled by the application you are using. If the application in question is not sure how to write to the shared file system, it can result in file corruption on the volume. One possible solution is to use a local filesystem instead, for example Minio It uses the same object storage server as the project.

Another problem with Docker volumes is that they can make application portability more difficult. Storage topology varies from system to system. If you create a volume based on assumptions about the specific location of this or that element in the system, you may find yourself in a situation where these assumptions are not true when you try to deploy the same container on a system that you did not build yourself. This may not be a problem if you only use containers in systems where you have strict topology control (for example, an internal private cluster), but it can become a headache later in a redesign.

Finally, you should not use volumes to store stateful data that is better handled through Docker’s other native mechanisms. For example, the application secret is Docker’s own secret system or Hashkov’s VaultIt must be processed by a third-party product such as , and not via a volume or writable container image layer.
editor@itworld.co.kr