一直一來，對於多個容器需要共享訪問同一資料目錄，或者需要持久化容器內資料（如資料庫）時，我們都是採用掛載目錄形式（bind mounts），將宿主機的某一目錄掛載到容器內的指定目錄，這種方式能解決問題，但這種方式也一直有一些缺點：

容器在不同的伺服器部署需要根據實際磁碟掛載目錄修改路徑不同作業系統的檔案和目錄許可權會搞得你昏頭轉向，火冒三丈 ?

而這些問題，使用Volume就可以解決。我們先來對比一下bind mounts和docker volume，然後看volume是如何解決bind mounts的問題的。先來看一張圖：

此圖來自docker文件

這張圖說明bind mount和volume其實都是利用宿主機的檔案系統，不同之處在於volume是docker自身管理的目錄中的子目錄，所以不存在許可權引發的掛載的問題，並且目錄路徑是docker自身管理的，所以也不需要在不同的伺服器上指定不同的路徑，你不需要關心路徑（其實也不全是，下面會關心 ?）。接下來就來看看bind mount和volume的不同用法吧。

1. 容器在不同的伺服器部署需要根據實際磁碟掛載目錄修改路徑

例如：

在Linux系統中，我們經常使用"/var/someDir"作為掛載目錄；

然而到了Mac上，/var/ 並不是真實存在的目錄，Mac使用者會告訴你，我們比Linux更先進，我們不用 /var/，使用者不需要；

在Windows系統中，Windows使用者會反問你：/var/ 是什麼？C盤、D盤是最合理的劃分～～

大家都說自己最帥，到底誰是最帥的

mac中var目錄是一個軟連結

2. 不同作業系統的檔案和目錄許可權會搞得你昏頭轉向，火冒三丈 ?

本來在Linux系統中測試的挺好，結果到了Windows上掛載路徑各種問題，這裡就不一一細說了，沒有遇到這些問題的可以嘗試一下，體驗體驗。不過在Mac中還好一些，畢竟和Linux同宗。

Docker中除了掛載方式，還有一種Volume可以持久化資料，說到這裡有點汗顏，使用Docker這麼久，一直把掛載當成Volume，不過也不怪我，Docker-compose檔案中在volume段中寫容器和宿主機掛載路徑對映關係也沒問題，就一直這麼誤解了。。（花式甩鍋?）

其實“掛載”和“Docker Volume”並不是一回事，有一定的區別，Docker Volume是宣告式的，Docker Engine本身會佔用系統的某個目錄，Linux一般為"/var/lib/docker"，Mac和Windows下都可以調節。當我們宣告一個volume，Docker會預設在佔用的路徑下為volume分配一個路徑，例如：

標題

相對於掛載，volume是Docker Engine在自己的“地盤”分配了一個路徑作為掛載點，自己地盤的許可權肯定是安排的明明白白。所以，以上掛載宿主機路徑的問題都解決了。?

在使用時，直接用volume名稱代替宿主機路徑名就行，假設我們上面建立了名為"test_vol"的volume：

docker run -d -v "test_vol:/var/data" some_image，這樣就將容器內的/var/data目錄掛載到了"test_vol"的掛載點；docker-compose中類似，不過要在docker-compose.yaml檔案中宣告volume，我們還是拿上面的例子修改一下：

Attention !! ⚠️

需要注意 volume 會引起 docker目錄膨脹，因為既要存映象，又要存 volume，最好不要放在系統盤，將 docker 的安裝目錄配置到其他更大的掛載盤。兩者有一個不同的行為：當容器外的對應目錄是空的，volume會先將容器內的內容複製到容器外目錄，而mount會將外部的目錄覆蓋容器內部目錄！！volume 還有一個不如bind mount的地方，不能直接掛載檔案，例如掛載nginx容器的配置檔案：nginx.conf。

這裡需要說明，類似於配置檔案這種單檔案方式並不適合使用volume，bind mount雖然也可以解決，但由於config檔案中包含一些類似於資料庫密碼等敏感資訊，因此，最好的方式是使用tmpfs。

kubernetes的volume也體現出類似的設計，subPath雖然可以解決配置檔案掛載的問題，但實際最好的方式是使用configMap。