Add bind-mounts or volumes

https://docs.docker.com/engine/reference/commandline/service_create/#add-bind-mounts-or-volumes

Docker支持两种不同类型的安装，允许容器读取或写入其他容器或主机操作系统上的文件或目录。这些类型是 数据卷 （通常简称为卷）和  绑定安装

（Docker supports two different kinds of mounts, which allow containers to read to or write from files or directories on other containers or the host operating system. These types are  data volumes  (often referred to simply as volumes) and  bind-mounts .）

A  bind-mount  makes a file or directory on the host available to the container it is mounted within. A bind-mount may be either read-only or read-write. For example, a container might share its host’s DNS information by means of a bind-mount of the host’s /etc/resolv.conf  or a container might write logs to its host’s /var/log/myContainerLogs  directory. If you use bind-mounts and your host and containers have different notions of permissions, access controls, or other such details, you will run into portability issues.

A  named volume  is a mechanism for decoupling persistent data needed by your container from the image used to create the container and from the host machine. Named volumes are created and managed by Docker, and a named volume persists even when no container is currently using it. Data in named volumes can be shared between a container and the host machine, as well as between multiple containers. Docker uses a  volume driver  to create, manage, and mount volumes. You can back up or restore volumes using Docker commands.

A  tmpfs  mounts a tmpfs inside a container for volatile data.

Consider a situation where your image starts a lightweight web server. You could use that image as a base image, copy in your website’s HTML files, and package that into another image. Each time your website changed, you’d need to update the new image and redeploy all of the containers serving your website. A better solution is to store the website in a named volume which is attached to each of your web server containers when they start. To update the website, you just update the named volume.

Option	Required	Description
types		The type of mount, can be either volume, bind, or tmpfs. Defaults to volume if no type is specified. volume: mounts a [managed volume](volume_create.md) into the container. bind: bind-mounts a directory or file from the host into the container. tmpfs: mount a tmpfs in the container
src or source	for type=bindonly>	type=volume: src is an optional way to specify the name of the volume (for example, src=my-volume). If the named volume does not exist, it is automatically created. If no src is specified, the volume is assigned a random name which is guaranteed to be unique on the host, but may not be unique cluster-wide. A randomly-named volume has the same lifecycle as its container and is destroyed when the container is destroyed (which is upon service update, or when scaling or re-balancing the service) type=bind: src is required, and specifies an absolute path to the file or directory to bind-mount (for example, src=/path/on/host/). An error is produced if the file or directory does not exist. type=tmpfs: src is not supported.
dst or destinationor target	yes	Mount path inside the container, for example /some/path/in/container/. If the path does not exist in the container's filesystem, the Engine creates a directory at the specified location before mounting the volume or bind-mount.
readonly or ro		The Engine mounts binds and volumes read-write unless readonlyoption is given when mounting the bind or volume. true or 1 or no value: Mounts the bind or volume read-only. false or 0: Mounts the bind or volume read-write.
consistency		The consistency requirements for the mount; one of default: Equivalent to consistent. consistent: Full consistency. The container runtime and the host maintain an identical view of the mount at all times. cached: The host's view of the mount is authoritative. There may be delays before updates made on the host are visible within a container. delegated: The container runtime's view of the mount is authoritative. There may be delays before updates made in a container are are visible on the host.