2019/10/25更新：
docker commit是不能對容器中volume聲明的目錄改動進行保存的，無論是Dockerfile中的VOLUME字段，還是docker-compose.yaml中的volumes配置。
分割線，知乎上學到的套路。以下是原文：
一直一來，對於多個容器需要共享訪問同一數據目錄，或者需要持久化容器內數據（如數據庫）時，我們都是採用掛載目錄形式（bind mounts），將宿主機的某一目錄掛載到容器內的指定目錄，這種方式能解決問題，但這種方式也一直有一些缺點：
- 容器在不同的服務器部署需要根據實際磁盤掛載目錄修改路徑
- 不同操作系統的文件和目錄權限會搞得你昏頭轉向，火冒三丈 ?
而這些問題，使用Volume就可以解決。我們先來對比一下bind mounts和docker volume，然後看volume是如何解決bind mounts的問題的。先來看一張圖：
這張圖說明bind mount和volume其實都是利用宿主機的文件系統，不同之處在於volume是docker自身管理的目錄中的子目錄，所以不存在權限引發的掛載的問題，並且目錄路徑是docker自身管理的，所以也不需要在不同的服務器上指定不同的路徑，你不需要關心路徑（其實也不全是，下面會關心 ?）。接下來就來看看bind mount和volume的不同用法吧。
1. 容器在不同的服務器部署需要根據實際磁盤掛載目錄修改路徑
例如：
在Linux系統中，我們經常使用"/var/someDir"作爲掛載目錄；
然而到了Mac上，/var/ 並不是真實存在的目錄，Mac用戶會告訴你，我們比Linux更先進，我們不用 /var/，用戶不需要；
在Windows系統中，Windows用戶會反問你：/var/ 是什麼？C盤、D盤是最合理的劃分～～
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。