1.Docker 遷移存儲目錄

默認情況系統會將 Docker 容器存放在 /var/lib/docker 目錄下

• [問題起因] 今天通過監控系統，發現公司其中一臺服務器的磁盤快慢，隨即上去看了下，發現 /var/lib/docker 這個目錄特別大。由上述原因，我們都知道，在 /var/lib/docker 中存儲的都是相關于容器的存儲，所以也不能隨便的將其刪除掉。
• 那就準備遷移 docker 的存儲目錄吧，或者對 /var 設備進行擴容來達到相同的目的。更多關于 dockerd 的詳細參數，請點擊查看 官方文檔 地址。
• 但是需要注意的一點就是，盡量不要用軟鏈， 因為一些 docker 容器編排系統不支持這樣做，比如我們所熟知的 k8s 就在內。

• [解決方法 1] 添加軟鏈接

• [解決方法 2] 改動 docker 配置文件

• [操作注意事項] 在遷移 docker 目錄的時候注意使用的命令，要么使用 mv 命令直接移動，要么使用 cp 命令復制文件，但是需要注意同時復制文件權限和對應屬性，不然在使用的時候可能會存在權限問題。如果容器中，也是使用 root 用戶，則不會存在該問題，但是也是需要按照正確的操作來遷移目錄。

• 下圖中，就是因為啟動的容器使用的是普通用戶運行進程的，且在運行當中需要使用 /tmp 目錄，結果提示沒有權限。在我們導入容器鏡像的時候，其實是會將容器啟動時需要的各個目錄的權限和屬性都賦予了。如果我們直接是 cp 命令單純復制文件內容的話，就會出現屬性不一致的情況，同時還會有一定的安全問題。

Docker遷移存儲目錄

2.Docker 設備空間不足

Increase Docker container size from default 10GB on rhel7.

• [問題起因一] 容器在導入或者啟動的時候，如果提示磁盤空間不足的，那么多半是真的因為物理磁盤空間真的有問題導致的。如下所示，我們可以看到 / 分區確實滿了。

• 如果發現真的是物理磁盤空間滿了的話，就需要查看到底是什么占據了如此大的空間，導致因為容器沒有空間無法啟動。其中，docker 自帶的命令就是一個很好的能夠幫助我們發現問題的工具。

• [解決方法] 通過查看信息，我們知道正是因為 docker 可用的磁盤空間不足，所以導致啟動的時候沒有足夠的空間進行加載啟動鏡像。解決的方法也很簡單，第一就是清理無效數據文件釋放磁盤空間(清除日志)，第二就是修改 docker 數據的存放路徑(大分區)。

• [問題起因二] 顯然我遇到的不是上一種情況，而是在啟動容器的時候，容器啟動之后不久就顯示是 unhealthy 的狀態，通過如下日志發現，原來是復制配置文件啟動的時候，提示磁盤空間不足。
• 后面發現是因為 centos7 的系統使用的 docker 容器默認的創建大小就是 10G 而已，然而我們使用的容器卻超過了這個限制，導致無法啟動時提示空間不足。

• [解決方法 1] 改動 docker 啟動配置文件

• [解決方法 2] 改動 systemctl 的 docker 啟動文件

• [問題起因三] 還有一種情況也會讓容器無法啟動，并提示磁盤空間不足，但是使用命令查看發現并不是因為物理磁盤真的不足導致的。而是，因為對于分區的 inode 節點數滿了導致的。

• [解決方法] 因為 ext3 文件系統使用 inode table 存儲 inode 信息，而 xfs 文件系統使用 B+ tree 來進行存儲?？紤]到性能問題，默認情況下這個 B+ tree 只會使用前 1TB 空間，當這 1TB 空間被寫滿后，就會導致無法寫入 inode 信息，報磁盤空間不足的錯誤。我們可以在 mount 時，指定 inode64 即可將這個 B+ tree 使用的空間擴展到整個文件系統。

