?1. 遇到的問題

項(xiàng)目介紹:

• 文件大小 5.6 GB
• 文件數(shù)量 529352

Dockerfile

FROM golang:1.13

COPY ./ /go/src/code

構(gòu)建命令及輸入如下:

time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile .  --progress=plain

#1 [internal] load build definition from Dockerfile
#1 sha256:2a154d4ad813d1ef3355d055345ad0e7c5e14923755cea703d980ecc1c576ce7
#1 transferring dockerfile: 37B done
#1 DONE 0.1s

#2 [internal] load .dockerignore
#2 sha256:9598c0ddacf682f2cac2be6caedf6786888ec68f009c197523f8b1c2b5257b34
#2 transferring context: 2B done
#2 DONE 0.2s

#3 [internal] load metadata for golang:1.13
#3 sha256:0c7952f0b4e5d57d371191fa036da65d51f4c4195e1f4e1b080eb561c3930497
#3 DONE 0.0s

#4 [1/2] FROM golang:1.13
#4 sha256:692ef5b58e708635d7cbe3bf133ba934336d80cde9e2fdf24f6d1af56d5469ed
#4 CACHED

#5 [internal] load build context
#5 sha256:f87f36fa1dc9c0557ebc53645f7ffe404ed3cfa3332535260e5a4a1d7285be3c
#5 transferring context: 18.73MB 4.8s
#5 transferring context: 38.21MB 9.8s done
#5 DONE 10.5s

#6 [2/2] COPY ./ /go/src/code
#6 sha256:2c63806741b84767def3d7cebea3872b91d7ef00bd3d524f48976077cce3849a
#6 DONE 26.8s

#7 exporting to image
#7 sha256:e8c613e07b0b7ff33893b694f7759a10d42e180f2b4dc349fb57dc6b71dcab00
#7 exporting layers
#7 exporting layers 67.5s done
#7 writing image sha256:03b278543ab0f920f5af0540d93c5e5340f5e1f0de2d389ec21a2dc82af96754 done
#7 naming to docker.io/library/test:v3 done
#7 DONE 67.6s

real    1m45.411s
user    0m18.374s
sys     0m7.344s

其中比較花時(shí)間的是:

• 10s，load build context
• 26s，執(zhí)行 COPY 操作
• 67s，導(dǎo)出鏡像，鏡像大小 5.79GB

以下也是按照這個(gè)思路進(jìn)行逐一排查，測(cè)試驗(yàn)證，尋找構(gòu)建時(shí)的 IO 瓶頸。

2. 自制 go client 直接提交給 Dockerd 構(gòu)建效果不佳

工程 https://github.com/shaowenchen/demo/tree/master/buidl-cli 實(shí)現(xiàn)的功能就是將本地的 Dockerfile 及上下文提交給 Dockerd 進(jìn)行構(gòu)建，從而測(cè)試 Docker CLI 是否有提交文件上的瓶頸。

2.1 編譯生成二進(jìn)制文件

GOOS=linux GOARCH=amd64 go build  -o build main.go

2.2 自制二進(jìn)制提交構(gòu)建任務(wù)

time ./build ./ test:v3

real    5m12.758s
user    0m2.182s
sys     0m14.169s

使用 Go 寫的 cli 工具，將構(gòu)建上下文提交給 Dockerd 進(jìn)行構(gòu)建，時(shí)長急劇增加；與此同時(shí)，構(gòu)建機(jī)的負(fù)載飆升。

也可能還有其他優(yōu)化點(diǎn)，需要慢慢調(diào)試。而 Docker CLI 其實(shí)也有相關(guān)的參數(shù)可以用于減少 IO 占用時(shí)間。

3. 構(gòu)建參數(shù) compress、stream 參數(shù)優(yōu)化效果不佳

compress 會(huì)將上下文壓縮為 gzip 格式進(jìn)行傳輸，而 stream 會(huì)以流的形式傳輸上下文。

3.1 使用 compress 優(yōu)化

time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . --compress

real    1m46.117s
user    0m18.551s
sys     0m7.803s

3.2 使用 stream 優(yōu)化

time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . --stream

real    1m51.825s
user    0m19.399s
sys     0m7.657s

