1. 為什么我勸你別再瞎寫 Dockerfile 了你有沒(méi)有過(guò)這種經(jīng)歷本地跑得好好的服務(wù)一打成鏡像就各種幺蛾子——構(gòu)建慢得像蝸牛、鏡像體積動(dòng)輒上 G、換個(gè)機(jī)器跑就報(bào)找不到依賴、改一行代碼要重新等十分鐘。我見過(guò)太多團(tuán)隊(duì)把 Dockerfile 當(dāng)成能跑就行的腳本隨手糊結(jié)果在 CI 流水線里天天翻車。Dockerfile 構(gòu)建鏡像這件事表面上是幾行指令的堆砌實(shí)際上是一套關(guān)于分層緩存、構(gòu)建上下文、運(yùn)行時(shí)最小化的系統(tǒng)性工程。寫得好構(gòu)建從十分鐘壓到一分鐘、鏡像從 1.2G 瘦到 80M寫得爛就是給自己埋雷。這篇內(nèi)容我想把 Dockerfile 從指令手冊(cè)的層面拉下來(lái)講清楚它背后的分層機(jī)制、緩存命中邏輯、多階段構(gòu)建的取舍以及那些文檔里不會(huì)寫、只有踩過(guò)坑才知道的細(xì)節(jié)。適合誰(shuí)看如果你已經(jīng)能寫出一個(gè)能跑的 Dockerfile但總覺(jué)得構(gòu)建慢、鏡像大、維護(hù)累那這篇就是給你準(zhǔn)備的。如果你是完全新手也沒(méi)關(guān)系我會(huì)把每個(gè)為什么都掰開講用生活化的類比帶你把底層邏輯吃透。核心關(guān)鍵詞就一個(gè)Dockerfile 構(gòu)建鏡像圍繞它我們把構(gòu)建效率、鏡像體積、可維護(hù)性這三條主線全部走一遍。先說(shuō)結(jié)論性的判斷一個(gè)合格的 Dockerfile應(yīng)該滿足三個(gè)標(biāo)準(zhǔn)——構(gòu)建可復(fù)現(xiàn)、緩存能命中、產(chǎn)物足夠小。后面所有的技巧、參數(shù)、取舍都是為這三條服務(wù)的。你帶著這個(gè)尺子去讀會(huì)發(fā)現(xiàn)很多最佳實(shí)踐其實(shí)都是在權(quán)衡而不是絕對(duì)的對(duì)錯(cuò)。2. 先搞懂分層與緩存不然寫啥都是蒙2.1 鏡像不是一坨而是一摞千層餅很多人對(duì)鏡像的理解是一個(gè)打包好的文件系統(tǒng)這個(gè)理解不算錯(cuò)但漏掉了最關(guān)鍵的一點(diǎn)鏡像是由一層層的只讀層疊加而成的。你可以把它想象成一摞透明膠片每張膠片上畫了一部分內(nèi)容疊在一起才是完整的畫面。Dockerfile 里的每一條指令除了少數(shù)元數(shù)據(jù)指令基本上都會(huì)產(chǎn)生一個(gè)新層。這個(gè)機(jī)制帶來(lái)兩個(gè)直接后果。第一層是只讀的容器啟動(dòng)時(shí)會(huì)在最上面加一個(gè)可寫層所有運(yùn)行時(shí)修改都發(fā)生在可寫層刪掉容器可寫層就沒(méi)了底層鏡像紋絲不動(dòng)。第二層可以被復(fù)用如果兩個(gè)鏡像共享前面的若干層這些層在磁盤上只存一份。這就是為什么你拉一個(gè)基于同一個(gè)基礎(chǔ)鏡像的服務(wù)往往只下載幾十兆而不是幾百兆——公共層已經(jīng)在了。理解這一點(diǎn)你才能明白為什么指令順序如此重要。因?yàn)榫彺娴钠ヅ涫菑纳贤轮饘颖葘?duì)的一旦某一層變了它后面的所有層緩存全部失效。這就像多米諾骨牌你推倒中間一張后面的全倒。2.2 緩存命中構(gòu)建速度的命門我見過(guò)最典型的翻車寫法是這樣的FROM node:20 WORKDIR /app COPY . . RUN npm install CMD [node, server.js]這段代碼邏輯上沒(méi)毛病但它有個(gè)致命問(wèn)題COPY . .把整個(gè)項(xiàng)目目錄包括源碼復(fù)制進(jìn)去只要你改了任何一行源碼這一層就變了后面的npm install緩存直接失效每次構(gòu)建都要重新裝一遍依賴。一個(gè)中型前端項(xiàng)目npm install動(dòng)輒兩三分鐘一天構(gòu)建幾十次時(shí)間全耗在這上面了。正確的做法是把變化頻率低的東西放前面變化頻率高的東西放后面FROM node:20 WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . CMD [node, server.js]先只復(fù)制依賴清單裝完依賴再?gòu)?fù)制源碼。這樣改源碼時(shí)npm ci那一層緩存穩(wěn)穩(wěn)命中構(gòu)建時(shí)間從幾分鐘降到幾秒。這個(gè)技巧的本質(zhì)就是按變化頻率給指令排序——依賴清單變得少放前面源碼變得多放后面。注意COPY的緩存判斷是基于文件內(nèi)容的校驗(yàn)和不是基于修改時(shí)間。所以哪怕你touch一下文件但內(nèi)容沒(méi)變緩存依然命中反過(guò)來(lái)內(nèi)容變了哪怕時(shí)間沒(méi)變緩存也會(huì)失效。這個(gè)細(xì)節(jié)很多人搞反了。2.3 構(gòu)建上下文那個(gè)你沒(méi)注意的隱形搬運(yùn)工docker build .后面那個(gè)點(diǎn)就是構(gòu)建上下文。Docker 客戶端會(huì)把這個(gè)目錄下的所有文件打包發(fā)給守護(hù)進(jìn)程或者構(gòu)建器。注意是所有文件包括你的.git目錄、node_modules、日志、臨時(shí)文件。我見過(guò)有人在一個(gè)幾十 G 的目錄里執(zhí)行構(gòu)建光傳輸上下文就等了好幾分鐘還納悶為什么這么慢。解決辦法是.dockerignore文件語(yǔ)法跟.gitignore類似.git node_modules *.log dist .env這個(gè)文件的價(jià)值不只是快還有安全——避免把.env、密鑰文件、本地配置誤打進(jìn)鏡像。我踩過(guò)一次坑某次調(diào)試時(shí)把帶數(shù)據(jù)庫(kù)密碼的.env打進(jìn)了鏡像雖然只是內(nèi)部測(cè)試環(huán)境但事后想想后背發(fā)涼。從那以后.dockerignore成了我每個(gè)項(xiàng)目的標(biāo)配而且我會(huì)刻意把敏感文件名寫進(jìn)去哪怕當(dāng)前沒(méi)有。2.4 指令選擇背后的取舍邏輯Dockerfile 的指令不多但每條都有講究。我挑幾個(gè)最容易用錯(cuò)的說(shuō)說(shuō)。RUN、CMD、ENTRYPOINT這三個(gè)經(jīng)常被混淆。簡(jiǎn)單記RUN是構(gòu)建時(shí)執(zhí)行CMD和ENTRYPOINT是運(yùn)行時(shí)執(zhí)行。RUN的結(jié)果會(huì)被固化進(jìn)鏡像層CMD/ENTRYPOINT只是記錄容器啟動(dòng)時(shí)該跑什么。CMD可以被docker run后面的命令覆蓋ENTRYPOINT不會(huì)除非用--entrypoint。所以做基礎(chǔ)工具鏡像用ENTRYPOINT做通用服務(wù)鏡像用CMD更靈活。COPY和ADD的區(qū)別也常被問(wèn)。ADD多了兩個(gè)功能自動(dòng)解壓 tar 包、支持 URL 下載。聽起來(lái)很美好但官方現(xiàn)在推薦優(yōu)先用COPY因?yàn)锳DD的隱式行為容易讓人困惑——你以為只是復(fù)制結(jié)果它偷偷解壓了。需要解壓就顯式用RUN tar -xf需要下載就顯式用RUN curl行為透明排查問(wèn)題時(shí)不會(huì)抓瞎。RUN里還有個(gè)經(jīng)典技巧合并命令減少層數(shù)。比如RUN apt-get update apt-get install -y \ curl \ git \ rm -rf /var/lib/apt/lists/*這里三個(gè)動(dòng)作合成一條RUN只產(chǎn)生一層。如果拆成三條RUN會(huì)產(chǎn)生三層而且apt-get update和install分開寫還有個(gè)隱患——緩存可能導(dǎo)致 update 用的是舊索引install 裝到舊版本甚至失敗。合并成一條同時(shí)清理 apt 緩存既減層又減體積。那個(gè)rm -rf /var/lib/apt/lists/*很關(guān)鍵apt 的包索引動(dòng)輒幾十兆不清理就白白留在鏡像里。3. 多階段構(gòu)建把構(gòu)建環(huán)境和運(yùn)行環(huán)境徹底分開3.1 為什么你的鏡像總是那么大一個(gè) Go 服務(wù)編譯出來(lái)二進(jìn)制可能就 20M但如果你用golang:1.22作為基礎(chǔ)鏡像最終鏡像輕松上 800M 甚至 1G。為什么因?yàn)闃?gòu)建鏡像里塞滿了編譯器、標(biāo)準(zhǔn)庫(kù)源碼、各種工具鏈而運(yùn)行時(shí)根本用不到這些。同理前端項(xiàng)目構(gòu)建完只剩靜態(tài)文件但node_modules和構(gòu)建工具全留在鏡像里。這就是多階段構(gòu)建要解決的問(wèn)題用一個(gè)大而全的鏡像做構(gòu)建車間只把產(chǎn)物搬到一個(gè)小而精的運(yùn)行環(huán)境里。類比一下就像你在工廠里用各種大型機(jī)床加工零件但最終交付給客戶的只是那個(gè)零件不是整條生產(chǎn)線。3.2 一個(gè) Go 服務(wù)的多階段實(shí)戰(zhàn)# 階段一構(gòu)建 FROM golang:1.22-alpine AS builder WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -ldflags-s -w -o /out/app ./cmd/server # 階段二運(yùn)行 FROM alpine:3.19 RUN apk add --no-cache ca-certificates tzdata WORKDIR /app COPY --frombuilder /out/app ./app EXPOSE 8080 ENTRYPOINT [./app]這里有幾個(gè)關(guān)鍵點(diǎn)值得展開。AS builder給階段命名后面用COPY --frombuilder精確搬運(yùn)產(chǎn)物。CGO_ENABLED0關(guān)掉 CGO編譯出靜態(tài)鏈接的二進(jìn)制這樣運(yùn)行階段就不需要 glibc可以用極小的 alpine 甚至 scratch。-ldflags-s -w去掉符號(hào)表和調(diào)試信息二進(jìn)制能再小 20%~30%。運(yùn)行階段我特意裝了ca-certificates和tzdata。這兩個(gè)是新手最容易漏的——不裝 CA 證書服務(wù)里發(fā) HTTPS 請(qǐng)求會(huì)報(bào)證書驗(yàn)證失敗不裝時(shí)區(qū)數(shù)據(jù)time.LoadLocation(Asia/Shanghai)會(huì)直接 panic。這兩個(gè)坑我都踩過(guò)而且報(bào)錯(cuò)信息往往很隱晦排查半天才發(fā)現(xiàn)是基礎(chǔ)鏡像太干凈。最終鏡像從 800M 降到 15M 左右效果立竿見影。3.3 前端項(xiàng)目的多階段套路前端更典型因?yàn)閚ode_modules是體積大戶FROM node:20-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build FROM nginx:1.25-alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80構(gòu)建階段用 node 裝依賴、跑打包運(yùn)行階段只把dist目錄拷進(jìn) nginx。最終鏡像就是 nginx 基礎(chǔ)鏡像加上幾十兆靜態(tài)文件干凈利落。這里npm ci比npm install更合適——它嚴(yán)格按 lock 文件安裝保證可復(fù)現(xiàn)而且速度更快。3.4 多階段的進(jìn)階玩法并行與復(fù)用多階段構(gòu)建還有個(gè)不太為人知的用法一個(gè) Dockerfile 里可以有多個(gè)構(gòu)建階段且階段之間可以互相引用。比如你可以有一個(gè)deps階段專門裝依賴一個(gè)builder階段基于deps編譯一個(gè)test階段基于builder跑測(cè)試最后runtime階段只拿產(chǎn)物。用--target參數(shù)可以只構(gòu)建到某個(gè)階段docker build --target builder -t myapp:builder .這在 CI 里特別有用——測(cè)試流水線只構(gòu)建到test階段發(fā)布流水線構(gòu)建到runtime階段共享前面的緩存。我現(xiàn)在的項(xiàng)目基本都這么組織一個(gè) Dockerfile 覆蓋開發(fā)、測(cè)試、生產(chǎn)三種用途維護(hù)成本低很多。提示多階段構(gòu)建的中間階段默認(rèn)不會(huì)出現(xiàn)在最終鏡像里但如果你用--target指定了中間階段那個(gè)階段的所有層都會(huì)保留。所以別在中間階段里塞敏感信息哪怕它理論上不會(huì)進(jìn)最終鏡像。4. 從零到一一個(gè)生產(chǎn)級(jí) Dockerfile 的完整落地4.1 基礎(chǔ)鏡像怎么選不是越小越好選基礎(chǔ)鏡像是個(gè)權(quán)衡題。alpine小5M 左右但用的是 musl libc 而不是 glibc某些預(yù)編譯二進(jìn)制跑不起來(lái)debian-slim稍大80M 左右但兼容性好scratch是空鏡像只有靜態(tài)二進(jìn)制能跑連 shell 都沒(méi)有調(diào)試基本靠猜。我的經(jīng)驗(yàn)是Go/Rust 這類能靜態(tài)編譯的用scratch或alpineJava/Python/Node 這類依賴運(yùn)行時(shí)的用-slim或alpine版本但要先驗(yàn)證依賴兼容性。曾經(jīng)有個(gè)項(xiàng)目用 alpine 跑一個(gè)依賴 glibc 的 Python 包裝了半天裝不上最后換python:3.12-slim才解決。所以別迷信越小越好先跑通再優(yōu)化。還有個(gè)細(xì)節(jié)基礎(chǔ)鏡像要固定版本別用latest。FROM node:latest今天構(gòu)建和明天構(gòu)建可能拿到不同版本構(gòu)建不可復(fù)現(xiàn)出了問(wèn)題都找不到原因。我一般固定到小版本比如node:20.11-alpine3.19既穩(wěn)定又能拿到安全更新。4.2 用戶與權(quán)限別用 root 跑服務(wù)默認(rèn)情況下容器里是 root 用戶這在生產(chǎn)環(huán)境是個(gè)隱患——一旦服務(wù)被攻破攻擊者拿到的就是容器內(nèi)的 root 權(quán)限。正確做法是創(chuàng)建非 root 用戶FROM node:20-alpine RUN addgroup -S app adduser -S app -G app WORKDIR /app COPY --chownapp:app . . USER app CMD [node, server.js]--chownapp:app保證復(fù)制進(jìn)去的文件屬主正確否則USER app之后可能沒(méi)權(quán)限讀寫。這個(gè)細(xì)節(jié)很容易漏漏了就是運(yùn)行時(shí)各種 permission denied。另外注意USER指令之后的所有RUN都以該用戶執(zhí)行所以需要 root 權(quán)限的操作比如裝系統(tǒng)包必須放在USER之前。4.3 環(huán)境變量與構(gòu)建參數(shù)分清 ARG 和 ENVARG是構(gòu)建時(shí)參數(shù)ENV是運(yùn)行時(shí)環(huán)境變量?jī)烧呓?jīng)常被混用。ARG只在構(gòu)建階段有效構(gòu)建完就沒(méi)了ENV會(huì)寫進(jìn)鏡像容器運(yùn)行時(shí)還在。所以構(gòu)建時(shí)需要但運(yùn)行時(shí)不需要的比如 npm 源地址、編譯選項(xiàng)用ARG運(yùn)行時(shí)需要的配置比如NODE_ENV、PORT用ENV。ARG NPM_REGISTRYhttps://registry.npmjs.org RUN npm config set registry $NPM_REGISTRY npm ci ENV NODE_ENVproduction ENV PORT8080注意ARG的值會(huì)出現(xiàn)在構(gòu)建歷史里docker history能看到所以絕對(duì)不要用ARG傳密鑰。密鑰應(yīng)該通過(guò)構(gòu)建時(shí)的 secret 掛載或者運(yùn)行時(shí)注入別圖省事寫進(jìn) Dockerfile。4.4 健康檢查與信號(hào)處理HEALTHCHECK指令很多人不用但它對(duì)編排系統(tǒng)很有價(jià)值HEALTHCHECK --interval30s --timeout3s --start-period10s --retries3 \ CMD wget -qO- http://localhost:8080/health || exit 1start-period給應(yīng)用啟動(dòng)留緩沖避免剛啟動(dòng)就被判定不健康。--retries3表示連續(xù)失敗三次才標(biāo)記 unhealthy。這些參數(shù)要根據(jù)應(yīng)用實(shí)際啟動(dòng)時(shí)間調(diào)調(diào)太緊會(huì)誤殺調(diào)太松故障發(fā)現(xiàn)慢。信號(hào)處理也是個(gè)坑。容器里 PID 1 的進(jìn)程如果沒(méi)正確處理SIGTERMdocker stop會(huì)等超時(shí)然后SIGKILL強(qiáng)殺導(dǎo)致優(yōu)雅關(guān)閉邏輯失效。用CMD [node, server.js]這種 exec 形式JSON 數(shù)組能讓 node 直接成為 PID 1 接收信號(hào)如果用 shell 形式CMD node server.js實(shí)際 PID 1 是 shell信號(hào)傳不到 node。這個(gè)區(qū)別在需要優(yōu)雅關(guān)閉的服務(wù)里是致命的。4.5 完整示例與構(gòu)建驗(yàn)證把上面的點(diǎn)串起來(lái)一個(gè)生產(chǎn)級(jí)的 Node 服務(wù) Dockerfile 大概長(zhǎng)這樣FROM node:20.11-alpine3.19 AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build npm prune --omitdev FROM node:20.11-alpine3.19 RUN addgroup -S app adduser -S app -G app WORKDIR /app COPY --frombuilder --chownapp:app /app/node_modules ./node_modules COPY --frombuilder --chownapp:app /app/dist ./dist COPY --chownapp:app package.json ./ ENV NODE_ENVproduction USER app EXPOSE 8080 HEALTHCHECK --interval30s --timeout3s --start-period10s --retries3 \ CMD wget -qO- http://localhost:8080/health || exit 1 CMD [node, dist/server.js]構(gòu)建完用docker images看體積用docker history看每層大小找出體積大戶。我一般會(huì)跑一遍docker history --no-trunc --format {{.Size}}\t{{.CreatedBy}}按大小排序哪層大就優(yōu)化哪層。這個(gè)習(xí)慣幫我發(fā)現(xiàn)過(guò)好幾次忘了清理緩存的問(wèn)題。5. 踩坑實(shí)錄那些文檔不會(huì)告訴你的問(wèn)題5.1 構(gòu)建慢的排查路徑構(gòu)建慢先別急著換機(jī)器按這個(gè)順序排查上下文大小 → 緩存命中 → 層數(shù) → 網(wǎng)絡(luò)。先看docker build輸出里 Sending build context 那行如果幾百兆先寫.dockerignore。然后看每步是CACHED還是重新執(zhí)行找出緩存斷點(diǎn)。再數(shù)層數(shù)能合并的RUN合并。最后才是網(wǎng)絡(luò)問(wèn)題比如拉基礎(chǔ)鏡像慢、裝依賴慢這時(shí)候考慮配鏡像源或者用構(gòu)建緩存。我遇到過(guò)一個(gè)詭異情況明明.dockerignore寫了node_modules構(gòu)建還是慢。查了半天發(fā)現(xiàn)是.dockerignore文件放在了子目錄而構(gòu)建上下文是父目錄根本沒(méi)生效。這個(gè)坑很隱蔽記住.dockerignore必須和構(gòu)建上下文根目錄同級(jí)。5.2 鏡像體積異常的定位鏡像比預(yù)期大常見原因就那么幾個(gè)沒(méi)清理包管理器緩存、把構(gòu)建工具打進(jìn)了運(yùn)行鏡像、COPY . .把無(wú)關(guān)文件帶進(jìn)去了、多層疊加沒(méi)合并。用docker history逐層看基本能定位。還有個(gè)工具叫dive能交互式查看每層新增了哪些文件排查體積問(wèn)題特別好用。有個(gè)反直覺(jué)的點(diǎn)刪除文件不一定能減小鏡像。因?yàn)殓R像分層是只讀的你在后面的層rm一個(gè)文件只是在上層標(biāo)記刪除底層那個(gè)文件還在體積照算。所以清理動(dòng)作必須和產(chǎn)生文件的動(dòng)作放在同一個(gè)RUN里比如apt-get install rm -rf /var/lib/apt/lists/*這樣文件根本沒(méi)進(jìn)層。5.3 常見問(wèn)題速查表現(xiàn)象可能原因排查方向構(gòu)建極慢卡在 Sending context上下文過(guò)大檢查.dockerignore是否生效改一行代碼就重裝依賴指令順序錯(cuò)誤依賴清單先 COPY源碼后 COPY鏡像體積遠(yuǎn)超預(yù)期緩存未清理/工具鏈殘留docker history逐層看用多階段容器啟動(dòng)報(bào)找不到命令基礎(chǔ)鏡像缺工具換-slim或補(bǔ)裝依賴HTTPS 請(qǐng)求證書錯(cuò)誤缺 CA 證書裝ca-certificates時(shí)區(qū)相關(guān)代碼 panic缺時(shí)區(qū)數(shù)據(jù)裝tzdatadocker stop等很久才停信號(hào)未正確處理用 exec 形式 CMD非 root 用戶權(quán)限不足文件屬主不對(duì)COPY --chown5.4 幾個(gè)我踩過(guò)的獨(dú)家坑第一個(gè)alpine 的wget和curl行為差異。alpine 自帶 busybox 的wget功能比 GNU wget 少很多某些參數(shù)不支持。有次健康檢查用wget --spider一直失敗換成wget -qO-才好。所以健康檢查命令要在目標(biāo)鏡像里實(shí)測(cè)別想當(dāng)然。第二個(gè)COPY通配符的坑。COPY package*.json ./看起來(lái)沒(méi)問(wèn)題但如果目錄里沒(méi)有匹配文件構(gòu)建會(huì)直接報(bào)錯(cuò)。而COPY . .至少不會(huì)因?yàn)閱蝹€(gè)文件缺失失敗。所以用通配符要確保至少有一個(gè)匹配或者用COPY package.json package-lock.json ./顯式列出。第三個(gè)構(gòu)建緩存和latest標(biāo)簽的交互。如果你FROM node:latest本地有緩存時(shí)不會(huì)去拉新版本可能一直用著舊的基礎(chǔ)鏡像安全更新拿不到。定期docker build --pull強(qiáng)制拉新或者干脆固定版本號(hào)省心。6. 構(gòu)建效率的進(jìn)階優(yōu)化思路6.1 BuildKit默認(rèn)就該開的構(gòu)建引擎新版 Docker 默認(rèn)用 BuildKit 了但如果你還在老版本或者手動(dòng)關(guān)了強(qiáng)烈建議開起來(lái)。BuildKit 帶來(lái)的提升是實(shí)打?qū)嵉牟⑿袠?gòu)建獨(dú)立階段、更好的緩存復(fù)用、支持--mounttypecache緩存包管理器目錄。那個(gè) cache mount 特別香RUN --mounttypecache,target/root/.npm \ npm ci這樣 npm 的緩存目錄跨構(gòu)建保留即使package-lock.json變了下載過(guò)的包也不用重新下。Go 的模塊緩存、pip 的緩存同理。這個(gè)技巧能把依賴安裝時(shí)間再砍一半尤其適合 CI 環(huán)境。6.2 緩存策略與 CI 集成CI 里構(gòu)建鏡像緩存怎么持久化是個(gè)問(wèn)題。常見做法是把構(gòu)建緩存導(dǎo)出成文件下次構(gòu)建再導(dǎo)入docker build --cache-from myapp:cache --cache-to typelocal,dest/tmp/cache .或者用 registry 作為緩存后端把緩存層推到鏡像倉(cāng)庫(kù)。具體用哪種看你的 CI 環(huán)境支持核心思路是讓緩存跨流水線存活否則每次 CI 都是冷啟動(dòng)多階段構(gòu)建的優(yōu)勢(shì)發(fā)揮不出來(lái)。6.3 什么時(shí)候該停止優(yōu)化優(yōu)化是有邊際遞減的。一個(gè)鏡像從 1G 優(yōu)化到 100M收益巨大從 100M 優(yōu)化到 90M可能花的時(shí)間比省下的存儲(chǔ)值錢得多。我的判斷標(biāo)準(zhǔn)是構(gòu)建時(shí)間控制在 3 分鐘內(nèi)、鏡像體積在合理范圍比如 200M 以內(nèi)、緩存命中率穩(wěn)定就差不多了。剩下的精力應(yīng)該花在業(yè)務(wù)上而不是無(wú)止境地?fù)改菐渍?。還有個(gè)現(xiàn)實(shí)考量過(guò)度優(yōu)化會(huì)讓 Dockerfile 變得難讀難維護(hù)。我見過(guò)為了減層把所有命令塞進(jìn)一個(gè)巨型RUN的寫法幾百行 shell 擠在一起改一個(gè)包版本要小心翼翼。這種優(yōu)化其實(shí)是負(fù)債?？勺x性和性能之間要平衡我的底線是每個(gè)RUN只做一件邏輯上完整的事比如裝系統(tǒng)依賴并清理算一件裝依賴和編譯分開。7. 我個(gè)人的幾條硬經(jīng)驗(yàn)寫 Dockerfile 這些年有幾條經(jīng)驗(yàn)是我反復(fù)驗(yàn)證、幾乎每個(gè)項(xiàng)目都會(huì)用上的。第一條先讓它跑通再讓它變小最后讓它變快。別一上來(lái)就追求極致先保證功能正確再逐步優(yōu)化否則容易在細(xì)節(jié)里迷失。第二條每個(gè)RUN都問(wèn)自己這層能不能更小養(yǎng)成清理緩存的肌肉記憶。第三條基礎(chǔ)鏡像版本固定依賴清單單獨(dú) COPY源碼最后 COPY這三條能解決 80% 的構(gòu)建慢問(wèn)題。最后分享一個(gè)我最近才用上的小技巧在 Dockerfile 頂部加一行注釋寫清楚這個(gè)鏡像的用途、構(gòu)建命令、以及為什么這么寫的關(guān)鍵決策。半年后回頭看或者交接給同事時(shí)這行注釋能省下大量溝通成本。比如# 用途訂單服務(wù)生產(chǎn)鏡像 # 構(gòu)建docker build -t order-svc:v1.2.0 . # 說(shuō)明多階段構(gòu)建運(yùn)行階段用 alpine 減小體積依賴清單單獨(dú) COPY 以命中緩存這東西不占地方但價(jià)值極高。我現(xiàn)在的習(xí)慣是凡是做了反直覺(jué)優(yōu)化的地方都在旁邊寫一句為什么避免后人好心改回去又踩一遍坑。