• [補充知識] 文件儲存在硬盤上，硬盤的最小存儲單位叫做 扇區(Sector)。每個扇區儲存 512 字節(相當于0.5KB)。操作系統讀取硬盤的時候，不會一個個扇區地讀取，這樣效率太低，而是一次性連續讀取多個扇區，即一次性讀取一個塊(block)。這種由多個扇區組成的塊，是文件存取的最小單位。塊的大小，最常見的是4KB，即連續八個 sector 組成一個 block 塊。文件數據都儲存在塊中，那么很顯然，我們還必須找到一個地方儲存文件的元信息，比如文件的創建者、文件的創建日期、文件的大小等等。這種儲存文件元信息的區域就叫做索引節點(inode)。每一個文件都有對應的 inode，里面包含了除了文件名以外的所有文件信息。
• inode 也會消耗硬盤空間，所以硬盤格式化的時候，操作系統自動將硬盤分成兩個區域。一個是數據區，存放文件數據；另一個是 inode 區(inode table)，存放 inode 所包含的信息。每個 inode 節點的大小，一般是 128 字節或 256 字節。inode 節點的總數，在格式化時就給定，一般是每1KB或每2KB就設置一個 inode 節點。

3.Docker 缺共享鏈接庫

Docker 命令需要對/tmp 目錄下面有訪問權限

• [問題起因] 給系統安裝完 compose 之后，查看版本的時候，提示缺少一個名為 libz.so.1 的共享鏈接庫。第一反應就是，是不是系統少安裝那個軟件包導致的。隨即，搜索了一下，將相關的依賴包都給安裝了，卻還是提示同樣的問題。

• [解決方法] 后來發現，是因為系統中 docker 沒有對 /tmp 目錄的訪問權限導致，需要重新將其掛載一次，就可以解決了。

4.Docker 容器文件損壞

對 dockerd 的配置有可能會影響到系統穩定

• [問題起因] 容器文件損壞，經常會導致容器無法操作。正常的 docker 命令已經無法操控這臺容器了，無法關閉、重啟、刪除。正巧，前天就需要這個的問題，主要的原因是因為重新對 docker 的默認容器進行了重新的分配限制導致的。

• [解決方法] 可以通過以下操作將容器刪除/重建。

5.Docker 容器優雅重啟

不停止服務器上面運行的容器，重啟 dockerd 服務是多么好的一件事

• [問題起因] 默認情況下，當 Docker 守護程序終止時，它會關閉正在運行的容器。從 Docker-ce 1.12 開始，可以在配置文件中添加 live-restore 參數，以便在守護程序變得不可用時容器保持運行。需要注意的是 windows 平臺暫時還是不支持該參數的配置。

• [解決方法] 可以通過以下操作將容器刪除/重建。

6.Docker 容器無法刪除

找不到對應容器進程是最嚇人的

• [問題起因] 今天遇到 docker 容器無法停止/終止/刪除，以為這個容器可能又出現了 dockerd 守護進程托管的情況，但是通過 ps -ef <container id> 無法查到對應的運行進程。哎，后來開始開始查 supervisor 以及 Dockerfile 中的進程，都沒有。這種情況的可能原因是容器啟動之后，主機因任何原因重新啟動并且沒有優雅地終止容器。剩下的文件現在阻止你重新生成舊名稱的新容器，因為系統認為舊容器仍然存在。

• [解決方法] 找到 /var/lib/docker/containers/ 下的對應容器的文件夾，將其刪除，然后重啟一下 dockerd 即可。我們會發現，之前無法刪除的容器沒有了。

7.Docker 容器中文異常

容器存在問題話，記得優先在官網查詢

• [問題起因] 今天登陸之前部署的 MySQL 數據庫查詢，發現使用 SQL 語句無法查詢中文字段，即使直接輸入中文都沒有辦法顯示。

• [解決方法] Docker 部署的 MySQL 系統使用的是 POSIX 字符集。然而 POSIX 字符集是不支持中文的，而 C.UTF-8 是支持中文的只要把系統中的環境 LANG 改為 "C.UTF-8" 格式即可解決問題。同理，在 K8S 進入 pod 不能輸入中文也可用此方法解決。

8.Docker 容器網絡互通

