Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to manage Docker data, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Manage Docker data

Data can be stored in the writable layer of the container, but it has the following disadvantages:

When the container is no longer running, the data will not persist and it will be difficult to extract the data from the container.

The container writable layer is tightly coupled to the host on which the container is running. Data can not be migrated well between different hosts.

The data is written in the writable layer of the container, and a storage driver is required to manage the file system. The read-write layer of the data writing container requires the kernel to provide a federated file system, which is expensive compared to writing data directly to the host file system using data volumes.

Docker provides three different ways to manage container data on hosts: volumes, bind mounts, and tmpfs volumes.

Select the appropriate mount type

No matter which mount type you choose, the data you see in the container is the same. That is, it exists as a directory or a separate file in the container file system.

A relatively simple way to distinguish between volumes, bind mounts, and tmpfs mounts is by distinguishing where the data is stored in the Docker host.

Volumes: stores the / var/lib/docker/volumes directory under the host file system. Non-Docker processes cannot modify this part of the file system. Volumes is the best way to manage Docker persistent data.

Bind mounts: stored anywhere in the host, it can be an important system file or directory. Non-Docker processes and Docker containers can modify this data at any time.

Tmpfs mounts: only exists in the memory of the host system and is not written to the host's file system.

More details about Mount types

Volumes: created and managed by Docker. You can explicitly create a volume,Docker through the docker volume create command, or you can create your own volume when creating a container or service.

When you create a volume, it is stored in a directory of the host. When you mount the volume to a container, this directory is what is mounted to the container. This is similar to bind mounts, except that volumes is created by Docker and is isolated from the core functionality of the host.

A volume can be mounted into several containers at the same time. This volume,volume still exists even if no running container is used and will not be automatically cleared. Volumes that is no longer in use can be cleared through docker volume prune.

Volumes also supports volume driver, which allows data to be stored on another machine or cloud.

Bind mounts:Docker supported this feature early on. Compared with volumes, Bind mounts supports limited functionality. When using bind mounts, a file or directory on the host is mounted to the container.

Warning: one side effect of using Bind mounts is that programs running in the container can modify the host's file system, including creating, modifying, and deleting important system files or directories. There may be security issues with this feature.

Tmpfs mounts:tmpfs mounts's data will not be closed. During the lifetime of the container, it can be used to store some state or sensitive data that does not need to be persisted. For example, a swarm service mounts secrets into a container of a service through tmpfs mounts.

Scenarios suitable for Volumes

Volume should be the preferred way to persist data, and its recommended use cases are:

