Volumes

docker volume create test-data

docker run --name counter -d \
  --mount type=volume,source=test-data,destination=/var/log/test \
  busybox \
  sh -c 'i=0; while true; do echo "$i: $(date)" >> /var/log/test/1.log; i=$((i+1)); sleep 1; done'

docker exec counter cat /var/log/test/1.log

docker run --name fluentd -d \
  --mount type=volume,source=test-data,destination=/var/log/input \
  --mount type=bind,source=/etc/fluentd/fluent.conf,destination=/fluentd/etc/fluent.conf \
  --mount type=bind,source=/etc/fluentd/output,destination=/var/log/output \
  --env FLUENTD_ARGS="-c /fluentd/etc/fluent.conf" \
  k8s.gcr.io/fluentd-gcp:1.30

Bind mounts

Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes. When you use a bind mount, a file or directory on the host machine is mounted into a container.

The file or directory is referenced by its full or relative path on the host machine. By contrast, when you use a volume, a new directory is created within Docker’s storage directory on the host machine, and Docker manages that directory’s contents.

Use the following command to bind-mount the target/ directory into your container at /app/. Run the command from within the source directory. The $(pwd) sub-command expands to the current working directory on Linux or macOS hosts.

The --mount and -v examples below produce the same result. You can’t run them both unless you remove the devtest container after running the first one.

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

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

volumes

To mount a volume use -v or --volume.

These flags consist of three fields, separated by colon characters (:). The fields must be in the correct order, and the meaning of each field is not immediately obvious. - In the case of named volumes, the first field is the name of the volume, and is unique on a given host machine. For anonymous volumes, the first field is omitted. - The second field is the path where the file or directory are mounted in the container. - The third field is optional, and is a comma-separated list of options, such as ro. These options are discussed below.

If you start a container with a volume that does not yet exist, Docker creates the volume for you. The following example mounts the volume myvol2 into /app/ in the container.

$ docker run -d \
  --name devtest \
  -v myvol2:/app \
  nginx:latest

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:

Volumes are easier to back up or migrate than bind mounts.

Volumes are useful for backups, restores, and migrations. Use the --volumes-from flag to create a new container that mounts that volume.

To remove all unused local volumes use:

docker volume prune [OPTIONS]

Unused local volumes are those which are not referenced by any containers

Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.

To manage volume, you could use:

docker volume COMMAND COMMAND

You can use subcommands to create, inspect, list, remove, or prune volumes.

Create a volume

docker volume create

Display detailed information on one or more volumes

docker volume inspect

List volumes

docker volume ls

Remove all unused local volumes

docker volume prune

Remove one or more volumes

docker volume rm

tmpfs

As opposed to volumes and bind mounts, a tmpfs mount is temporary, and only persisted in the host memory. When the container stops, the tmpfs mount is removed, and files written there won’t be persisted.

This is useful to temporarily store sensitive files that you don’t want to persist in either the host or the container writable layer.

volumes-from

The docker run command provides a flag, --volumes-from, that will copy the mount definitions from one or more containers to the new container.

By combining this flag and volumes, you can build shared-state relationships in a host-independent way.

remove volumes

Anonymous volumes can be cleaned up in two ways. First, anonymous volumes are automatically deleted when the container they were created for are automatically cleaned up. This happens when containers are deleted via the docker run --rm or docker rm -v flags. Remove one or more containers

docker rm [OPTIONS] CONTAINER [CONTAINER...]

Second, they can be manually deleted by issuing a docker volume remove command:

docker volume rm [OPTIONS] VOLUME [VOLUME...]

Which option will bind an already-created DATA volume inside a container, under the /data directory?

a) -v DATA:/data
b) --mount type=volume,source=DATA,target=/data

data representation has no affect

Data within the container is exposed as either directory or individual files in container's FS. So, the type of storage mount (volume, bind or tmpfs) does not have any control on data's representation. To differentiate among the storage mounts: volume, bind mount, and tmpfs, user need to check the location where these mounts store container's data on host system.

Bind mount can grant read/write permissions on host file system to a process running inside a container.

tmpfs is ephemeral and bind mount is less secure compared to volume so if the data to be stored is sensitive such as passwords or credentials, volumes are the ideal

Docker CLI with bind mounts

You can’t use Docker CLI commands to directly manage bind mounts