了解 Docker 的四種網絡模型

• [問題起因] 在本機部署 Nginx 容器想代理本機啟動的 Python 后端服務程序，但是對代碼服務如下的配置，結果訪問的時候一直提示 502 錯誤。

• [解決方法] 后面發現是因為 nginx.conf 配置文件中的 localhost 配置的有問題，由于 Nginx 是在容器中運行，所以 localhost 為容器中的 localhost，而非本機的 localhost，所以導致無法訪問。
• 可以將 nginx.conf 中的 localhost 改為宿主機的 IP 地址，就可以解決 502 的錯誤。

• 當容器使用 host 網絡時，容器與宿主共用網絡，這樣就能在容器中訪問宿主機網絡，那么容器的 localhost 就是宿主機的 localhost 了。

9.Docker 容器總線錯誤

總線錯誤看到的時候還是挺嚇人了

• [問題起因] 在 docker 容器中運行程序的時候，提示 bus error 錯誤。

• [解決方法] 原因是在 docker 運行的時候，shm 分區設置太小導致 share memory 不夠。不設置 --shm-size 參數時，docker 給容器默認分配的 shm 大小為 64M，導致程序啟動時不足。具體原因還是因為安裝 pytorch 包導致了，多進程跑任務的時候，docker 容器分配的共享內存太小，導致 torch 要在 tmpfs 上面放模型數據用于子線程的 共享不足，就出現報錯了。

• [解決方法] 還有一種情況就是容器內的磁盤空間不足，也會導致 bus error 這樣的報錯，所以如果出現了，清除多余文件和目錄或者分配一個大的磁盤空間，就可以解決了。

10.Docker NFS 掛載報錯

NFS 掛載之后容器程序使用異常為內核版本太低導致的

• [問題起因] 我們將服務部署到 openshift 集群中，啟動服務調用資源文件的時候，報錯信息如下所示。從報錯信息中，得知是在 Python3 程序執行 read_file() 讀取文件的內容，給文件加鎖的時候報錯了。但是奇怪的是，本地調試的時候發現服務都是可以正常運行的，文件加鎖也是沒問題的。后來發現，在 openshift 集群中使用的是 NFS 掛載的共享磁盤。

• [解決方法] 從下面的信息得知，要在 linux 中使用 flock() 的話，就需要升級內核版本到 2.6.11+ 才行。后來才發現，這實際上是由 RedHat 內核中的一個錯誤引起的，并在 kernel-3.10.0-693.18.1.el7 版本中得到修復。所以對于 NFSv3 和 NFSv4 服務而已，就需要升級 Linux 內核版本才能夠解決這個問題。

11.Docker 使用默認網段

啟動的容器網絡無法相互通信，很是奇怪！

• [問題起因] 我們在使用 Docker 啟動服務的時候，發現有時候服務之前可以相互連通，而有時啟動的多個服務之前卻出現了無法訪問的情況。究其原因，發現原來是因為使用的內部私有地址網段不一致導致的。有的服務啟動到了 172.17 - 172.31 的網段，有的服務跑到了 192.169.0 - 192.168.224 的網段，這樣導致服務啟動之后出現無法訪問的情況(默認情況下，有下面這個兩個網段可供其使用)。

Docker默認使用網段

• [解決方法] 上述問題的處理方式，就是手動指定 Docker 服務的啟動網段，二選一就可以了。

12.Docker 服務啟動串臺

使用 docker-compose 命令各自啟動兩組服務，發現服務會串臺！

• [問題起因] 在兩個不同名稱的目錄目錄下面，使用 docker-compose 來啟動服務，發現當 A 組服務啟動完畢之后，再啟動 B 組服務的時候，發現 A 組當中對應的一部分服務又重新啟動了一次，這就非常奇怪了！因為這個問題的存在會導致，A 組服務和 B 組服務無法同時啟動。之前還以為是工具的 Bug，后來請教了 “上峰”，才知道了原因，恍然大悟。

