How to use -v flag in Docker
On the difference between volumes and bind months in Docker
3 min readAug 25, 2022
The aim of this page📝is to analyze the -v flag for docker run command and realize that it can work as
- mounting volumes
- mounting bind mouths
...And that these are different things.
- Ignoring immutable storage types at this point, we may need either NON-PERSISTENT or PERSISTENT storage in a docker container
NON-PERSISTENT | PERSISTENT&CHANGEABLE
---------------------------|-------------------------------------
**bind mouths** | **volumes**
automatic | own `docker volume` cmd
done. no sticking, no data | outside of container's lifetime
ideal for containers |
every container has it | manually created
local block storage | volume storage3. VOLUME
- volumes come into play for a scenario when you have data that you
- need to change
- need to persist
- volumes are
- decoupled from containers
- way to store data
- volume is a directory on a docker host (local machine/SAN/NAS)
- mounted straight into the container at a specific mount point
4. VOLUME CREATION
-vor--volume- Consists 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.
FIELD_1 | FIELD_2 | FIELD_3
------------|----------------|--------------
volume name | container path | optional flag- 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 is mounted in the container.
5. EXAMPLE COMMAND
docker run --rm -it `
-v tfm:/root/terraform-modules `
-v gcp:/root/.gcp `
-e AWS_ACCESS_KEY_ID='PLACE_HOLDER' `
-e AWS_SECRET_ACCESS_KEY='PLACE_HOLDER' `
-e GOOGLE_APPLICATION_CREDENTIALS='/root/.gcp/PLACE_HOLDER' `
-e CONSUL_HTTP_ADDR='https://consul.foo.net' `
-e CONSUL_HTTP_TOKEN='PLACE_HOLDER' `
foo-bar-box6. CREATE AND INSPECT VOLUME
- create docker volume from the host folder
>>> docker volume create tfm
>>> docker volume inspect tfm
[
{
"CreatedAt": "2021-12-04T05:43:35Z",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/tfm/_data",
"Name": "tfm",
"Options": {},
"Scope": "local"
}
]Mountpointis where docker folders are on a host- mount volume within the container
--mount source=tfm,target=/tfm- well why do you need that data — how was he accessing it
7. BIND MOUNT != VOLUMES
- Also created in with
docker wunwith-vor--volumeflag - 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 absolute 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
- with volumes, Docker manages that directory’s contents.
- the file or directory does not need to exist on the Docker host already
- it is created on demand if it does not yet exist.
- Bind mounts are very performant, but they rely on the host machine’s filesystem having a specific directory structure available.
- If you are developing new Docker applications, consider using named volumes instead.
- You can’t use Docker CLI commands to directly manage bind mounts.
- bind mouths are for
- mapping paths in a file system to the container
- so volumes are for
- new apps and persistent storage (I’m on Windows)
docker run --rm -it `
-v $($pwd.path -replace '\\','/'):/root/foo `
-e AWS_ACCESS_KEY_ID='PLACE_HOLDER' `
-e AWS_SECRET_ACCESS_KEY='PLACE_HOLDER' `
-e GOOGLE_APPLICATION_CREDENTIALS='/root/.gcp/PLACE_HOLDER' `
-e CONSUL_HTTP_ADDR='https://consul.foo.net' `
-e CONSUL_HTTP_TOKEN='PLACE_HOLDER' `
foo-bar-box