Share data in different containers. Sharing data between multiple containers, volume still exists when the container is stopped or deleted, and needs to be displayed if deleted (dockr rm-v … Multiple containers can load the same volume Volumes are only removed when you explicitly remove them.

When the host cannot guarantee a specified directory or file structure. Volume helps decouple container runtime and Docker host configurations.

When it is necessary to transfer container data When you want to store your container's data on a remote host or a cloud provider, rather than locally.

When you need to back up, restore, or migrate data. Stop the container, the directory of the backup volume (for example, / var/lib/docker/volumes/.

Scenarios suitable for bind mounts

Through bind mount, you can mount any file or directory (absolute path) on your host to the container.

The mounted file or directory can be modified by any process, so sometimes modifying the file or directory in the container will affect other processes.

If the file or directory on which the host is mounted does not exist, it will be created automatically.

This method cannot be managed by docker volume, so it is recommended to use volume method.

Hosts and containers share configuration files. This is the case with the DNS solution provided by Docker, which mounts the / etc/resolv.conf of the host into each container.

The development environment needs to share code in hosts and containers. This is the case with docker-based development. After all, there is generally no editor in the container.

The file and directory structure on the Docker host needs to be consistent with the bind mount directory in the container.

If an empty file or directory is mounted to a container and there are files in that directory in the container, these files will be copied to the directory on the host. If a non-empty file or directory is mounted to a container and there are files in that directory in the container, the files in the container will be hidden.

Volume VS. Bind mount

Volume is recommended as the preferred method in docker. Compared with bind mount, it has the following advantages:

Volume is easier to back up or migrate than bind mount.

You can use the Docker CLI command or Docker API to manage.

Volume works on both Linux and Windows containers.

Volume can be shared more securely among multiple containers.

The volume driver allows you to provide storage, encryption, or other functions on a remote host or cloud.

The contents of the new volume can be pre-populated by the container.

Configure Propagation

Propagation defaults to rprivate in bind mount and volume. It can only be configured on bind mount and can only be configured on Linux hosts. This is an advanced option and many users do not need to configure it.

Propagation refers to whether a mount created in a given mount volume or named volume can be propagated to a copy of that mount. Consider a mount point / mnt, which is mounted at / tmp. The propagation setting controls whether / tmp/an is mounted or / mnt/an is also available. Each Propagation setting has a recursive corresponding point. In the case of recursion, consider that / tmp/an is mounted as / foo. Propagation settings control whether / mnt/an or / tmp/a will exist.

The Propagation setting describes that the child mount of the original mount of the shared is exposed to the replica mount, and the child mount of the replica mount is propagated to the original mount. Slave is similar to a shared mount, but only in one direction. If the original mount displays a child mount, the replica mount can see it. However, if the copy mount exposes a child mount, the original mount cannot see it. Private, this mount is private. The child mount is not exposed to the replica mount, and the child mount of the sub-mount is not exposed to the original mount. Rshared is the same as sharing, but propagation also extends to mount points nested within any original or replica mount point. Rslave is the same as slave devices, but propagation also extends to mount points nested within any original or replica mount point. Rprivate defaults. Same as private, this means that no mount point propagates in either direction anywhere within the original or copy mount point.

Before binding propagation can be set at the mount point, the host file system needs to already support binding propagation. For more information about binding propagation, see the Linux kernel documentation for a shared subtree.

The following example loads the target/ directory into a container twice, with the second load setting the ro option and the rslave binding propagation option.

The same results are obtained in the-- mount and-v instances.

$docker run-d\-it\-- name devtest\-- mount type=bind,source= "$(pwd)" / target,target=/app\-- mount type=bind,source= "$(pwd)" / target,target=/app2,readonly,bind-propagation=rslave\ nginx:latest$ docker run-d\-it\-name devtest\-v "$(pwd)" / target:/app\-v "$(pwd)" / target:/app2:ro,rslave\ nginx:latest

Now if you create / app/foo/,/app2/foo/ will also exist.

Configure selinux tags

If you use selinux, you can add z or Z options to modify the selinux tag of the host file or directory that is being loaded into the container. This can affect the host's own files or directories and may lead to consequences outside the scope of Docker.

This z option indicates that the binding installation content is shared among multiple containers.

The Z option indicates that the binding installation is private and non-shared.

Use these options with extreme caution. Binding a system directory, such as / home or / usr with this Z option, will prevent your host from working, and you may need to re-mark the host file manually.

Important: when installing the service using bindings, the selinux tags (: Z and: Z) and: ro are ignored. For more information, see moby/moby#32579.

This example sets the z option to specify that multiple containers can share bound-mounted content:

It is not possible to use the-- mount flag to modify the selinux tag.

$docker run-d\-it\-- name devtest\-v "$(pwd)" / target:/app:z\ nginx:latest configuration macOS installation consistency

Docker for Mac is used for osxfs to propagate directories and files shared from macOS to Linux VM. This propagation makes these directories and files available to Docker containers running on Docker for Mac.

By default, these shares are identical, which means that every time a write occurs on a macOS host or is mounted through a container, changes are flushed to disk so that all participants in the share have exactly the same view. In some cases, full consistency can seriously affect performance. Docker 17.05 and later introduced options to adjust the consistency settings for each container. The following options are available:

Consistent or default: identical default settings, as described above.

Delegated: the mount view of the container runtime is authoritative. Updates made in the container may be delayed before they are visible on the host.

The mount view of the cached:macOS host is authoritative. Updates made on the host may be delayed before they are visible in the container. These options are completely ignored on all host operating systems except macOS.

The same results are obtained in the-mount and-v instances.

$docker run-d\-it\-- name devtest\-- mount type=bind,source= "$(pwd)" / target,destination=/app,consistency=cached\ nginx:latest$ docker run-d\-it\-- name devtest\-v "$(pwd)" / target:/app:cached\ nginx:latest is suitable for tmpfs mounts scenarios

Tmpfs mounts is mainly used when you do not want to be in the container, nor do you want to save data in the host file system. This may be for security reasons, or it may be that your application needs to write a lot of non-persistent data, and tmpfs mounts can guarantee container performance at this time.

Related use cases

Tmpfs, which is generally used when security is more important and there is no need to persist data.

Mode of use

There is no need to say much about the relationship between tmpfs and-mount and the first two ways. Then the difference between them is:

-- tmpfs does not allow you to specify any configurable options. -- tmpfs cannot be used for swarm service, you must use-- mount. Limitations of tmpfs containers

Tmpfs mounts cannot be shared between containers. Tmpfs can only work on Linux containers, not windows containers.

Use tmpfs$ docker run-d\-it\-- name tmptest\-- mount type=tmpfs,destination=/app\ nginx:latest$ docker run-d\-it\-- name tmptest\-- tmpfs / app\ nginx:latest in the container

Tmpfs verifies that the installation is mounted by running docker container inspect tmptest and looking for the Mounts section:

"Tmpfs": {"/ app": ""}

Delete the container:

$docker container stop tmptest$ Docker container rm tmptest specifies the tmpfs option

Tmpfs mounts allow two configuration options, neither of which is required. If you need to specify these options, you must use the-- mount flag because the-- tmpfs flag does not support them.

Option describes the size of the tmpfs-sizetmpfs, in bytes. Unlimited default. Octal file mode for tmpfs-modetmpfs. For example, 700 or 0770. The default is 1777 or globally writable.

The following example sets tmpfs-mode to 1770 so that it is not globally readable within the container.

Docker run-d\-it\-- name tmptest\-- mount type=tmpfs,destination=/app,tmpfs-mode=1770\ nginx:latest Thank you for reading this article carefully. I hope the article "how to manage Docker data" shared by the editor will be helpful to you. At the same time, I hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.