• [解決方法] 發現 A 和 B 兩組服務會串臺的原因，原來是 docker-compose 會給啟動的容器加 label 標簽，然后根據這些 label 標簽來識別和判斷對應的容器服務是由誰啟動的、誰來管理的，等等。而這里，我們需要關注的 label 變量是 com.docker.compose.project，其對應的值是使用啟動配置文件的目錄的最底層子目錄名稱，即上面的 App 就是對應的值。我們可以發現， A 和 B 兩組服務對應的值都是 app，所以啟動的時候被認為是同一個，這就出現了上述的問題。如果需要深入了解的話，可以去看對應源代碼。

Docker服務啟動串臺

• 或者使用 docker-compose 命令提供的參數 -p 手動指定標簽，來規避該問題的發生。

13.Docker 命令調用報錯

在編寫腳本的時候常常會執行 docker 相關的命令，但是需要注意使用細節！

• [問題起因] CI 更新環境執行了一個腳本，但是腳本執行過程中報錯了，如下所示。通過對應的輸出信息，可以看到提示說正在執行的設備不是一個 tty。

Docker命令調用報錯

• 隨即，查看了腳本發現報錯地方是執行了一個 exec 的 docker 命令，大致如下所示。很奇怪的是，手動執行或直接調腳本的時候，怎么都是沒有問題的，但是等到 CI 調用的時候怎么都是有問題。后來好好看下，下面這個命令，注意到 -it 這個參數了。

• 我們可以一起看下 exec 命令的這兩個參數，自然就差不多理解了。

• [解決方法] docker exec 的參數 -t 是指 Allocate a pseudo-TTY 的意思，而 CI 在執行 job 的時候并不是在 TTY 終端中執行，所以 -t 這個參數會報錯。同時在 『stackoverflow』也有人給出原因，可以自行查看。

Docker命令調用報錯

14.Docker 定時任務異常

在 Crontab 定時任務中也存在 Docker 命令執行異常的情況！

• [問題起因] 今天發現了一個問題，就是在備份 Mysql 數據庫的時候，使用 docker 容器進行備份，然后使用 Crontab 定時任務來觸發備份。但是發現備份的 MySQL 數據庫居然是空的，但是手動執行對應命令切是好的，很奇怪。

• [解決方法] 后來發現是因為執行的 docker 命令多個 -i 導致的。因為 Crontab 命令執行的時候，并不是交互式的，所以需要把這個去掉才可以?？偨Y就是，如果你需要回顯的話則需要 -t 選項，如果需要交互式會話則需要 -i 選項。

15.Docker 變量使用引號

compose 里邊環境變量帶不帶引號的問題！

• [問題起因] 使用過 compose 的朋友可能都遇到過，在編寫啟服務啟動配置文件的時候，添加環境變量時到底是使用單引號、雙引號還是不使用引號的問題？時間長了，我們可能會將三者混用，認為其效果是一樣的。但是后來，發現的坑越來越多，才發現其越來越隱晦。
• 反正我是遇到過很多問題，都是因為添加引號導致的服務啟動異常的，后來得出的結論就是一律不使引號。裸奔，體驗前所未有的爽快！直到現在看到了 Github 中對應的 issus 之后，才終于破案了。

• [解決方法] 得到的結論就是，因為 Compose 解析 yaml 配置文件，發現引號也進行了解釋包裝。這就導致原本的 TEST_VAR="test" 被解析成了 'TEST_VAR="test"'，所以我們在引用的時候就無法獲取到對應的值。現在解決方法就是，不管是我們直接在配置文件添加環境變量或者使用 env_file 配置文件，能不使用引號就不適用引號。
• 需要注意的是環境變量配置的是日志格式的話(2022-01-01)，如果使用的是 Python 的 yaml.load 模塊的話，會被當做是 date 類型的，這是如果希望保持原樣信息的話，可以使用 '/" 引起來將其變成字符串格式的。

16.Docker 刪除鏡像報錯

無法刪除鏡像，歸根到底還是有地方用到了！

• [問題起因] 清理服器磁盤空間的時候，刪除某個鏡像的時候提示如下信息。提示需要強制刪除，但是發現及時執行了強制刪除依舊沒有效果。

• [解決方法] 后來才發現，出現這個原因主要是因為 TAG，即存在其他鏡像引用了這個鏡像。這里我們可以使用如下命令查看對應鏡像文件的依賴關系，然后根據對應 TAG 來刪除鏡像。

17.Docker 普通用戶切換

切換 Docker 啟動用戶的話，還是需要注意下權限問題的！

• 問題起因] 我們知道在 Docker 容器里面使用 root 用戶的話，是不安全的，很容易出現越權的安全問題，所以一般情況下，我們都會使用普通用戶來代替 root 進行服務的啟動和管理的。今天給一個服務切換用戶的時候，發現 Nginx 服務一直無法啟動，提示如下權限問題。因為對應的配置文件也沒有配置 var 相關的目錄，無奈 ‍♀ ！?

• [解決方法] 后來發現還是 nginx.conf 配置文件，配置的有問題，需要將 Nginx 服務啟動時候需要的文件都配置到一個無權限的目錄，即可解決。

18.Docker 綁定到 IPv6 上

Docker 服務在啟動的時候，將地址綁定到 IPv6 地址上面了，提示報錯信息！

• [問題起因] 物理機器更新了對應補丁之后，重啟了服務，導致原本可以正常啟動的 docker-compose 服務提示如下報錯信息。不清楚是否修改了操作系統的相關配置，還是對應 docker 進行的其他方面的配置，比如修改 /etc/docker/daemon.json 或者 docker 的 service 啟動文件。

• [解決方法] 通過如上所示的報錯信息，可以看到服務的啟動端口綁定到了 tcp6 上面了，但是對應的 socket 發現系統本身并不支持。這時，我們一看下對應的操作系統 ipv6 的設置，發現系統禁用了，所有的 ipv6 地址。需要了解的朋友，可以參考 fix port forwarding with ipv6.disable=1 和 cannot start if ipv6 is disabled on host 這兩個 issus 來獲取更多信息。

• [方法一] 最為簡單的解決方法，就是在 docker-compose.yml 文件中，手動指定將對應服務的端口綁定到 ipv4 上面，如下所示。

• [方法二] 或者修改 /etc/docker/daemon.json 文件，在配置中，阻止 Docker 錯誤的將端口映射到 IPv6 上，即可達到同樣的效果，且不用再次修改多個服務的啟動配置文件了。

• [方法三] Docker 默認情況下會同時將端口映射于 IPv4 與 IPv6 兩者上，而且有的時候會出現只綁定到了 IPv6，導致服務無法正常訪問的情況?，F在通用的始終還是 IPv4 地址，因此最簡單的做法就是關閉 IPv6 地址。詳細的配置，可以參考 Port redirecting binding to IPv6 but not IPv4 interfaces 這個 issus 地址。

19. Docker 容器啟動超時

Docker 服務在啟動的時候，提示超時，被直接終止了！

• [問題起因] 使用 docker-compose 啟動容器的時候，等待了很久的時候(大約 2-3 分鐘左右)，之后提示如下信息。通過閱讀信息內容，可以看到是因為超時導致的，提示可以通過設置環境變量，加大超時的時間。

• [解決方法] 按照提示設置的環境變量之后，再次啟動發現確實可以正常啟動了，但是還是能夠感覺到有些慢。

• 排除了下啟動流程，因為容器啟動有映射目錄到容器里面且目錄大小比較大，所以懷疑是因為 i/o 導致的。隨即使用 iotop 命令查看服務器目前的 i/o 情況，發現存在很多個 rg 命令，且都處于 100% 左右。查了下，發現是 vscode 遠程服務器啟動的搜索目錄結構的進程，西八，有些坑呀！

20.Docker 端口網絡限制

如果發現服務都一切正常，但是無法無法訪問的話，則多為網絡問題！

• [問題起因] 啟用服務之后，登錄跳轉發現直接 502 報錯了。排除了配置等相關原因都沒有任何問題(做過相關測試)，這就非常奇怪了！

