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
The -v / --volume flag uses the classic Binds field / API
The --mount flag uses the Mounts field / API
The --tmpfs flag uses the Tmpfs field / API
The --device flag uses the Devices field / API (but some other fields related to that).
TBD: --shm-size (sets size for /dev/shm)
What's the issue?
Effectively, all of these flags are (indirectly for some) related to adding "mounts" to the container, but passed through different options. On the daemon side, those options need to be "merged" in order to validate if there's conflicts.
For example; a --tmpfs and -v using the same target path in the container causes an error;
docker container create --name test \
-v myvolume:/tmpfs1 \
--tmpfs /tmpfs1 \
nginx:alpine
Error response from daemon: Duplicate mount point: /tmpfs1
Similarly, using -v and --mount wth the same target;
docker container create --name test \
-v myvolume:/vol \
--mount type=volume,src=myvolume,dst=/vol \
nginx:alpine
Error response from daemon: Duplicate mount point: /vol
Currently, setting those options, sets different fields in the HostConfig;
We should look at migrating all of those options to use the same (Mounts) API (where possible). Some of this must depend on the API version used, as older API versions may not have all features required.
The -v / --volume flag
Starting with moby/moby#43484 (related to moby/moby#43483), the Mounts field / API provides a CreateMountpoint option, which brings feature-parity between the Binds and Mounts API.
When using API v1.42 or up, convert -v (Binds) options to --mount (Mounts)
For bind-mounts, use the CreateMountpoint option
For API version v1.41 and below, continue using the Binds flag for bind-mounts
Consider using the Mounts API for (named/anonymous) volumes on API < v1.42
When using -v, convert relative paths to absolute paths (see Handle relative source mounts #3469) this should not be done with the --mount flag (at least not currently), which was designed to not convert paths.
The --tmpfs flag
⚠️ we need to verify if the Mounts option provides all options that can be passed in the --tmpfs microformat
rw
noexec
nosuid
size=65536k
The --device flag
For --device, more work will be needed. The Mounts API does not yet provide a type=device option (but we could consider adding).
Currently threre's (at least) 3 fields in HostConfig (indirectly) related to devices. From a quick glance, these options are "global" options (so not "per device"), but we can look at these mode in-depth and consider if making (some of) those options on --mount (or --device with an advanced syntax) would make sense;
This is a bit of a stretch, but effectively, --shm-size overrides the size for the /dev/shm mount in the container.
👍 we could consider making --shm-size an implicit --mount type=tmpfs,dst=/dev/shm,tmpfs-size=<size>
👎 this "sets in stone" that shm must be a mount at /dev/shm (probably ok), but also assumes that this option only is used for Linux (are there equivalents on other platforms?)
Description
Change CLI to use Mounts API as default API
Current situation:
-v/--volumeflag uses the classicBindsfield / API--mountflag uses theMountsfield / API--tmpfsflag uses theTmpfsfield / API--deviceflag uses theDevicesfield / API (but some other fields related to that).--shm-size(sets size for/dev/shm)What's the issue?
Effectively, all of these flags are (indirectly for some) related to adding "mounts" to the container, but passed through different options. On the daemon side, those options need to be "merged" in order to validate if there's conflicts.
For example; a
--tmpfsand-vusing the same target path in the container causes an error;docker container create --name test \ -v myvolume:/tmpfs1 \ --tmpfs /tmpfs1 \ nginx:alpine Error response from daemon: Duplicate mount point: /tmpfs1Similarly, using
-vand--mountwth the same target;docker container create --name test \ -v myvolume:/vol \ --mount type=volume,src=myvolume,dst=/vol \ nginx:alpine Error response from daemon: Duplicate mount point: /volCurrently, setting those options, sets different fields in the
HostConfig;But (at least
--volumeand--mount) end up in the same list ofMountsin the container config (top-level, not inHostConfig);Unify the API
We should look at migrating all of those options to use the same (
Mounts) API (where possible). Some of this must depend on the API version used, as older API versions may not have all features required.The
-v/--volumeflagStarting with moby/moby#43484 (related to moby/moby#43483), the
Mountsfield / API provides aCreateMountpointoption, which brings feature-parity between theBindsandMountsAPI.-v(Binds) options to--mount(Mounts)CreateMountpointoptionBindsflag for bind-mountsMountsAPI for (named/anonymous) volumes on API < v1.42-v, convert relative paths to absolute paths (see Handle relative source mounts #3469) this should not be done with the--mountflag (at least not currently), which was designed to not convert paths.The
--tmpfsflagMountsoption provides all options that can be passed in the--tmpfsmicroformatrwnoexecnosuidsize=65536kThe
--deviceflagFor
--device, more work will be needed. TheMountsAPI does not yet provide atype=deviceoption (but we could consider adding).Currently threre's (at least) 3 fields in
HostConfig(indirectly) related to devices. From a quick glance, these options are "global" options (so not "per device"), but we can look at these mode in-depth and consider if making (some of) those options on--mount(or--devicewith an advanced syntax) would make sense;The
--shm-sizeflagThis is a bit of a stretch, but effectively,
--shm-sizeoverrides the size for the/dev/shmmount in the container.--shm-sizean implicit--mount type=tmpfs,dst=/dev/shm,tmpfs-size=<size>/dev/shm(probably ok), but also assumes that this option only is used for Linux (are there equivalents on other platforms?)