這兩個(gè)參數(shù)對(duì)縮短構(gòu)建時(shí)間，并沒有什么效果。但需要注意的是測(cè)試項(xiàng)目的文件大而且數(shù)量多，如果測(cè)試用例發(fā)生變化，可能產(chǎn)生不同的效果。接著，我們一起看看文件數(shù)量、文件大小對(duì) Dockerd 構(gòu)建鏡像的影響。

4. 文件數(shù)量對(duì) COPY 影響遠(yuǎn)不及文件大小

4.1 準(zhǔn)備測(cè)試文件

du -h --max-depth=1

119M    ./data
119M    .

在 data 目錄下放置了一個(gè) 119MB 的文件，通過復(fù)制該文件不斷增加 build context 的大小。

4.2 測(cè)試 Dockerfile

FROM golang:1.13

COPY ./ /go/src/code

4.3 構(gòu)建命令

DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile .

4.4 測(cè)試文件大小對(duì) COPY 影響明顯

文件大小對(duì) COPY 影響明顯，接近線性增長。

4.5 測(cè)試文件數(shù)量對(duì) COPY 影響甚微

文件數(shù)量對(duì) COPY 影響不大。這是由于在 Docker CLI 將 build context 發(fā)送給 Dockerd 時(shí)，會(huì)對(duì) context 進(jìn)行 tar 打包，并不是一個(gè)一個(gè)文件傳輸。

4.6 構(gòu)建并發(fā)數(shù)的瓶頸在磁盤IO

5.6G 529341個(gè)

通過 iotop 可以實(shí)時(shí)觀測(cè)到磁盤寫速度，最快能達(dá)到 200MB/s，與文件系統(tǒng) 4K 隨機(jī)寫速度最接近。

Rand_Write_Testing: (groupid=0, jobs=1): err= 0: pid=30436
  write: IOPS=37.9k, BW=148MiB/s (155MB/s)(3072MiB/20752msec); 0 zone resets

由于公用一個(gè) Dockerd，并發(fā)時(shí) Dockerd 吞吐會(huì)有瓶頸，系統(tǒng)磁盤 IO 也會(huì)成為瓶頸。

5. 不清理 Buildkit 緩存對(duì)新的構(gòu)建影響甚微

如果提示找不到 docker build?，則需要開啟EXPERIMENTAL? 或者沒有 buildx，需要下載 docker-buildx? 到 /usr/libexec/docker/cli-plugins/ 目錄。

• 查看 build 緩存

docker system df  -v

• 清理全部 build 緩存

DOCKER_BUILDKIT=1 docker builder prune -f

僅當(dāng)開啟 BuildKit 時(shí)，才會(huì)產(chǎn)生 Build cache。生產(chǎn)環(huán)境的緩存大小達(dá)到 1.408TB，但比較清理前后，對(duì)于新項(xiàng)目的構(gòu)建并沒有發(fā)現(xiàn)明顯構(gòu)建速度變化；對(duì)于老項(xiàng)目，如果沒有變動(dòng)，命中緩存后速度很快?？赡艿脑蚴蔷彺骐m大但條目不多，查詢是否有緩存的時(shí)間開銷很小。

但定期定理緩存，有利于預(yù)防磁盤被占滿的風(fēng)險(xiǎn)。

• 定時(shí)清理遠(yuǎn)期的構(gòu)建緩存

清理掉 72h 之前的緩存

DOCKER_CLI_EXPERIMENTAL=enabled docker buildx prune --filter "until=72h" -f

6. 構(gòu)建不會(huì)限制 CPU 但 IO 速度很慢

6.1 測(cè)試 CPU 限制

Dockerfile 文件

FROM ubuntu
RUN apt-get update -y
RUN apt-get install -y stress
RUN stress -c 40

DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile .

構(gòu)建機(jī)有 40C，構(gòu)建時(shí)機(jī)器 CPU 負(fù)載能達(dá)到 95%，說明構(gòu)建時(shí)，Dockerd 默認(rèn)不會(huì)對(duì) CPU 消耗進(jìn)行限制。在生產(chǎn)環(huán)境下，出現(xiàn)過 npm run build 占用 十幾個(gè) GB 內(nèi)存的場景，因此我判斷 Dockerd 默認(rèn)也不會(huì)對(duì)內(nèi)存消耗進(jìn)行限制。