• [解決方法] 根據錯誤信息可知，是因為沒有路由到指定的 host 導致了，隨即看了下防火墻是開著的，看了日志發現被過濾掉了，西八！問題找到了，現在需要做的就是，要么添加防火墻規則，要么關閉防火墻。

21.Docker 無法獲取鏡像

新初始化的機器，無法獲取私有倉庫的鏡像文件！

• [問題起因] 機器初始化之后，使用如下命令登錄私有 docker 倉庫，發現提示無法獲取對應鏡像，但是在其他機器上面獲取該鏡像就可以執行成功，這就非常奇怪了！

• [解決方法] 太坑了，我還以為我發現某個隱藏的 bug 了，可勁的排查，最后發現，原來是自己鏡像包名字寫錯了，應該寫成 0.0.10 的，自己卻寫成了 0.10。這里，紀念一下，以后碰到上述報錯，那肯定是鏡像不存在的。

22.Docker 使容器不退出

如何使使用 docker-compose 啟動的容器服務 hang 住而不退出

• [問題起因] 有時候我們啟動的服務，因為某些問題(bug)導致服務無法正常啟動，就會出現容器無限重啟(restart: on-failure)的情況，這時就很不利于排除問題。

• [解決方法] 這時我們就需要根據，服務構建使用命令來決定是用什么命令來 hang 住服務。卡住的原理，就類似于使用 /bin/bash 進入容器是一樣的，這里我就不過多解釋了。

• 同理，我們在使用 docker-compose 或者 k8s 平臺部署服務的時候，也有時會因為啟動問題需要，使啟動的服務不直接退出，來手動調試和排查問題原因。所以，我這里記錄下其不同部署方式的，暫停方式。

23.Docker 不使用默認網段

有些情況，內部規劃的網段和可能和 Dockerd 默認的網段有沖突，導致異常出現！

• [問題起因] 今天在新機器上面，部署了一整套服務(多臺機器)，服務部署完畢之后，通過前置 Nginx 服務發現并不能訪問，后置機器開放的端口，發現發到對應端口的請求都沒有轉發出去。這就比較奇怪了，因為端口控制是已經開通了的，不應該出現不通的情況。

• [解決方法] 發現服務器端口不通，我這里懷疑可能是 dockerd 服務啟動導致的，所以我先將服務都停掉，直接在機器上面啟動了 Python 的服務端程序(Linux 機器自帶 Python2.7.x 的版本)，然后在前置 Nginx 服務發現，端口確實是通的。后來，排除發現是內部服務默認網段和 dockerd 服務啟動的默認網段是沖突的，導致重寫了機器的防火墻規則，導致出現上述異常的。

• 既然問題已經知道了，現在需要做的就是非常簡單了：不適用默認網段！通過 『mirantis』 里面，我們可以選擇進行設置，然后重啟服務 dockerd 服務，即可。

• 這時，就到了考驗我們網絡的子網劃分的能力了：如何在給定的網段下面合理且高效的進行劃分呢？咳咳，確實難倒我了，這時我們可以再這個在線網站上面 JSON 在線解析 進行劃分，然后選定合理的 base 和 size 就可以了。
• 其中，base 告訴我們劃分子網的網段是什么(從來開始)，是從前兩位(/16)開始，還是第三位開始(/24)呢？而 size 則告訴我們劃分的每個子網有多少 IP 地址可以使用呢？從 "10.210.200.0/24" 我們可以知道，該網絡下面只有 254 個可用的 IP 地址(直接使用肯定不夠)，然后我們需要給 docker 使用，劃分每個子網可用 16 個 IP 地址，所以子網就應該寫成 28 了。

Docker 不使用默認網段

24.Docker 添加私有倉庫

有些情況，我們服務器上面需要使用內部私有的容器鏡像地址！

• [問題起因] 如果新機器上面需要使用私有倉庫的話，但是又沒有配置，再獲取鏡像的時候就會出現如下報錯信息。

• [解決方法] 該問題的處理方式很簡單，如下所示，配置一下倉庫地址，重啟服務并登陸私有倉庫就可以了。

參考鏈接：公眾號-奇妙的Linux世界