一文弄懂docker的緩存機制

更新時間：2024年06月23日 09:19:18 作者：Cherry Xie

Docker的緩存機制是指當你構建鏡像時,Docker會盡可能重用之前步驟的輸出,本文主要介紹了一文弄懂docker的緩存機制,具有一定的參考價值,感興趣的可以了解一下

docker的緩存機制

鏡像層緩存(Image Layer Cache)

Docker 鏡像是分層構建的,每一個 Dockerfile 指令都會生成一個新的鏡像層。
Docker 會緩存每一個鏡像層,當構建新的鏡像時,如果檢測到某個層之前已經(jīng)構建過,就會直接復用該層,而不需要重新構建。

FROM ubuntu:18.04
RUN apt-get update
RUN apt-get install -y nginx
COPY app/ /var/www/html/
CMD ["nginx", "-g", "daemon off;"]

在上面的 Dockerfile 中, 前兩個 RUN 指令對應的鏡像層會被緩存。當再次構建鏡像時,如果這兩個層沒有變化,Docker 就會直接復用緩存,而不需要重新執(zhí)行這兩條命令,大大加快了構建速度。

容器層緩存(Container Layer Cache)

每個容器都有自己的可寫容器層,位于鏡像層之上,用于存儲容器的動態(tài)數(shù)據(jù)。
Docker 也會緩存容器層,當重新啟動容器時,Docker 會復用之前的容器層,避免重新創(chuàng)建。

# 創(chuàng)建并啟動容器
docker run -d --name my-app my-app:v1

# 停止并重啟容器
docker stop my-app
docker start my-app

在上面的示例中,當我們停止并重啟容器時,Docker 會復用之前的容器層,避免了重新創(chuàng)建容器的開銷,使容器啟動速度更快。

構建緩存(Build Cache)

Docker 還提供了一個專門的構建緩存機制,可以進一步優(yōu)化鏡像構建過程。
構建緩存會將之前構建過程中用到的中間層緩存起來,下次構建時如果檢測到相同的指令,就會復用這些緩存層。
用戶可以通過設置 --cache-from 參數(shù)來指定需要復用的緩存層。

# 構建鏡像時啟用構建緩存
docker build --cache-from my-app:v1 -t my-app:v2 .

在上面的示例中,我們指定了 --cache-from my-app:v1 參數(shù),告訴 Docker 復用之前構建 my-app:v1 時使用的緩存層,這樣可以進一步加快構建速度。

Registry 緩存

Docker Registry 也提供了緩存機制,可以緩存之前拉取的鏡像層,下次拉取時直接從緩存中獲取,提高拉取速度。
這種緩存機制對于分布式環(huán)境下的鏡像分發(fā)非常有用,可以減輕 Registry 服務器的壓力。

綜上所述,Docker 的緩存機制涵蓋了鏡像層、容器層、構建過程以及 Registry 等多個方面,充分利用緩存可以大幅提升 Docker 的性能和效率。如果您還有其他問題,歡迎繼續(xù)提出

docker的幾種寫法

指令順序優(yōu)化

Dockerfile 中指令的順序非常重要,因為 Docker 是根據(jù)指令順序來構建鏡像層的。
通常將較穩(wěn)定不變的指令放在前面,易變的指令放在后面,這樣可以最大限度地利用緩存。

例如:

# 不好的寫法
RUN apt-get update
COPY . /app
RUN pip install -r requirements.txt

# 更好的寫法  
FROM python:3.9
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

在第二個例子中,我們先復制 requirements.txt 并安裝依賴包,這部分內(nèi)容相對穩(wěn)定,可以很好地利用緩存。而后面的 COPY . . 指令是最易變的,放在最后可以最大化利用緩存。

分層構建

充分利用 Docker 的分層特性,把 Dockerfile 拆分成多個階段,每個階段構建一部分功能。
這樣可以確保穩(wěn)定的基礎層能夠最大化利用緩存,而變更的部分只需重新構建對應層即可。

例如:

# 基礎層
FROM ubuntu:18.04
RUN apt-get update && apt-get install -y nodejs npm

# 應用層  
FROM base-image
COPY . /app
WORKDIR /app
RUN npm install
CMD ["node", "server.js"]

在這個例子中,我們將 Dockerfile 劃分為兩個階段:基礎層和應用層?；A層負責安裝 Node.js 環(huán)境,這部分內(nèi)容相對穩(wěn)定,可以很好地利用緩存。應用層則負責復制源代碼并安裝依賴,這部分內(nèi)容更容易變更。

多階段構建

Docker 17.05 版本引入了多階段構建的功能,可以進一步優(yōu)化鏡像大小和構建過程。
通過在 Dockerfile 中定義多個 FROM 指令,可以實現(xiàn)將構建過程拆分為多個獨立的階段。

例如:

# 構建階段
FROM golang:1.16 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 運行階段 
FROM alpine:latest
COPY --from=builder /app/myapp /myapp
CMD ["/myapp"]

在這個例子中,我們先在 builder 階段編譯 Go 代碼,然后在 runtime 階段只復制編譯好的二進制文件到最終鏡像中。這種方式可以大幅減小最終鏡像的體積,同時也能很好地利用緩存。

關于docker的builder階段

在多階段構建的場景中,即使在 builder 階段復制了源代碼,最終也只會把編譯好的二進制文件復制到運行時容器中。這是因為 COPY --from=builder 指令會選擇性地復制指定階段的文件。

讓我們更詳細地解釋一下:

在 builder 階段,我們將源代碼復制到工作目錄并執(zhí)行編譯命令go build。此時,容器中包含了源代碼和編譯好的二進制文件。
在 runtime 階段,我們使用 COPY --from=builder 指令從 builder 階段復制二進制文件 /app/myapp 到當前容器的 /myapp 路徑。
這樣做的好處是:
1、只將最終需要的二進制文件復制到運行時容器中,大大減小了鏡像大小。
2、builder 階段的源代碼和編譯過程不會被帶入到最終鏡像中,從而避免了不必要的信息泄露。

在多階段構建中,builder 階段的源代碼確實會被保存下來,但不會被包含在最終的容器鏡像中。這里有幾點需要說明: