苦命打包工具人 ????
目前在负责公司 PaaS toB 产品的打包发布工作(苦命发版+打包工具人 ????)。日常的一项工作就是跑完自动化打包流水线,再将打出来的安装包更新到 QA 测试环境中。因为打包环境和测试环境分布在两个不同的机房,产品的安装包需要跨公网从打包机器上同步到 QA 环境中,因此产品安装包的大小就决定着两者间同步的耗时。优化和减少产品安装包的大小就成为了提升流水线效率的途径之一。最近做的一项工作就是将产品补丁包的大小减少 30%~ 60%,大大节省了补丁包上传下载和安装的耗时,提升了产品打包流水线的效率。因此今天就总结一下从中学到的一点人生经验 ????。
再次优化
因为产品所有的组件都是容器化的形式部署的,所以产品的补丁包中最主要的就是镜像文件以及一些部署脚本,想要优化和见减小补丁包基本上等同于减小这些镜像的大小。众所周知 docker 镜像是由一层一层的 layer + 镜像的元数据信息构成的,其中镜像的元数据信息就是镜像的 image config + manifests,这些都是 json 格式的文本内容,相对于镜像的 layer 的大小,这些文本内容往往可以忽略不计。
其实去年的时候已经做过了一次优化,将补丁包镜像打包的方式由原来的 docker save 的方式替换成了 skopeo copy 到目录的方式,优化的效果就是:将补丁包的大小减少了 60%~ 80%;流水线的速度提升了 5 倍;补丁包安装速度也提升了 5 倍。这项优化的原理可以参考我之前的博客 深入浅出容器镜像的一生[1]。虽然第一次已经有了这么明显的优化,但咱仍然觉得还有可以优化的空间。
经过第一次优化之后,产品补丁包中镜像存在的形式如下:
root@debian:/root/kube # tree images -h
images
├── [4.0K] kube-apiserver:v1.20.5
│ ├── [707K] 742efefc8a44179dcc376b969cb5e3f8afff66f87ab618a15164638ad07bf722
│ ├── [ 28M] 98d681774b176bb2fd6b3499377d63ff4b1b040886dd9d3641bb93840815a1e7
│ ├── [2.6K] d7e24aeb3b10210bf6a2dc39f77c1ea835b22af06dfd2933c06e0421ed6d35ac
│ ├── [642K] fefd475334af8255ba693de12951b5176a2853c2f0d5d2b053e188a1f3b611d9
│ ├── [ 949] manifest.json
│ └── [ 33] version
├── [4.0K] kube-controller-manager:v1.20.5
│ ├── [ 27M] 454a7944c47b608efb657a1bef7f4093f63ceb2db14fd78c5ecd2a08333da7cf
│ ├── [2.6K] 6f0c3da8c99e99bbe82920a35653f286bd8130f0662884e77fa9fcdca079c07f
│ ├── [707K] 742efefc8a44179dcc376b969cb5e3f8afff66f87ab618a15164638ad07bf722
│ ├── [642K] fefd475334af8255ba693de12951b5176a2853c2f0d5d2b053e188a1f3b611d9
│ ├── [ 949] manifest.json
│ └── [ 33] version
└── [4.0K] kube-scheduler:v1.20.5
├── [ 12M] 565677e452d17c4e2841250bbf0cc010d906fbf7877569bb2d69bfb4e68db1b5
├── [707K] 742efefc8a44179dcc376b969cb5e3f8afff66f87ab618a15164638ad07bf722
├── [2.6K] 8d13f1db8bfb498afb0caff6bf3f8c599ecc2ace74275f69886067f6af8ffdf6
├── [642K] fefd475334af8255ba693de12951b5176a2853c2f0d5d2b053e188a1f3b611d9
├── [ 949] manifest.json
└── [ 33] version
仔细分析可以发现这样打包出来的镜像要比它们在 registry 中的所占存储空间要大一些,这是因为每一个镜像存储目录下都保存在该镜像的所有 layer ,不能像 registry 存储那样可以复用相同的 layer。比如 kube-apiserver
kube-controller-manager
kube-scheduler
这三个镜像都是使用的 k8s.gcr.io/build-image/go-runner
这个 base 镜像。在 registry 中,它只需要存储一份 go-runner
base 镜像即可。而使用 skopeo copy 存储在目录中时,就需要分别存储一份这个 base 镜像了。
从文件名和文件大小也可以大致推断出 707K
大小的 742efefc8a 就是 go-runner
镜像的跟文件系统;642K
大小的 fefd47533 就是 go-runner 的二进制文件;2.x
左右大小的应该就是镜像的 image config 文件;剩下那个十几二十几 M 的就是 kube-apiserver
kube-controller-manager
kube-scheduler
的二进制文件;manifest.json 文件就是镜像在 registry 存储中的 manifest 。
使用 find 来统计这些文件的数量,经过去重之后可以发现镜像的 layer 文件和 config 文件总数量从原来的 12 个减少到 8 个。做一个简单的加法计算也就是:3 个 image config 文件 + 3 个二进制文件 + 1 个 base 镜像 layer 文件 + 1 个 go-runner 二进制文件,这不正好就是 8 嘛 ????
root@debian:/root/kube # find images -type f | grep -Eo "\b[a-f0-9]{64}\b" | wc
12
root@debian:/root/kube # find images -type f | grep -Eo "\b[a-f0-9]{64}\b" | sort -u | wc -l
8
既然补丁包中的镜像文件有一些相同的 layer,那么去重这些相同的 layer 文件岂不就能减少补丁包的大小了?于是就拿了一个历史的补丁包测试一下。
root@debian:/root $ du -sh images
3.3G images
root@debian:/root $ find images -type f ! -name 'version' ! -name 'manifest.json' | wc -l
279
root@debian:/root $ mkdir -p images2
root@debian:/root $ find images -type f -exec mv {} images2 \;
root@debian:/root $ du -sh images2
1.3G images2
root@debian:/root $ $ find images2 -type f ! -name 'version' ! -name 'manifest.json' | wc -l
187
没有对比就没有伤害,经过测试之后发现:补丁包中镜像文件的总数量由原来的 279 个减小至 187 个,总大小从原来的 3.3G 减小到 1.3G,减小了 60%!当时兴奋得我拍案叫绝,如获珍宝。其实这得益于我们产品组件使用的 base 镜像基本上是相同的,因此可以去除掉很多相同的 base 镜像 layer 文件。
既然找到了减小补丁包中镜像大小的思路,那么只要找到一种方式来去重这些镜像 layer 就可以了。首先想到的就是使用 registry 存储:根据 registry 存储的特性,镜像在 registry 中是可以复用相同的 layer 的。所以大体的思路就是将这些补丁包中的镜像转换为 registry 存储的格式,在安装的时候再将 registry 存储的格式转换为 skopeo copy 支持的 dir 格式。
构建 skopeo dir 镜像存储
为了方便演示,需要找个合适的镜像列表,看了一下 ks-installer[2] 项目中有个镜像列表,看样子比较合适那就用它吧 ????
root@debian:/root # curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.0.0/images-list.txt
首先将镜像使用 skopeo sync 同步到本地目录,并统计一下镜像的大小和文件的数量
root@debian:/root # for img in $(cat cat images-list.txt | grep -v "#");do skopeo sync --insecure-policy --src docker --dest dir ${img} images; done
root@debian:/root # tree images -d -L 1
images
├── alpine:3.10.4
├── busybox:1.31.1
├── calico
├── coredns
├── csiplugin
├── docker:19.03
├── elastic
├── fluent
├── haproxy:2.0.4
├── istio
├── jaegertracing
├── java:openjdk-8-jre-alpine
├── jenkins
├── jimmidyson
├── joosthofman
├── kubesphere
├── minio
├── mirrorgooglecontainers
├── mysql:8.0.11
├── nginx:1.14-alpine
├── nginxdemos
├── openpitrix
├── osixia
├── perl:latest
├── prom
├── redis:5.0.5-alpine
└── wordpress:4.8-apache
使用 skopeo sync 将镜像同步到本地 images 目录后,统计可得所有镜像的大小为 11G、总的文件为 1264 个。
root@debian:/root # du -sh images
11G images
root@debian:/root # find images -type f ! -name "version" | wc -l
1264
转换成 registry 存储目录
根据下图所示的 registry 存储结构,我们要将镜像的 layer、image config、manifests 这三种文件根据它们的 sha256 值存放到 blobs/sha256 目录下,然后再在 repositories 目录下创建相应 link 文件,这样就可以将镜像转换成 registry 存储的格式了。
为方便演示我们先以单个镜像为例,将 images/alpine:3.10.4
这个镜像在转换成 docker registry 存储目录的形式
root@debian:/root # tree -h images/alpine:3.10.4
images/alpine:3.10.4
└── [4.0K] alpine:3.10.4
├── [2.7M] 4167d3e149762ea326c26fc2fd4e36fdeb7d4e639408ad30f37b8f25ac285a98
├── [1.5K] af341ccd2df8b0e2d67cf8dd32e087bfda4e5756ebd1c76bbf3efa0dc246590e
├── [ 528] manifest.json
└── [ 33] version
根据镜像文件大小我们可以得知:2.7M
大小的 4167d3e1497……
文件就是镜像的 layer 文件,由于 alpine 是一个 base 镜像,该 layer 就是 alpine 的根文件系统;1.5K
大小的 af341ccd2……
显而易见就是镜像的 images config 文件;manifest.json
文件则是镜像在 registry 存储中的 manifest.json 文件。
先创建该镜像在 registry 存储中的目录结构
root@debian:/root # mkdir -p docker/registry/v2/{blobs/sha256,repositories/alpine}
root@debian:/root # tree docker
docker
└── registry
└── v2
├── blobs
│ └── sha256
└── repositories
└── alpine
构建镜像 layer 的 link 文件
grep -Eo "\b[a-f0-9]{64}\b" images/alpine:3.10.4/manifest.json | sort -u | xargs -L1 -I {} mkdir -p docker/registry/v2/repositories/alpine/_layers/sha256/{}
grep -Eo "\b[a-f0-9]{64}\b" images/alpine:3.10.4/manifest.json | sort -u | xargs -L1 -I {} sh -c "echo -n 'sha256:{}' > docker/registry/v2/repositories/alpine/_layers/sha256/{}/link"
构建镜像 tag 的 link 文件
manifests_sha256=$(sha256sum images/alpine:3.10.4/manifest.json | awk '{print $1}')
mkdir -p docker/registry/v2/repositories/alpine/_manifests/revisions/sha256/${manifests_sha256}
echo -n "sha256:${manifests_sha256}" > docker/registry/v2/repositories/alpine/_manifests/revisions/sha256/${manifests_sha256}/link
mkdir -p docker/registry/v2/repositories/alpine/_manifests/tags/3.10.4/index/sha256/${manifests_sha256}
echo -n "sha256:${manifests_sha256}" > docker/registry/v2/repositories/alpine/_manifests/tags/3.10.4/index/sha256/${manifests_sha256}/link
mkdir -p docker/registry/v2/repositories/alpine/_manifests/tags/3.10.4/current
echo -n "sha256:${manifests_sha256}" > docker/registry/v2/repositories/alpine/_manifests/tags/3.10.4/current/link
构建镜像的 blobs 目录
mkdir -p docker/registry/v2/blobs/sha256/${manifests_sha256:0:2}/${manifests_sha256}
ln -f images/alpine:3.10.4/manifest.json docker/registry/v2/blobs/sha256/${manifests_sha256:0:2}/${manifests_sha256}/data
for layer in $(grep -Eo "\b[a-f0-9]{64}\b" images/alpine:3.10.4/manifest.json); do
mkdir -p docker/registry/v2/blobs/sha256/${layer:0:2}/${layer}
ln -f images/alpine:3.10.4/${layer} docker/registry/v2/blobs/sha256/${layer:0:2}/${layer}/data
done
最终得到的 registry 存储目录如下
docker
└── registry
└── v2
├── blobs
│ └── sha256
│ ├── 41
│ │ └── 4167d3e149762ea326c26fc2fd4e36fdeb7d4e639408ad30f37b8f25ac285a98
│ │ └── data
│ ├── af
│ │ └── af341ccd2df8b0e2d67cf8dd32e087bfda4e5756ebd1c76bbf3efa0dc246590e
│ │ └── data
│ └── de
│ └── de78803598bc4c940fc4591d412bffe488205d5d953f94751c6308deeaaa7eb8
│ └── data
└── repositories
└── alpine
├── _layers
│ └── sha256
│ ├── 4167d3e149762ea326c26fc2fd4e36fdeb7d4e639408ad30f37b8f25ac285a98
│ │ └── link
│ └── af341ccd2df8b0e2d67cf8dd32e087bfda4e5756ebd1c76bbf3efa0dc246590e
│ └── link
└── _manifests
├── revisions
│ └── sha256
│ └── de78803598bc4c940fc4591d412bffe488205d5d953f94751c6308deeaaa7eb8
│ └── link
└── tags
└── 3.10.4
├── current
│ └── link
└── index
└── sha256
└── de78803598bc4c940fc4591d412bffe488205d5d953f94751c6308deeaaa7eb8
└── link
测试是否正常,本地 docker run 一个 registry 容器,将刚刚转换的 registry 存储目录挂载到容器的 /var/lib/registry,然后再使用 docker pull 的方式拉取镜像,在使用 docker run 测试一下能否正常使用。经过验证之后确实可以使用,那就说明这样的转换是没有问题的 ????。
root@debian:/root # docker pull localhost/alpine:3.10.4
3.10.4: Pulling from alpine
4167d3e14976: Pull complete
Digest: sha256:de78803598bc4c940fc4591d412bffe488205d5d953f94751c6308deeaaa7eb8
Status: Downloaded newer image for localhost/alpine:3.10.4
root@debian:/root # docker run --rm -it localhost/alpine:3.10.4 cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.4
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
将上述步骤整合成一个 shell 脚本,内容如下
#!/bin/bash
set -eo pipefail
IMAGES_DIR="images"
REGISTRY_DIR="docker"
rm -rf ${REGISTRY_DIR}
BLOBS_PATH="${REGISTRY_DIR}/registry/v2/blobs"
REPO_PATH="${REGISTRY_DIR}/registry/v2/repositories"
for image in $(find ${IMAGES_DIR} -type f | sed -n 's|/manifest.json||p' | sort -u); do
image_name=$(echo ${image%%:*} | sed "s|${IMAGES_DIR}/||g")
image_tag=${image##*:}; mfs="${image}/manifest.json"
mfs_sha256=$(sha256sum ${image}/manifest.json | awk '{print $1}')
mkdir -p ${BLOBS_PATH}/sha256/${mfs_sha256:0:2}/${mfs_sha256}
ln -f ${mfs} ${BLOBS_PATH}/sha256/${mfs_sha256:0:2}/${mfs_sha256}/data
# make image repositories dir
mkdir -p ${REPO_PATH}/${image_name}/{_layers,_manifests/revisions}/sha256
mkdir -p ${REPO_PATH}/${image_name}/_manifests/revisions/sha256/${mfs_sha256}
mkdir -p ${REPO_PATH}/${image_name}/_manifests/tags/${image_tag}/{current,index/sha256}
mkdir -p ${REPO_PATH}/${image_name}/_manifests/tags/${image_tag}/index/sha256/${mfs_sha256}
# create image tag manifest link file
echo -n "sha256:${mfs_sha256}" > ${REPO_PATH}/${image_name}/_manifests/tags/${image_tag}/current/link
echo -n "sha256:${mfs_sha256}" > ${REPO_PATH}/${image_name}/_manifests/revisions/sha256/${mfs_sha256}/link
echo -n "sha256:${mfs_sha256}" > ${REPO_PATH}/${image_name}/_manifests/tags/${image_tag}/index/sha256/${mfs_sha256}/link
# link image layers file to registry blobs file
for layer in $(grep -Eo "\b[a-f0-9]{64}\b" ${mfs}); do
mkdir -p ${BLOBS_PATH}/sha256/${layer:0:2}/${layer}
mkdir -p ${REPO_PATH}/${image_name}/_layers/sha256/${layer}
echo -n "sha256:${layer}" > ${REPO_PATH}/${image_name}/_layers/sha256/${layer}/link
ln -f ${image}/${layer} ${BLOBS_PATH}/sha256/${layer:0:2}/${layer}/data
done
done
使用该脚本对 images 中所有镜像进行一下转换,最终得到的 registry 存储大小为 8.3 G,比之前减少了 2.7G。
root@debian:/root # du -sh docker
8.3G docker
root@debian:/root # find docker -type f -name "data" | wc -l
1046
再还原回 Dir 格式
经过上述步骤一番折腾之后,将补丁包中镜像文件的总大小的确实减少了很多,但同时又引入了另一个问题:skopeo 无法直接使用 registry 存储的格式。因此我们还需要再做一次转换,将镜像由 registry 存储的格式还原回 skopeo 所支持的 dir 格式。至于还原的原理和方法我在 docker registry 迁移至 harbor[3] 中有详细地介绍,感兴趣的小伙伴可以再去看一下。
#!/bin/bash
REGISTRY_DOMAIN="harbor.k8s.li"
REGISTRY_PATH="/var/lib/registry"
# 切换到 registry 存储主目录下
cd ${REGISTRY_PATH}
gen_skopeo_dir() {
# 定义 registry 存储的 blob 目录 和 repositories 目录,方便后面使用
BLOB_DIR="docker/registry/v2/blobs/sha256"
REPO_DIR="docker/registry/v2/repositories"
# 定义生成 skopeo 目录
SKOPEO_DIR="docker/skopeo"
# 通过 find 出 current 文件夹可以得到所有带 tag 的镜像,因为一个 tag 对应一个 current 目录
for image in $(find ${REPO_DIR} -type d -name "current"); do
# 根据镜像的 tag 提取镜像的名字
name=$(echo ${image} | awk -F '/' '{print $5"/"$6":"$9}')
link=$(cat ${image}/link | sed 's/sha256://')
mfs="${BLOB_DIR}/${link:0:2}/${link}/data"
# 创建镜像的硬链接需要的目录
mkdir -p "${SKOPEO_DIR}/${name}"
# 硬链接镜像的 manifests 文件到目录的 manifest 文件
ln ${mfs} ${SKOPEO_DIR}/${name}/manifest.json
# 使用正则匹配出所有的 sha256 值,然后排序去重
layers=$(grep -Eo "\b[a-f0-9]{64}\b" ${mfs} | sort -u)
for layer in ${layers}; do
# 硬链接 registry 存储目录里的镜像 layer 和 images config 到镜像的 dir 目录
ln ${BLOB_DIR}/${layer:0:2}/${layer}/data ${SKOPEO_DIR}/${name}/${layer}
done
done
}
sync_image() {
# 使用 skopeo sync 将 dir 格式的镜像同步到 harbor
for project in $(ls ${SKOPEO_DIR}); do
skopeo sync --insecure-policy --src-tls-verify=false --dest-tls-verify=false \
--src dir --dest docker ${SKOPEO_DIR}/${project} ${REGISTRY_DOMAIN}/${project}
done
}
gen_skopeo_dir
sync_image
脚注
[1]
深入浅出容器镜像的一生: https://blog.k8s.li/Exploring-container-image.html
[2]ks-installer: https://github.com/kubesphere/ks-installer
[3]docker registry 迁移至 harbor: https://blog.k8s.li/docker-registry-to-harbor.html
原文链接:https://blog.k8s.li/skopeo-to-registry.html
你可能还喜欢
点击下方图片即可阅读
云原生是一种信仰 ????
关注公众号
后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!
点击 "阅读原文" 获取更好的阅读体验!
发现朋友圈变“安静”了吗?