類別
Docker
更新
Dec 20, 2021 06:16 PM
完成
完成
Use bind mounts
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, and 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.
Choose the -v or --mount flag
In general,
--mount is more explicit and verbose. The biggest difference is that the -v syntax combines all the options together in one field, while the --mount syntax separates them. Here is a comparison of the syntax for each flag.Tip: New users should use the--mountsyntax. Experienced users may be more familiar with the-vor --volumesyntax, but are encouraged to use--mount, because research has shown it to be easier to use.
和volume一樣，可以用
-v或—-mount語法不同
—mount
-v
Differences between -v and -mount behavior
Because the
-v and --volume flags have been a part of Docker for a long time, their behavior cannot be changed. This means that there is one behavior that is different between -v and --mount.- If you use
-vor--volumeto bind-mount a file or directory that does not yet exist on the Docker host,-vcreates the endpoint for you. It is always created as a directory.
- If you use
--mountto bind-mount a file or directory that does not yet exist on the Docker host, Docker does not automatically create it for you, but generates an error.
我覺得
--mount的行為更合理，mount一個容器中不存在的資料夾，應該要出現錯誤，因為我們往往就是以要它存在為前提才能正常運作Start a container with a bind mount
Consider a case where you have a directory
source and that when you build the source code, the artifacts are saved into another directory, source/target/. You want the artifacts to be available to the container at /app/, and you want the container to get access to a new build each time you build the source on your development host. Use the following command to bind-mount the target/ directory into your container at /app/. Run the command from within the source directory. The $(pwd) sub-command expands to the current working directory on Linux or macOS hosts.The
--mount and -v examples below produce the same result. You can’t run them both unless you remove the devtest container after running the first one.-v
Use
docker inspect devtest to verify that the bind mount was created correctly. Look for the Mounts section:This shows that the mount is a
bind mount, it shows the correct source and destination, it shows that the mount is read-write, and that the propagation is set to rprivate.⭐️⭐️⭐️ Mount into a non-empty directory on the container
If you bind-mount into a non-empty directory on the container, the directory’s existing contents are obscured by the bind mount. This can be beneficial, such as when you want to test a new version of your application without building a new image. However, it can also be surprising and this behavior differs from that of docker volumes.
This example is contrived to be extreme, but replaces the contents of the container’s
/usr/ directory with the /tmp/ directory on the host machine. In most cases, this would result in a non-functioning container.>> obscure： not well known and usually not very important
講白了就是容器上的dst路徑資料夾暫時被「隱藏——無法從原來的路徑存取到」，連進去就會連回本機的mount資料夾，但原來容器上的東西並不受影響