如何使用 registry 存储的特性


苦命打包工具人 ????

目前在负责公司 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


你可能还喜欢

点击下方图片即可阅读

记一次 Kubernetes 中严重的安全问题

云原生是一种信仰 ????

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!

点击 "阅读原文" 获取更好的阅读体验!

发现朋友圈变“安静”了吗?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值