❶ Docker映射配置文件到宿主機
最近在做mysql中間件的docker，搞了mycat、mysql route都拉不起來容器，最後試試proxysql可以，proxysql官方發布了鏡像，感覺比較可靠。但是遇到一個小問題，筆者以前寫過一篇文章-Docker MySQL數據持久化，用數據卷掛載的方式將mysql的數據（映射數據目錄）持久化到宿主機。那麼配置文件也是有必要來映射的，注意就可以避免在容器內安裝編輯器。
容器內有apt 和ap-get工具，安裝前要apt update（或者apt-get update，較慢）更新軟體列表，然後apt install（或者apt-get install），這樣會增大容器空間，是沒有必要的。筆者以前就是這樣操作的，但是比較麻煩，而且容器如果是內部網路的話來安裝的話就更加不方便了。筆者在映射數據目錄時使用-v /home/mysql/data:/var/lib/mysql 。但是使用同樣的分發，今天在映射proxysql的配置文件proxysql.cnf時遇到一個麻煩。
先看看筆者掛載時遇到的問題： Are you trying to mount a directory onto a file。
都是文件，那裡來的目錄呢。映射的意思是將可以將宿主機目錄掛載到容器中，那麼可能就是將/home/mycentos/proxysql.cnf設別為一個目錄了，因為容器內/etc/proxysql.cnf的是真實存在的文件。在/home/mycentos/目錄下ls -l查看一下。
果然是目錄！輾轉反側找到原因是 docker啟動容器進行掛載的時候,如果路徑不存在,那麼docker會自動創建一個目錄。
筆者的home/mycentos/目錄下沒有proxysql.cnf文件，掛載時docker就新建了一個proxysql.cnf的目錄，但是這個對於掛載數據目錄時是十分有用的，對於配置文件來說是不行的。於是筆者在目錄home/mycentos/下新建了一個proxysql.cnf文件，再次運行docker run成功（前面運行失敗的容器需要刪除，不然名稱沖突）。
docker run -itd --name proxysql -p 16032:6032 -p 16033:6033 -p 16070:6070 -v /home/mycentos/proxysql.cnf:/etc/proxysql.cnf proxysql/proxysql
掛載後，容器內的/etc/proxysql.cnf配置文件是空的，不掛載的情況下是保持默認配置文件內容的，使用徐需要在編輯/home/mycentos/proxysql.cnf文件，然後進入容器後/etc/proxysql.cnf配置文件會跟隨改變的。但是配置文件為空，那麼就要從頭開始配置，這對於配置文件很多的話是不方便的，保留原來的配置配置文件，再在裡面修改會更加方便。這里筆者只能想到先運行一個容器，然後docker cp拷貝容器內的文件或者文件夾，在刪除這個容器，另外開一個配置文件映射的容器。
映射配置文件避免在容器內進行apt操作，使得容器膨脹過大。比如你要安裝編輯器vi，首先要apt update更新，然後apt install ，相比於在容器外對其進行操作來說，更加麻煩沒必要。
❷ docker常用文件映射方式-bind vs volume
Docker中，數據持久化是常見需求。官方推薦的文件映射方式是通過volume（數據卷）。volume是一種獨立於容器生命周期的存儲，它可以跨容器復用，提供了更好的數據管理和隔離性。然而，在實際操作中，許多人更傾向於使用bind（-v掛載）方式，直接將本地磁碟掛載到容器中。
bind掛載允許你直接映射容器的文件系統到主機的目錄，優點在於操作簡便，適合臨時數據或開發環境，因為數據更改會立即反映到宿主機。然而，bind方式存在數據丟失風險，因為容器的生命周期結束後，映射的本地文件可能會被刪除。
相比之下，volume的優勢在於它創建了一個獨立的存儲空間，容器重啟或刪除後，volume中的數據仍會保留。這對於需要長期存儲或需要數據持久化的場景更為合適。此外，volume還可以在多個容器間共享，提高了資源利用率。
總結來說，選擇bind還是volume取決於你的具體需求。如果追求便捷性和開發環境的實時反饋，bind可能是首選；而對數據持久性、復用性和安全性有更高要求的生產環境，volume則更為理想。官方推薦volume，是基於其在大規模部署和數據管理上的優勢。