6.2 在 Dockerfile 中測(cè)試 IO

Dockerfile 文件

FROM ubuntu
RUN apt-get update -y
RUN apt-get install -y fio
RUN fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=3G -numjobs=1 -runtime=1000 -group_reporting -filename=/tmp/test.file --allow_mounted_write=1 -name=Rand_Write_Testing

DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . 

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
   write: IOPS=17.4k, BW=67.9MiB/s (71.2MB/s)(3072MiB/45241msec); 0 zone resets

6.3 在容器中測(cè)試 IO

docker run -it shaowenchen/demo-fio bash

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
  write: IOPS=17.4k, BW=68.1MiB/s (71.4MB/s)(3072MiB/45091msec); 0 zone resets

6.4 在容器的存儲(chǔ)卷中測(cè)試 IO

docker run -v /tmp:/tmp -it shaowenchen/demo-fio bash

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
  write: IOPS=39.0k, BW=152MiB/s (160MB/s)(3072MiB/20162msec); 0 zone resets

6.5 在主機(jī)上試 IO

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
  write: IOPS=38.6k, BW=151MiB/s (158MB/s)(3072MiB/20366msec); 0 zone resets

Dockerd 在構(gòu)建 Dockerfile 時(shí)，遇到 Run 命令會(huì)啟動(dòng)一個(gè)容器運(yùn)行，然后提交鏡像。從測(cè)試結(jié)果，可以看到 Dockerfile 中的 IO 速度遠(yuǎn)達(dá)不到主機(jī)的，與容器中的 IO 速度一致；主機(jī)存儲(chǔ)卷的 IO 速度與主機(jī)的 IO 速度一致。

7. 直接使用 buildkitd 構(gòu)建效果不佳

雖然可以通過 DOCKER_BUILDKIT=1 開啟 Buildkit 構(gòu)建，但如果直接使用 buildkitd 效果不錯(cuò)，用于替換 Dockerd 構(gòu)建也是一個(gè)不錯(cuò)的選擇。

7.1 安裝 buildkit

