You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default all files created inside a container are stored on a writable
12
-
container layer. This means that:
12
+
container layer that sits on top of the read-only, immutable image layers.
13
13
14
-
- The data doesn't persist when that container no longer exists, and it can be
15
-
difficult to get the data out of the container if another process needs it.
16
-
- A container's writable layer is tightly coupled to the host machine
17
-
where the container is running. You can't easily move the data somewhere else.
18
-
- Writing into a container's writable layer requires a
19
-
[storage driver](/engine/storage/drivers/) to manage the
20
-
filesystem. The storage driver provides a union filesystem, using the Linux
21
-
kernel. This extra abstraction reduces performance as compared to using
22
-
_data volumes_, which write directly to the host filesystem.
14
+
Data written to the container layer doesn't persist when the container is
15
+
destroyed. This means that it can be difficult to get the data out of the
16
+
container if another process needs it.
23
17
24
-
Docker has two options for containers to store files on the host machine, so
25
-
that the files are persisted even after the container stops: volumes, and
26
-
bind mounts.
18
+
The writable layer is unique per container. You can't easily extract the data
19
+
from the writeable layer to the host, or to another container.
27
20
28
-
Docker also supports containers storing files in-memory on the host machine. Such files are not persisted.
29
-
If you're running Docker on Linux, `tmpfs` mount is used to store files in the host's system memory.
30
-
If you're running Docker on Windows, named pipe is used to store files in the host's system memory.
21
+
## Storage mount options
31
22
32
-
## Choose the right type of mount
23
+
Docker supports the following types of storage mounts for storing data outside
24
+
of the writable layer of the container:
25
+
26
+
-[Volume mounts](#volume-mounts)
27
+
-[Bind mounts](#bind-mounts)
28
+
-[tmpfs mounts](#tmpfs-mounts)
29
+
-[Named pipes](#named-pipes)
33
30
34
31
No matter which type of mount you choose to use, the data looks the same from
35
32
within the container. It is exposed as either a directory or an individual file
36
33
in the container's filesystem.
37
34
38
-
An easy way to visualize the difference among volumes, bind mounts, and `tmpfs`
39
-
mounts is to think about where the data lives on the Docker host.
40
-
41
-
42
-
43
-
- Volumes are stored in a part of the host filesystem which is _managed by
44
-
Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not
45
-
modify this part of the filesystem. Volumes are the best way to persist data
46
-
in Docker.
47
-
48
-
- Bind mounts may be stored anywhere on the host system. They may even be
49
-
important system files or directories. Non-Docker processes on the Docker host
50
-
or a Docker container can modify them at any time.
51
-
52
-
-`tmpfs` mounts are stored in the host system's memory only, and are never
53
-
written to the host system's filesystem.
54
-
55
-
Bind mounts and volumes can both be mounted into containers using the `-v` or
56
-
`--volume` flag, but the syntax for each is slightly different. For `tmpfs`
57
-
mounts, you can use the `--tmpfs` flag. We recommend using the `--mount` flag
58
-
for both containers and services, for bind mounts, volumes, or `tmpfs` mounts,
59
-
as the syntax is more clear.
60
-
61
-
### Volumes
62
-
63
-
Volumes are created and managed by Docker. You can create a volume explicitly
64
-
using the `docker volume create` command, or Docker can create a volume during
65
-
container or service creation.
66
-
67
-
When you create a volume, it's stored within a directory on the Docker
68
-
host. When you mount the volume into a container, this directory is what's
69
-
mounted into the container. This is similar to the way that bind mounts work,
70
-
except that volumes are managed by Docker and are isolated from the core
71
-
functionality of the host machine.
72
-
73
-
A given volume can be mounted into multiple containers simultaneously. When no
74
-
running container is using a volume, the volume is still available to Docker
75
-
and isn't removed automatically. You can remove unused volumes using `docker
76
-
volume prune`.
77
-
78
-
When you mount a volume, it may be named or anonymous. Anonymous volumes are
79
-
given a random name that's guaranteed to be unique within a given Docker host.
80
-
Just like named volumes, anonymous volumes persist even if you remove the
81
-
container that uses them, except if you use the `--rm` flag when creating the
82
-
container, in which case the anonymous volume is destroyed.
83
-
See [Remove anonymous volumes](volumes.md#remove-anonymous-volumes).
84
-
If you create multiple containers after each other that use anonymous volumes,
85
-
each container creates its own volume.
86
-
Anonymous volumes aren't reused or shared between containers automatically.
87
-
To share an anonymous volume between two or more containers,
88
-
you must mount the anonymous volume using the random volume ID.
89
-
90
-
Volumes also support the use of volume drivers, which allow you to store
91
-
your data on remote hosts or cloud providers, among other possibilities.
92
-
93
-
### Bind mounts
94
-
95
-
Bind mounts have limited functionality compared to volumes. When you use a bind
96
-
mount, a file or directory on the host machine is mounted into a container. The
97
-
file or directory is referenced by its full path on the host machine. The file
98
-
or directory doesn't need to exist on the Docker host already. It is created on
99
-
demand if it doesn't yet exist. Bind mounts are fast, but they rely on the host
100
-
machine's filesystem having a specific directory structure available. If you
101
-
are developing new Docker applications, consider using named volumes instead.
102
-
You can't use Docker CLI commands to directly manage bind mounts.
103
-
104
-
> [!IMPORTANT]
105
-
>
106
-
> Bind mounts allow write access to files on the host by default.
107
-
>
108
-
> One side effect of using bind mounts is that you can change the host
109
-
> filesystem via processes running in a container, including creating,
110
-
> modifying, or deleting important system files or directories. This is a
111
-
> powerful ability which can have security implications, including impacting
112
-
> non-Docker processes on the host system.
113
-
114
-
> [!TIP]
115
-
>
116
-
> Working with large repositories or monorepos, or with virtual file systems that are no longer scaling with your codebase?
117
-
> Check out [Synchronized file shares](/manuals/desktop/features/synchronized-file-sharing.md). It provides fast and flexible host-to-VM file sharing by enhancing bind mount performance through the use of synchronized filesystem caches.
118
-
119
-
### tmpfs
120
-
121
-
A `tmpfs` mount isn't persisted on disk, either on the Docker host or within a
122
-
container. It can be used by a container during the lifetime of the container,
123
-
to store non-persistent state or sensitive information. For instance,
124
-
internally, Swarm services use `tmpfs` mounts to mount
125
-
[secrets](/manuals/engine/swarm/secrets.md) into a service's containers.
0 commit comments