Add new HostConfig field, Mounts.#22373
Conversation
b8223b6 to
ba06fec
Compare
|
Have some cleanup on windows and probably some reconciliation on validations between the string spec ( |
HostConfig field, Mounts.HostConfig field, Mounts.
There was a problem hiding this comment.
Target, only because it is shorter.
There was a problem hiding this comment.
The reason I used "Destination" is because we already use this term in container.MountPoints
|
@cpuguy83 Overall, design LGTM. I have a few naming concerns, but those are easy to work out. I would like to see a mapping for the current "volume syntax" to these types, as part of this effort. It should be straightforward to work out. |
ba06fec to
44e31b8
Compare
HostConfig field, Mounts.HostConfig field, Mounts.
|
Ok, this is updated, more tests, reconciled some of the validation/parsing between the string spec parser and the new config type... though I did not address @stevvooe's concerns yet |
4851f95 to
fc1538a
Compare
0b8f1b5 to
241412f
Compare
`Mounts` allows users to specify in a much safer way the volumes they
want to use in the container.
This replaces `Binds` and `Volumes`, which both still exist, but
`Mounts` and `Binds`/`Volumes` are exclussive.
The CLI will continue to use `Binds` and `Volumes` due to concerns with
parsing the volume specs on the client side and cross-platform support
(for now).
The new API follows exactly the services mount API.
Example usage of `Mounts`:
```
$ curl -XPOST localhost:2375/containers/create -d '{
"Image": "alpine:latest",
"HostConfig": {
"Mounts": [{
"Type": "Volume",
"Target": "/foo"
},{
"Type": "bind",
"Source": "/var/run/docker.sock",
"Target": "/var/run/docker.sock",
},{
"Type": "volume",
"Name": "important_data",
"Target": "/var/data",
"ReadOnly": true,
"VolumeOptions": {
"DriverConfig": {
Name: "awesomeStorage",
Options: {"size": "10m"},
Labels: {"some":"label"}
}
}]
}
}'
```
There are currently 2 types of mounts:
- **bind**: Paths on the host that get mounted into the
container. Paths must exist prior to creating the container.
- **volume**: Volumes that persist after the
container is removed.
Not all fields are available in each type, and validation is done to
ensure these fields aren't mixed up between types.
Signed-off-by: Brian Goff <[email protected]>
Signed-off-by: Brian Goff <[email protected]>
d182d62 to
29b1c1d
Compare
|
LGTM! |
|
🎉 |
|
Is there a PR or a plan to support this new Mount in Swarmkit? I'd like to use it in #26331 |
|
@AkihiroSuda it is used in swarmkit, it is not yet supported on |
|
Well, swarmkit is still using the |
|
oh, sorry. |
|
Thank you, and while looking into the implementation, I got surprised that Swarmkit defines https://github.com/docker/docker/blob/master/api/types/mount/mount.go#L7-L10 |
|
@AkihiroSuda Yes, tmpfs needs to be implemented as well, thanks! |
- What I did
Add capability to
/containers/createAPI to specify mounts in a more granular and safer wayMountsallows users to specify in a much safer way the volumes theywant to use in the container.
- How I did it
Add new field
Mountsto HostConfig as well as newMountConfigThis replaces
BindsandVolumes, which both still exist, butMountsandBinds/Volumesare exclusive.The CLI will continue to use
BindsandVolumesdue to concerns withparsing the volume specs on the client side and cross-platform support.
- How to verify it
Example usage of
Mounts:There are currently 2 types of mounts:
container. Paths must exist prior to creating the container.
container is removed.
Not all fields are available in each type, and validation is done to
ensure these fields aren't mixed up between types.
- Description for the changelog
Add capability to
/containers/createAPI to specify mounts in a more granular and safer way- A picture of a cute animal (not mandatory but encouraged)
