docker-documentation/general/volumes.md

27 wiersze
2.2 KiB
Markdown
Czysty Zwykły widok Historia

2019-01-24 20:22:31 +00:00
# Volumes
2019-01-27 11:24:19 +00:00
In Docker terminology, a _volume_ is a storage device that allows you to persist the data used and generated by each of your running containers. While a container remains alive \(in either an active or inactive state\), the data inside its user-space remains intact. However, if you decide to recreate a container, all data within that container is lost. Volumes are an intrinsic aspect of container management, so it is useful to know how to create them.
2019-01-24 20:22:31 +00:00
There are two ways to map persistent storage to your containers; container volumes, and directory overlays. All of our images reference persistent data by means of directory overlays.
## Mapping a volume to your container
2019-09-29 09:44:22 +00:00
Firstly, you must understand which directories from _within_ your container you wish to persist. All of our images come with side-by-side documentation on which internal directories are used by the application. As mentioned in the [Running our Containers](running-our-containers.md) documentation, the most common directory you will wish to persist is the `/config` directory.
2019-01-24 20:22:31 +00:00
Before you create your container, first create a directory on the host machine that will act as the home for your persisted data. We recommend creating the directory `/opt/appdata`. Under this tree, you can create a single configuration directory for each of your containers.
When creating the container itself, now is the time to make use of the `-v` flag, which will tell Docker to overlay your host directory over the container's directory:
2019-01-27 11:24:19 +00:00
```text
2019-01-24 20:22:31 +00:00
docker create --name my_container \
-v /opt/appdata/my_config:/config \
linuxserver/<an_image>
```
The above example shows how the usage of `-v` has mapped the host machine's `/opt/appdata/my_config` directory over the container's internal `/config` directory.
> **Remember**: When dealing with mapping overlays, it always reads `host:container`
You can do this for as many directories as required by either you or the container itself. Our rule-of-thumb is to _always_ map the `/config` directory as this contains pertinent runtime configuration for the underlying application. For applications that require further data, such as media, our documentation will clearly indicate which internal directories need mapping.
2019-01-27 11:24:19 +00:00