背景
我們公司系統採用微服務架構，每次提交代碼自動利用Jenkins構建成Docker鏡像推送到Harbor私服，然後部署到K8S環境。
我們的持續集成環境Jenkins、Nexus和Harbor都部署在一臺服務器上。
問題
過年放假回來，我發現Jenkins構建非常慢。
分析過程
首先，我懷疑是不是硬盤滿了。通過df -h命令查看
文件系統 容量 已用 可用 已用% 掛載點
/dev/mapper/centos-root 496G 489G 6.4G 99% /
devtmpfs 2.9G 0 2.9G 0% /dev
tmpfs 2.9G 0 2.9G 0% /dev/shm
tmpfs 2.9G 306M 2.6G 11% /run
tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup
/dev/sda1 1014M 142M 873M 14% /boot
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/ae9d672f614f6d2e7a436ca4d29fb56d892675cc8bbd9d244f460683dad8b87f/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/5a79a3cdecd5ca7c2840b0846f6736d3de6b7da0a4d4d81652a9b15af9c46370/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/614b70e0b3e9782fbe218d2aad9d748cc02c7768feab9976c13eea2e23164921/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/a49a997083f6ae89b6c0a537ec35f26fec88705597b6227724d6d510dd1a1ad3/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/08893dcc508e8a3277b3124ad77e4f1753fd72491172b5fd7d347244b27564ee/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/df52246abd100df2df119ba23dd1482b85d0a34fb1f6cfc8a0a95cc9da5e84ed/merged
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/1dc0e6d16a354a1aeaa0340401fd8cae89047da1d68bb8aedb15f655e47d61d6/merged
shm 64M 4.0K 64M 1% /var/lib/docker/containers/794b6ee5914330556c9cfef46d514beb7dd43b957d473ccf17b219381dd4249a/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/5e15b0dc478dd229db5f1fa1dbc3c042fab306bb956ec117edbba8c1403e38d5/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/f88e6312f68139a03c138117e53f9ce4dff46677bd2fd238a0650d7baeec20f0/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/7d6ffd81852c8c4f0c4036880f9cb7563c2ee71ae287cac6927ae142db74c390/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/740c664fa12d2be7c51196b9531f3854b9446199ee8f24d634ec24c6fe43f37d/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/5017ce1922b22c6054edc167b6c1112bc1cd9d188ebab77b14f0aaf0db60409e/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/2fe712ff7df3ce8beb2d7f047a825555ae138aeac9b4daef84de40257a6e8573/mounts/shm
overlay 496G 489G 6.4G 99% /var/lib/docker/overlay2/8c1dff4865db5f2e175cf57b9056a0848750c431f968c65ea7560b9a7f4c4384/merged
shm 64M 0 64M 0% /var/lib/docker/containers/acdc2754e191cded34d8f25f0d22199c48e2ae08d666eeed8d814daceed206a0/mounts/shm
tmpfs 581M 0 581M 0% /run/user/0
的確是硬盤滿了，整個硬盤佔用99%，這其中/var/lib/docker/overlay2…佔用空間最大。
overlay2存儲的都是鏡像層數據，網上搜索都說是image過多。
我再通過docker system df命令查看
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 59 8 8.099GB 7.53GB (92%)
Containers 8 8 954.9kB 0B (0%)
Local Volumes 274 5 70.37kB 70.34kB (99%)
Build Cache 0 0 0B
Images佔用不足8G。
我再使用docker images輸出所有鏡像，彙總所有images的SIZE顯示有30G，和docker system df輸出數據對不上，但也沒有490G。
我前面懷疑服務器鏡像過多，嘗試好長時間，清理鏡像佔用的空間，發現效果不佳。接下來，我直接查看整個服務器硬盤。
服務器根目錄運行 df -h * 查看每個目錄佔用空間，結果顯示/data/registry/docker/registry/v2/blobs目錄佔用空間接近350G。
registry說明是鏡像倉庫佔用空間大。
我們私服採用Harbor，Harbor Web端顯示倉庫裏面的鏡像並不多，大概60個，每個約100M，大約6G。和實際佔用空間對不上。
通過查資料，發現是我們系統持續集成推送的tag一直不變的問題。
我們系統持續集成，每個微服務推送鏡像tag都是latest。所以Harbor Web顯示鏡像不多，但磁盤充滿歷史鏡像。具體參考Harbor歷史鏡像清理問題
解決方法
Harbor沒有提供機制自動清理，需要手動利用registry鏡像清理。
注意registry要2.7.1以上版本才能清理同一個tag標籤的歷史鏡像。
清理命令如下，
docker run -it --name gc --rm --volumes-from registry goharbor/registry-photon:v2.7.1-patch-2819-2553-v1.9.4 garbage-collect -m /etc/registry/config.yml
注意：上述命令依賴一個名稱是registry且正在運行的goharbor/registry-photon容器。
可以把上述命令做成bash腳本，crontab定時清理。
0 1 * * * /home/local/clean-docker.sh
經驗總結
1、找到問題根源很重要。前面沒找到硬盤滿根源，通過表象就去尋找解決方案，浪費很多時間。
2、要敢於嘗試。我找到上面”清理命令“時，由於作者環境不一樣及沒有說明怎麼用和自己擔心弄壞集成環境，不敢嘗試。後面找到garbage-collect的–dry-run參數纔敢嘗試。