早上九點(diǎn)剛過監(jiān)控群里彈出一條告警某臺(tái)業(yè)務(wù)機(jī)的根分區(qū)使用率到了 93%。登上去一看/var/lib/docker這一個(gè)目錄就吃掉了一百二十多個(gè) G而真正跑著的容器加起來不到三個(gè)。這不是我第一次碰到這種場面也不會(huì)是最后一次。Docker 用久了體積膨脹本質(zhì)上是個(gè)記賬問題鏡像層、容器可寫層、日志文件、構(gòu)建緩存、命名卷每一筆都有自己的存放位置和生命周期你不管它它就一直在那兒躺著。這篇內(nèi)容我打算把四件事一次講透怎么在不誤刪重要數(shù)據(jù)的前提下把空間清出來、哪些東西必須先備份再動(dòng)手、備份怎么恢復(fù)回來、Docker 的壓縮能力到底壓的是什么、在哪些環(huán)節(jié)用得上、以及把整個(gè)數(shù)據(jù)目錄搬到另一塊大盤上的完整操作鏈路。剛接觸 Docker 的朋友可以照著命令一步步來已經(jīng)在一線維護(hù)機(jī)器的同行也能在里面的排查鏈路和踩坑記錄里找到點(diǎn)參考。1. 先定位再動(dòng)手那上百個(gè) G 究竟藏在 Docker 的哪個(gè)角落清理這件事最容易犯的錯(cuò)是一上來就敲docker system prune -a。命令敲下去確實(shí)爽回車之后騰出幾十個(gè) G然后第二天發(fā)現(xiàn)某個(gè)沒用latest之外的 tag 推上去的鏡像沒了某個(gè)只跑過一次的臨時(shí)容器依賴的卷也空了。所以我現(xiàn)在的習(xí)慣是任何清理動(dòng)作之前先花十分鐘把占用地圖畫出來誰大、誰在用、誰可以重建心里有數(shù)再動(dòng)手。1.1 用 du 從文件系統(tǒng)層面圈出體積大戶Docker 的所有落盤數(shù)據(jù)默認(rèn)都在/var/lib/docker下先在這一層做一次分層統(tǒng)計(jì)速度最快、信息也最直觀du -h --max-depth1 /var/lib/docker | sort -hr | head -20這條命令跑完基本能看出大頭在哪。常見的幾個(gè)子目錄含義如下目錄存放內(nèi)容能否直接刪overlay2/鏡像層與容器可寫層絕對(duì)不能手動(dòng)刪刪了元數(shù)據(jù)全亂containers/容器配置與*-json.log日志日志可截?cái)嗄夸洸豢蓜hvolumes/命名卷與匿名卷的真實(shí)數(shù)據(jù)需逐卷確認(rèn)可能是業(yè)務(wù)庫image/鏡像元數(shù)據(jù)層數(shù)據(jù)在 overlay2不可手動(dòng)刪buildkit/構(gòu)建緩存可以用 prune 清tmp/臨時(shí)導(dǎo)入導(dǎo)出文件可清如果containers/這一層大得離譜那十有八九是容器日志。繼續(xù)往下鉆du -h --max-depth1 /var/lib/docker/containers | sort -hr | head -10 find /var/lib/docker/containers -name *-json.log -size 200M -exec ls -lh {} \;第二條命令會(huì)直接把超過 200M 的日志文件列出來帶上容器 ID。到這里你就能對(duì)上號(hào)哪個(gè)容器在瘋狂打日志。我遇到過最夸張的一次一個(gè)容器因?yàn)檫B不上依賴服務(wù)在重試循環(huán)里每毫秒打一行錯(cuò)誤三天寫了 68G 的 json 日志而業(yè)務(wù)方完全不知道。1.2 docker system df 給出的是邏輯賬本文件系統(tǒng)層面看的是物理占用Docker 自己還有一套賬本兩者要對(duì)照著看docker system df -v不加-v只給四行匯總Images、Containers、Local Volumes、Build Cache。加了-v會(huì)展開到每個(gè)鏡像、每個(gè)容器、每個(gè)卷的SIZE和SHARED SIZE。這里有個(gè)概念必須先掰清楚否則很容易誤判SIZE是這個(gè)對(duì)象占的總空間SHARED SIZE是和別的對(duì)象共用的層UNIQUE SIZE才是它獨(dú)占的部分。因?yàn)殓R像分層復(fù)用的關(guān)系你把幾個(gè)鏡像的 SIZE 加起來得到的數(shù)字會(huì)遠(yuǎn)大于實(shí)際占用。判斷刪掉這個(gè)鏡像能省多少要看 UNIQUE SIZE不是 SIZE。同理docker ps -s里面容器的size是可寫層virtual size是它加上所有底層的總和虛得厲害別拿它當(dāng)清理依據(jù)。1.3 動(dòng)手前先劃出能刪和碰不得的紅線我的紅線清單是這樣的每次清理前在腦子里過一遍碰不得/var/lib/docker下的任何目錄都不用手工rm -rf。overlay2、image、containers 這些目錄里存的是軟鏈接和元數(shù)據(jù)刪一半等于把 Docker 的內(nèi)部數(shù)據(jù)庫撕了救不回來的概率很高。碰不得命名卷里如果是數(shù)據(jù)庫數(shù)據(jù)目錄刪卷等于刪庫。docker volume prune我先看docker volume ls -f danglingtrue的輸出確認(rèn)沒有業(yè)務(wù)卷混在里面?？梢詣?dòng)懸空鏡像danglingnone:none那種、停止很久的容器、構(gòu)建緩存、超過閾值的歷史日志。需要確認(rèn)不是懸空但也沒容器在用的鏡像。這類往往是你留作回滾備用的版本刪之前至少要docker image inspect看一眼創(chuàng)建時(shí)間。提示清理前把docker ps -a、docker image ls -a、docker volume ls三條命令的輸出重定向到文件里存一份命名帶上時(shí)間戳。真出事了至少知道丟了什么能照著清單重建。2. 分級(jí)清場從零風(fēng)險(xiǎn)的緩存到需要停機(jī)的鏡像瘦身空間大頭找到之后清理要按照風(fēng)險(xiǎn)從低到高的順序推進(jìn)。我一般分三層第一層完全無損隨便清第二層影響運(yùn)行中的日志和已停容器需要看一眼第三層涉及鏡像和卷必須逐個(gè)確認(rèn)。這個(gè)順序的好處是往往清完前兩層問題就解決了壓根不用冒險(xiǎn)動(dòng)第三層。2.1 第一層構(gòu)建緩存與懸空鏡像清了不影響任何運(yùn)行構(gòu)建緩存是純?cè)隽慨a(chǎn)物刪了最多下次 build 慢一點(diǎn)沒有任何運(yùn)行風(fēng)險(xiǎn)docker builder prune --filter until168h--filter until168h表示只清理 7 天前的緩存比全量docker builder prune -a溫和得多。如果你的構(gòu)建機(jī)是 CI 環(huán)境構(gòu)建頻繁這一條能穩(wěn)定回收幾十個(gè) G。懸空鏡像是指那些 TAG 被新構(gòu)建頂?shù)?、又沒有被任何容器引用的中間層docker image prune默認(rèn)行為就是只刪懸空鏡像。這里有個(gè)經(jīng)驗(yàn)先docker image prune -a --filter until720h之前一定先用 dry-run 思路看一遍。Docker 的 prune 沒有--dry-run我的替代做法是先列出來docker images -f danglingtrue docker images --filter beforeimage:tag順手提一個(gè)常被忽略的點(diǎn)docker container prune清理的是已停止的容器可寫層會(huì)一起釋放。但如果你之前docker stop了某個(gè)容器只是想臨時(shí)停一下prune會(huì)把它連元數(shù)據(jù)一起干掉docker start就回不來了。停超過一周沒動(dòng)的容器我才會(huì)清。2.2 第二層容器日志——那個(gè)最容易被忽視的隱形黑洞日志文件的清理有兩個(gè)層面的問題很多人卡在第一個(gè)為什么我rm了日志文件df -h顯示的空間沒變?cè)蚴?Linux 的文件引用計(jì)數(shù)機(jī)制。容器里的應(yīng)用進(jìn)程還持有這個(gè)文件的句柄你把目錄項(xiàng)刪了inode 仍然被進(jìn)程引用空間不會(huì)釋放直到進(jìn)程退出。所以正確做法是清空內(nèi)容而不是刪除文件truncate -s 0 /var/lib/docker/containers/容器ID/容器ID-json.logtruncate保留 inode只是把長度置零進(jìn)程繼續(xù)往同一個(gè)文件寫df立刻能看到空間回來。這也是為什么我說千萬不要用rm之后不管回頭du看不到這個(gè)文件df卻還是滿的會(huì)讓人懷疑人生。第二個(gè)層面是治本給后創(chuàng)建的容器加上日志上限從源頭卡住。編輯/etc/docker/daemon.json{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }改完執(zhí)行systemctl reload docker部分發(fā)行版需要restart。注意daemon.json里的日志配置只對(duì)之后新建的容器生效已經(jīng)在跑的容器不會(huì)自動(dòng)套用需要重建。這一點(diǎn)我在文檔里踩過坑配置改完以為萬事大吉結(jié)果老容器的日志照樣漲。另外max-size不要設(shè)得太小。50m 配合 3 個(gè)文件單個(gè)容器最多 150m對(duì)排查問題足夠了。設(shè)成 10m 會(huì)導(dǎo)致日志輪轉(zhuǎn)太頻繁真出問題的時(shí)候關(guān)鍵上下文已經(jīng)被覆蓋了。2.3 第三層鏡像與卷一條命令之差就是數(shù)據(jù)事故到了這一層每一條命令我都要先在別的終端確認(rèn)一遍docker system prune這條是相對(duì)安全的版本清的是已停止的容器、未被使用的網(wǎng)絡(luò)、懸空鏡像、懸空構(gòu)建緩存。加-a之后語義就變了會(huì)刪掉所有沒有被任何容器引用的鏡像包括你打好的 tag。加--volumes更狠會(huì)連卷一起處理。關(guān)于卷這里必須說清楚版本差異不同 Docker 版本對(duì)docker volume prune的默認(rèn)行為有過調(diào)整早期版本會(huì)把未使用的命名卷也算進(jìn)去較新版本默認(rèn)只處理匿名卷需要額外參數(shù)才碰命名卷。這種版本差異在緊急清理的時(shí)候最容易出事我的做法是永遠(yuǎn)不依賴默認(rèn)行為docker volume ls -f danglingtrue docker volume inspect 卷名先列出來逐個(gè)inspect看掛載點(diǎn)和創(chuàng)建時(shí)間確認(rèn)是臨時(shí)數(shù)據(jù)之后再用精確的docker volume rm 卷名一個(gè)個(gè)刪。慢是慢了點(diǎn)但不會(huì)出現(xiàn)清理完發(fā)現(xiàn)數(shù)據(jù)庫空了這種事。鏡像同理docker rmi比prune可控得多。刪除前先看引用docker ps -a --filter ancestor鏡像名:tag有輸出說明還有容器依賴它刪了會(huì)報(bào) conflict。這種情況下先處理容器別強(qiáng)行-f。3. 該留的一個(gè)都不能丟卷、鏡像與容器運(yùn)行時(shí)的備份方案清理之前先備份這是常識(shí)但 Docker 場景下的備份具體備什么、備到哪、怎么驗(yàn)證很多人的理解是模糊的。我見過有人以為docker commit出來的鏡像就包含了卷里的數(shù)據(jù)結(jié)果恢復(fù)的時(shí)候發(fā)現(xiàn)數(shù)據(jù)庫目錄是空的——因?yàn)榫淼臄?shù)據(jù)根本不在容器文件系統(tǒng)里。所以動(dòng)手前先把三類東西分開看。3.1 命名卷的冷備份容器停掉tar 打包校驗(yàn)結(jié)構(gòu)卷是唯一存放有狀態(tài)數(shù)據(jù)的地方數(shù)據(jù)庫、上傳文件、配置。備份的基本原則是先停容器再備份讓文件處于一致狀態(tài)。熱備份在文件正在被寫入的時(shí)候打 tar很容易拿到半截文件尤其是數(shù)據(jù)庫的 WAL、雙寫日志這類。完整流程如下# 1. 停掉使用該卷的容器 docker stop mysql-prod # 2. 用臨時(shí)容器把卷掛載出來打包 docker run --rm \ -v mysql-data:/data:ro \ -v /backup/docker:/backup \ alpine:3.19 \ tar -czf /backup/mysql-data-$(date %F).tar.gz -C /data . # 3. 啟動(dòng)容器 docker start mysql-prod幾個(gè)細(xì)節(jié)值得展開:ro只讀掛載防止打包過程中意外寫入-C /data .而不是-C /data *避免漏掉隱藏文件比如.my.cnf之類的點(diǎn)文件臨時(shí)容器用alpine體積小、啟動(dòng)快不要用業(yè)務(wù)鏡像免得帶進(jìn)額外依賴輸出目錄用宿主機(jī)綁定掛載不要輸出到卷里否則等于沒備份。備份產(chǎn)出之后一定要校驗(yàn)不能只看命令退出碼tar -tzf /backup/docker/mysql-data-2024-06-01.tar.gz | head -20 tar -tzf /backup/docker/mysql-data-2024-06-01.tar.gz | wc -l看一眼目錄結(jié)構(gòu)對(duì)不對(duì)、文件數(shù)量級(jí)合不合理。文件數(shù)量對(duì)不上說明源目錄少了東西。對(duì)于數(shù)據(jù)庫這類有自己備份工具的服務(wù)我更推薦做邏輯備份而非文件級(jí)拷貝。MySQL 用mysqldumpPostgreSQL 用pg_dump導(dǎo)出的 SQL 文件跨版本兼容性好恢復(fù)時(shí)也不會(huì)因?yàn)槲募到y(tǒng)差異出問題。文件級(jí) tar 備份適合配置目錄 上傳附件這類場景。3.2 鏡像與整機(jī)環(huán)境的導(dǎo)出save 與 export 不是一回事鏡像的備份用docker save它保留完整的層結(jié)構(gòu)和元數(shù)據(jù)CMD、ENTRYPOINT、ENV、健康檢查docker save -o /backup/docker/app-1.4.2.tar \ registry.local/app:1.4.2 \ registry.local/worker:1.4.2一次 save 多個(gè)鏡像有個(gè)隱藏收益共享層只存一份。分別 save 兩個(gè)基于同一個(gè)基礎(chǔ)鏡像的服務(wù)加起來可能是 1.8G合并成一條命令可能只有 1.1G。這個(gè)差異在鏡像數(shù)量多的時(shí)候非?？捎^。而docker export導(dǎo)出的是容器的文件系統(tǒng)快照丟失所有鏡像元數(shù)據(jù)環(huán)境變量、啟動(dòng)命令、數(shù)據(jù)卷聲明全都沒了導(dǎo)回去只能docker import成一個(gè)新鏡像還得手工補(bǔ) CMD。除非你在做鏡像取證或者特殊遷移否則不要用 export 做備份。還有一個(gè)容易混淆的點(diǎn)鏡像備份不包含卷數(shù)據(jù)。所以一套完整的恢復(fù)包應(yīng)該是鏡像 tar 卷 tar 一份記錄啟動(dòng)參數(shù)的文本。第三項(xiàng)特別重要我現(xiàn)在的做法是備份目錄里放一個(gè)run.sh把docker run的完整命令包括所有端口、環(huán)境變量、掛載寫在里面。半年后恢復(fù)的時(shí)候你絕對(duì)想不起來當(dāng)初那個(gè)容器是怎么起的。3.3 恢復(fù)演練把備份灌進(jìn)一個(gè)新卷驗(yàn)證能起來再收工備份不演練等于沒備份。我的習(xí)慣是每月抽一次把最新的卷備份恢復(fù)到一個(gè)臨時(shí)卷上驗(yàn)證目錄結(jié)構(gòu)和關(guān)鍵文件# 1. 建一個(gè)驗(yàn)證用的新卷 docker volume create verify-restore # 2. 把備份灌進(jìn)去 docker run --rm \ -v verify-restore:/data \ -v /backup/docker:/backup:ro \ alpine:3.19 \ sh -c cd /data tar -xzf /backup/mysql-data-2024-06-01.tar.gz # 3. 檢查內(nèi)容 docker run --rm -v verify-restore:/data alpine:3.19 \ sh -c ls -la /data du -sh /data # 4. 清理驗(yàn)證卷 docker volume rm verify-restore如果要把正式環(huán)境恢復(fù)到新卷上還有個(gè)順序問題先創(chuàng)建卷、再填數(shù)據(jù)、最后啟動(dòng)容器。如果順序反了容器啟動(dòng)時(shí)會(huì)因?yàn)槟夸浄强斩鴪?bào)錯(cuò)有些應(yīng)用比如某些版本的 MySQL遇到非空數(shù)據(jù)目錄會(huì)直接拒絕初始化?；謴?fù)鏡像則是docker load -i /backup/docker/app-1.4.2.tar docker image ls | grep appdocker load會(huì)自動(dòng)識(shí)別 gzip 壓縮過的 tar不用先解壓。恢復(fù)完之后用docker image inspect核對(duì)一下 Entrypoint 和 Env 是不是跟備份前一致這個(gè)檢查只要十秒鐘但能省掉后面半小時(shí)的排查。注意備份目錄本身也要有異地副本。我見過卷備份做得非常規(guī)范的團(tuán)隊(duì)所有 tar 都在同一個(gè)宿主機(jī)上的/backup目錄然后一次磁盤故障機(jī)器和備份一起沒了。4. Docker 的壓縮到底壓的是什么鏡像導(dǎo)出、構(gòu)建產(chǎn)物與存儲(chǔ)層壓縮這個(gè)詞在 Docker 語境下其實(shí)指向三個(gè)完全不同的東西經(jīng)常被混為一談一是鏡像導(dǎo)出成 tar 文件時(shí)的壓縮二是構(gòu)建輸出時(shí)的壓縮三是存儲(chǔ)驅(qū)動(dòng)層面的壓縮。這三者的適用場景、能省多少空間、怎么操作差別很大。分清楚了你才知道自己需要的到底是哪一種。4.1 docker save 接 gzip離線分發(fā)的標(biāo)準(zhǔn)鏈路最常用也最直接的壓縮場景是把鏡像傳給別人或者歸檔到對(duì)象存儲(chǔ)docker save app:1.4.2 | gzip -c app-1.4.2.tar.gz體積收益通常在 40% 到 70% 之間取決于鏡像內(nèi)容?；A(chǔ)鏡像里的大量二進(jìn)制文件壓縮率一般不錯(cuò)如果鏡像里塞了已經(jīng)壓縮過的資源jar、zip、打包好的前端產(chǎn)物壓縮率就有限。更進(jìn)一步用pigz做并行壓縮多核機(jī)器上速度能快好幾倍docker save app:1.4.2 | pigz -p $(nproc) app-1.4.2.tar.gz加載的時(shí)候不用手動(dòng)解壓Docker 自己認(rèn)得docker load -i app-1.4.2.tar.gz我實(shí)測過一個(gè) 2.3G 的鏡像docker save直出 tar 是 2.3Ggzip 之后 890Mpigz -9能壓到 850M 左右但耗時(shí)明顯更長。日常用默認(rèn)級(jí)別就夠了追求極限壓縮率的話再加參數(shù)。這里的經(jīng)驗(yàn)是gzip -1 到 -6 之間體積差距很小但耗時(shí)差距很大批量歸檔的時(shí)候別迷信-9。一個(gè)容易踩的坑docker save -o file.tar和管道寫法不要混用。有些人寫成docker save app:1.4.2 -o app.tar | gzip app.tar.gz結(jié)果得到的是一個(gè)空的 gz 文件因?yàn)?o已經(jīng)把輸出重定向到文件了管道上什么都沒流過去。要么用-o直出要么用管道二選一。4.2 buildx 的輸出壓縮與鏡像瘦身是兩碼事如果你用 BuildKit 構(gòu)建輸出階段本身就能控制壓縮算法和級(jí)別。比如導(dǎo)出一個(gè) OCI 格式的歸檔docker buildx build \ --output typeoci,destapp-oci.tar,compressionzstd,compression-level5 \ -t app:1.4.2 .或者推到鏡像倉庫時(shí)順帶壓docker buildx build \ --output typeregistry,compressionzstd,compression-level3 \ -t registry.local/app:1.4.2 --push .zstd 相比 gzip 在壓縮率和速度上都有優(yōu)勢(shì)尤其是解壓速度對(duì)拉取鏡像的體驗(yàn)改善明顯。前提是目標(biāo)環(huán)境的 Docker 版本足夠新、能識(shí)別 zstd 壓縮的層老版本會(huì)報(bào)錯(cuò)。做這種改動(dòng)前先確認(rèn)下游機(jī)器的版本別在灰度環(huán)境里試出來問題。但這里要分清的是輸出壓縮只影響傳輸和歸檔體積不影響鏡像在本地占用的空間。你把鏡像層從 gzip 換成 zstd本地docker system df看到的數(shù)字基本不變。真正減小本地占用的是鏡像瘦身屬于構(gòu)建階段的事手段完全不同多階段構(gòu)建把編譯工具鏈留在 builder 階段最終鏡像只帶運(yùn)行時(shí)同一個(gè)RUN里apt-get update和apt-get install以及清理緩存寫完避免緩存留在某個(gè)中間層優(yōu)先用精簡的基礎(chǔ)鏡像.dockerignore把node_modules、.git、日志目錄排除掉這條最容易被忽略但收益經(jīng)常是最大的。我見過一個(gè)前端鏡像因?yàn)闆]寫.dockerignore把本地的node_modules整個(gè) COPY 進(jìn)去了鏡像從 180M 漲到 1.2G壓縮之后還是 700M。加個(gè)忽略規(guī)則問題當(dāng)場解決。4.3 存儲(chǔ)驅(qū)動(dòng)的壓縮邊界overlay2 壓不了別抱幻想很多人會(huì)問能不能讓 Docker 把鏡像層壓縮著存省點(diǎn)磁盤用默認(rèn)的 overlay2 驅(qū)動(dòng)時(shí)答案是不能。overlay2 是在普通文件系統(tǒng)上做聯(lián)合掛載鏡像層就是一堆普通文件和目錄不存在塊級(jí)壓縮的余地。你看到的鏡像占 2G那就是實(shí)打?qū)嵉?2G疊加共享層之后。能提供存儲(chǔ)壓縮的是另一類驅(qū)動(dòng)zfs 和 btrfs它們支持在文件系統(tǒng)層面開啟透明壓縮。如果你把 Docker 的數(shù)據(jù)目錄放在一個(gè)啟用了壓縮的 zfs 數(shù)據(jù)集上鏡像數(shù)據(jù)寫入時(shí)會(huì)自動(dòng)壓縮讀的時(shí)候自動(dòng)解壓。配置大致是這樣zfs create -o compressionlz4 docker/data systemctl stop docker # 把現(xiàn)有數(shù)據(jù)遷過去后文會(huì)講遷移流程lz4是速度優(yōu)先的選擇對(duì)容器場景比較合適CPU 開銷小zstd壓縮率更高但更吃 CPU。要不要折騰這條路取決于你的實(shí)際瓶頸如果磁盤 IO 不是問題、只是空間緊張值得考慮如果機(jī)器本身 CPU 已經(jīng)很緊壓縮帶來的開銷可能得不償失。而且切換存儲(chǔ)驅(qū)動(dòng)是高風(fēng)險(xiǎn)操作現(xiàn)有鏡像和容器都得重建不能在線切。我在生產(chǎn)環(huán)境做過一次評(píng)估了兩周、停機(jī)窗口留了四小時(shí)最終數(shù)據(jù)遷移加驗(yàn)證用了接近三小時(shí)。所以對(duì)大多數(shù)場景清理 遷移到更大磁盤的性價(jià)比遠(yuǎn)高于換驅(qū)動(dòng)。5. 數(shù)據(jù)目錄整體搬家把 /var/lib/docker 遷到大容量磁盤清理只能解一時(shí)之困如果業(yè)務(wù)真的在長數(shù)據(jù)量遲早還會(huì)漲回來。這時(shí)候更徹底的辦法是把整個(gè)數(shù)據(jù)目錄搬到大盤上讓系統(tǒng)盤保持輕量。這件事本身不復(fù)雜但細(xì)節(jié)很多尤其是拷貝方式選錯(cuò)、SELinux 上下文沒處理、daemon 配置改完沒生效這幾個(gè)坑我都踩過。5.1 遷移前要評(píng)估的三件事空間、文件系統(tǒng)、停機(jī)窗口第一件是空間。目標(biāo)盤至少要有源目錄 1.2 倍的空閑留出拷貝過程中的臨時(shí)開銷。先量一下du -sh /var/lib/docker df -h /data第二件是文件系統(tǒng)。overlay2 對(duì)底層文件系統(tǒng)有要求XFS 需要ftype1較新的發(fā)行版默認(rèn)滿足ext4 一般沒問題。用xfs_info /data | grep ftype確認(rèn)一下如果ftype0overlay2 會(huì)拒絕啟動(dòng)這個(gè)錯(cuò)誤信息很晦澀提前查能省不少事。第三件是停機(jī)窗口。停止 Docker 服務(wù)期間所有容器都不可用必須提前和業(yè)務(wù)方對(duì)齊。如果有多臺(tái)機(jī)器建議先用一臺(tái)非核心機(jī)器完整走一遍流程。停服務(wù)的正確姿勢(shì)是把三個(gè)單元都停掉systemctl stop docker docker.socket containerd只停docker不頂用docker.socket會(huì)因?yàn)橛腥藞?zhí)行 docker 命令而被激活導(dǎo)致服務(wù)在你拷貝過程中被拉起來數(shù)據(jù)目錄一邊寫一邊拷拷出來的是不一致的。順手確認(rèn)一下當(dāng)前的數(shù)據(jù)目錄到底在哪有些機(jī)器之前被人改過docker info | grep -i docker root dir同時(shí)看一眼存儲(chǔ)驅(qū)動(dòng)docker info | grep -i storage driver這里有個(gè)新版本要注意的點(diǎn)較新的 Docker 在部分場景下使用 containerd 的鏡像存儲(chǔ)鏡像數(shù)據(jù)可能落在/var/lib/containerd而不是/var/lib/docker。如果你的docker info顯示存儲(chǔ)驅(qū)動(dòng)是 containerd 相關(guān)的類型遷移時(shí)要一并考慮那個(gè)目錄或者確認(rèn)它的實(shí)際占用不大、不需要搬。5.2 rsync 拷貝加>mkdir -p /data/docker rsync -aHAX --numeric-ids --infoprogress2 \ /var/lib/docker/ /data/docker/參數(shù)逐個(gè)解釋-a歸檔模式保留權(quán)限時(shí)間戳-H保留硬鏈接關(guān)鍵-A保留 ACL-X保留擴(kuò)展屬性--numeric-ids不做用戶映射避免容器內(nèi) UID 被改。如果開了 SELinux還要處理上下文否則 Docker 啟動(dòng)會(huì)各種權(quán)限拒絕chcon -R --reference/var/lib/docker /data/docker或者更穩(wěn)妥的方式是restorecon -Rv /data/docker前提是目錄策略已經(jīng)配好?？截愅瓿珊笞鲆淮尾町愋ｒ?yàn)再補(bǔ)一遍增量此時(shí)服務(wù)仍然停著理論上不會(huì)有新數(shù)據(jù)但校驗(yàn)一下更安心rsync -aHAX --numeric-ids --dry-run --itemize-changes \ /var/lib/docker/ /data/docker/ | head沒有輸出說明兩邊完全一致。接下來改配置。編輯/etc/docker/daemon.json{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }注意 JSON 語法最后一項(xiàng)后面不能有逗號(hào)很多人復(fù)制粘貼的時(shí)候帶了個(gè)尾逗號(hào)Docker 啟動(dòng)直接失敗。啟動(dòng)服務(wù)并驗(yàn)證systemctl daemon-reload systemctl start docker docker info | grep -i docker root dir輸出應(yīng)該是/data/docker。如果還是老路徑說明配置沒被讀到檢查文件位置和語法journalctl -u docker -n 50能看到解析錯(cuò)誤的具體行號(hào)。5.3 遷移后的驗(yàn)證清單與回滾路徑服務(wù)起來不等于遷移成功我一般會(huì)按這個(gè)清單過一遍驗(yàn)證項(xiàng)命令期望結(jié)果數(shù)據(jù)目錄docker info | grep Root Dir指向新路徑鏡像完整docker image ls數(shù)量與遷移前一致容器列表docker ps -a全部容器都在狀態(tài)未變卷完整docker volume ls卷名與遷移前一致容器可啟動(dòng)逐個(gè)docker start啟動(dòng)無報(bào)錯(cuò)新數(shù)據(jù)落盤docker run --rm alpine echo ok成功且新目錄體積增長空間釋放df -h系統(tǒng)盤使用率下降舊目錄一定要留著至少留一周。我一般的做法是先改名而不是刪除mv /var/lib/docker /var/lib/docker.bak確認(rèn)新環(huán)境穩(wěn)定運(yùn)行一段時(shí)間、業(yè)務(wù)無異常之后再rm -rf /var/lib/docker.bak。這一條看著保守但真的救過命有一次遷移后第三天發(fā)現(xiàn)某個(gè)容器的卷數(shù)據(jù)少了一部分追下去發(fā)現(xiàn)是拷貝時(shí)該容器其實(shí)還在寫停服務(wù)前有個(gè) systemd 單元把它拉起來了靠舊目錄把數(shù)據(jù)撈了回來?；貪L路徑也很簡單把daemon.json里的># /etc/cron.d/docker-gc 0 3 * * 0 root /usr/bin/docker builder prune -f --filter until168h /var/log/docker-gc.log 21 30 3 * * 0 root /usr/bin/docker image prune -f --filter until720h /var/log/docker-gc.log 21注意image prune這里只清懸空鏡像不加-a帶 tag 的鏡像不會(huì)被碰。--filter until720h再加一層保險(xiǎn)30 天內(nèi)的懸空鏡像也不動(dòng)萬一有正在排查的問題還能回看。日志進(jìn)/var/log/docker-gc.log是為了事后能查某天某個(gè)鏡像突然沒了翻日志能看到是被清理任務(wù)干掉的而不是懷疑存儲(chǔ)出問題。另外兩條約定俗成的規(guī)矩值得在團(tuán)隊(duì)里推一下鏡像 tag 不用latest固定版本號(hào)這樣prune時(shí)你清楚知道每個(gè) tag 對(duì)應(yīng)什么容器不長期docker run -d手工起用編排文件描述好處是所有掛載、端口、環(huán)境變量都有據(jù)可查重建的時(shí)候不會(huì)漏參數(shù)。6.2 給磁盤體積加一道監(jiān)控別等 93% 才被動(dòng)響應(yīng)清理和遷移都是事后補(bǔ)救監(jiān)控才是提前量。最基礎(chǔ)的是磁盤使用率告警這個(gè)大多數(shù)環(huán)境都有。但更有價(jià)值的是趨勢(shì)告警不是用了 90%才報(bào)而是三天內(nèi)漲了 20G就報(bào)。我常用的一個(gè)土辦法是每天定時(shí)采集一次關(guān)鍵目錄的體積寫到一個(gè) csv 里配合簡單的環(huán)比判斷#!/bin/bash STAMP$(date %F) SIZE$(du -sb /var/lib/docker | awk {print $1}) echo $STAMP,$SIZE /var/log/docker-size.csv跑上兩周就能看出正常增速是多少。某天突然翻倍說明有容器在異常寫盤或者有鏡像在批量堆積這時(shí)候介入成本最低。再進(jìn)一步docker system df的輸出也可以定期存檔看鏡像數(shù)量、卷數(shù)量的變化趨勢(shì)。我遇到過一個(gè)問題某個(gè) CI 任務(wù)每天構(gòu)建一個(gè)新 tag 但從來不清理鏡像數(shù)量三個(gè)月從 20 個(gè)漲到 900 多個(gè)每個(gè)都占著幾百 M 的獨(dú)占層加起來 200 多 G。這種緩慢增長靠單次告警是抓不到的只有看趨勢(shì)才能發(fā)現(xiàn)。最后分享一個(gè)我在實(shí)際維護(hù)中形成的小習(xí)慣每次執(zhí)行任何帶prune或rm的命令之前先把要?jiǎng)h的東西列出來看一眼。多花的那三十秒換來的是不用在下班前處理一個(gè)數(shù)據(jù)庫沒了的緊急電話。空間是省出來的但數(shù)據(jù)是靠謹(jǐn)慎保住的這兩件事在 Docker 這里從來不矛盾。