wget https://github.com/moby/buildkit/releases/download/v0.11.2/buildkit-v0.11.2.linux-amd64.tar.gz
tar xvf buildkit-v0.11.2.linux-amd64.tar.gz
mv bin/* /usr/local/bin/

7.2 部署 buildkitd

cat > /usr/lib/systemd/system/buildkitd.service <<EOF
[Unit]
Description=/usr/local/bin/buildkitd
ConditionPathExists=/usr/local/bin/buildkitd
After=containerd.service

[Service]
Type=simple
ExecStart=/usr/local/bin/buildkitd
User=root
Restart=on-failure
RestartSec=1500ms

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl restart buildkitd
systemctl enable buildkitd
systemctl status buildkitd

查看到 buildkitd 正常運(yùn)行即可。

7.3 測(cè)試 buildctl 提交構(gòu)建

buildctl build --frontend=dockerfile.v0 --local context=. --local dockerfile=. --no-cache --output type=docker,name=test:v4 | docker load

[+] Building 240.8s (7/7) FINISHED

使用 buildctl 提交給 buildkitd 進(jìn)行構(gòu)建，需要的時(shí)間更多，達(dá)到 4min，較之前增加一倍。

8. 當(dāng)前存儲(chǔ)驅(qū)動(dòng)下讀寫鏡像有瓶頸

8.1 查看 Dockerd 處理邏輯

在代碼 https://github.com/moby/moby/blob/8d193d81af9cbbe800475d4bb8c529d67a6d8f14/builder/dockerfile/dispatchers.go 可以找到處理 Dockerfile 的邏輯。

1，Add 和 Copy 都是調(diào)用 performCopy 函數(shù) 2，performCopy 中調(diào)用 NewRWLayer() 新建層，調(diào)用 exportImage 寫入數(shù)據(jù)

因此，懷疑的是 Dockerd 寫鏡像層速度慢。

8.2 測(cè)試鏡像層寫入速度

準(zhǔn)備一個(gè)鏡像，大小 16GB，一共 18 層。

• 導(dǎo)入鏡像

time docker load < /tmp/16GB.tar

real    2m43.288s

• 保存鏡像

time docker save 0d08de176b9f > /tmp/16GB.tar

real    2m48.497s

docker load? 和 docker save 速度差不多，對(duì)鏡像層的處理速度大約為 100 MB/s。這個(gè)速度比磁盤 4K 隨機(jī)寫速度少了近 30%。在我看來，如果是個(gè)人使用勉強(qiáng)接受；如果用于對(duì)外提供構(gòu)建服務(wù)的平臺(tái)產(chǎn)品，這塊磁盤顯然是不合適的。

8.3 存儲(chǔ)驅(qū)動(dòng)怎么選

下面是從 https://docs.docker.com/storage/storagedriver/select-storage-driver/ 整理得出的一個(gè)比較表格:

排除不維護(hù)和非生產(chǎn)適用的，可選項(xiàng)其實(shí)沒幾個(gè)。正好有一臺(tái)機(jī)器，前段時(shí)間初始化時(shí)，將磁盤格式化成 Btrfs 文件格式，可以用于測(cè)試。zfs 存儲(chǔ)驅(qū)動(dòng)推薦用于高密度 PaaS 系統(tǒng)。

8.4 測(cè)試 Btrfs 存儲(chǔ)驅(qū)動(dòng)

• 在主機(jī)上

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
  write: IOPS=40.0k, BW=160MiB/s (168MB/s)(3072MiB/19191msec); 0 zone resets

• 容器下的測(cè)試命令

運(yùn)行容器

docker run -it shaowenchen/demo-fio bash

執(zhí)行測(cè)試

fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=3G -numjobs=1 -runtime=1000 -group_reporting -filename=/data/test.file --allow_mounted_write=1 -name=Rand_Write_Testing

• 測(cè)試 overlay2 存儲(chǔ)驅(qū)動(dòng)

docker info

Server Version: 20.10.12
Storage Driver: overlay2
  Backing Filesystem: btrfs

Rand_Write_Testing: (groupid=0, jobs=1): err= 0: pid=78: Thu Feb  2 02:41:48 2023
  write: IOPS=21.5k, BW=84.1MiB/s (88.2MB/s)(3072MiB/36512msec); 0 zone resets

• 測(cè)試 btrfs 存儲(chǔ)驅(qū)動(dòng)

docker info

Server Version: 20.10.12
Storage Driver: btrfs
  Build Version: Btrfs v5.4.1

Rand_Write_Testing: (groupid=0, jobs=1): err= 0
  write: IOPS=39.8k, BW=156MiB/s (163MB/s)(3072MiB/19750msec); 0 zone resets

可以明顯看到 btrfs 存儲(chǔ)驅(qū)動(dòng)在速度上優(yōu)于 overlay2。

9. 總結(jié)

本篇主要是記錄在生產(chǎn)環(huán)境下碰到的 Dockerfile 構(gòu)建 IO 慢問題排查過程。

通過設(shè)計(jì)各種測(cè)試案例排查問題，對(duì)各個(gè)要素進(jìn)行一一驗(yàn)證，需要極大耐心，也特別容易走錯(cuò)方向，得出錯(cuò)誤結(jié)論。

本篇主要觀點(diǎn)如下:

• compress、stream 參數(shù)對(duì)構(gòu)建速度不一定有效
• 減少構(gòu)建上下文大小，有利于緩解構(gòu)建 IO 壓力
• Buildkit 的緩存可以不用頻繁清理
• 構(gòu)建 Dockerfile 執(zhí)行命令時(shí)，CPU、Mem 不會(huì)受到限制，但 IO 速度慢
• 使用 buildkitd 構(gòu)建速度不如 Dockerd 開啟 DOCKER_BUILDKIT
• 使用 Btrfs 存儲(chǔ)有利于獲得更好的 IO 速度

但最簡單的還是使用 4K 隨機(jī)讀寫快的磁盤，在拿到新的環(huán)境用于生產(chǎn)之前，務(wù)必先進(jìn)行測(cè)試，僅當(dāng)滿足需求時(shí)，再執(zhí)行后續(xù)計(jì)劃。

10. 參考

• https://docs.docker.com/engine/reference/commandline/build/
• https://docs.docker.com/build/install-buildx/
• https://flyer103.com/2022/08/20220806-buildkitd-usage/
• https://pepa.holla.cz/2019/11/18/how-build-own-docker-image-in-golang/