相关文章

Docker镜像瘦身

 |   

Docker 是一个用于开发,交付和运行应用程序的开发平台。 它能够将应用程序和基础架构分开,保证开发,测试, 部署的环境完全一致,从而达到快速交付的目的。 但是在实际项目中,会对项目中的模块或者服务进行细分, 导致部署的镜像过多(50+ 个),过大(打包压缩后的镜像达 50G+),这给部署带来了不小的隐患,特别是私有化部署(通过移动介质拷贝镜像进行部署)。本文从多篇镜像瘦身的文章入手,并进行实践验证,结合 官方的Dockerfile最佳实践 总结了镜像压缩的4种方法和日常实践的多个技巧。

镜像构建

构建方式

镜像构建的方式有两种,一种是通过 docker build 执行 Dockerfile 里的指令来构建镜像,另一种是通过 docker commit 将存在的容器打包成镜像。 通常我们都是使用第一种方式来构建容器,二者的区别就像批处理和单步执行一样。

体积分析

Docker镜像是由很多镜像层(Layers)组成的(最多127层), Dockerfile 中的每条指定都会创建镜像层,不过只有 RUN, COPY, ADD 会使镜像的体积增加。这个可以通过命令 docker history image_id 来查看每一层的大小。 这里我们以官方的 alpine:3.12 为例看看它的镜像层情况。

1FROM scratch
2ADD alpine-minirootfs-3.12.0-x86_64.tar.gz /
3CMD ["/bin/sh"]

alpine镜像层数
对比 Dockerfile 和镜像历史层数发现 ADD 命令层占据了 5.57M 大小,而 CMD 命令层并不占空间。

镜像的层就像 Git 的每一次提交 Commit, 用于保存镜像的上一个版本和当前版本之间的差异。所以当我们使用 docker pull 命令从公有或私有的 Hub 上拉取镜像时,它只会下载我们尚未拥有的层。 这是一种非常高效的共享镜像的方式,但是有时会被错误使用,比如反复提交。

反复提交案例
从上图看出,基础镜像 alpine:3.12 占据了 5.57M 大小,idps_sm.tar.gz 文件占据了 4.52M。 但是命令 RUN rm -f ./idps_sm.tar.gz 并没有降低镜像大小, 镜像大小由一个基础镜像和两次 ADD 文件构成。

瘦身方法

了解了镜像构建中体积增大的原因,那么就可以对症下药:精简层数精简每一层大小

镜像瘦身

关于镜像瘦身这块的实际操作以打包 redis 镜像为例,在打包之前我们先拉取官方 redis 的镜像, 发现标签为6的镜像大小为 104M, 标签为 6-alpine 的镜像大小为 31.5M。打包的流程如下:

  1. 选择基础镜像,更新软件源,安装打包工具
  2. 下载源码并进行打包安装
  3. 清理不需要的安装文件

按照上述的流程,我们编写如下的 Dockerfile,该镜像使用命令 docker build --no-cache -t optimize/redis:multiline -f redis_multiline . 打包后镜像大小为 441M。

 1FROM ubuntu:focal
 2
 3ENV REDIS_VERSION=6.0.5
 4ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz
 5
 6# update source and install tools
 7RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list 
 8RUN apt update 
 9RUN apt install -y curl make gcc
10
11# download source code and install redis
12RUN curl -L $REDIS_URL | tar xzv
13WORKDIR redis-$REDIS_VERSION
14RUN make
15RUN make install
16 
17# clean up
18RUN rm  -rf /var/lib/apt/lists/* 
19
20CMD ["redis-server"]

RUN指令合并

指令合并是最简单也是最方便的降低镜像层数的方式。该操作节省空间的原理是在同一层中清理“缓存”和工具软件。 还是打包 redis 的需要,指令合并的 Dockerfile如下,打包后的镜像大小为 292M。

 1FROM ubuntu:focal
 2
 3ENV REDIS_VERSION=6.0.5
 4ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz
 5
 6# update source and install tools
 7RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list &&\
 8    apt update &&\
 9    apt install -y curl make gcc &&\
10
11# download source code and install redis
12    curl -L $REDIS_URL | tar xzv &&\
13    cd redis-$REDIS_VERSION &&\
14    make &&\
15    make install &&\
16
17# clean up
18    apt remove -y --auto-remove curl make gcc &&\
19    apt clean &&\
20    rm  -rf /var/lib/apt/lists/* 
21
22CMD ["redis-server"]

使用 docker history 分析 optimize/redis:multiline 和 optimize/redis:singleline 镜像,得到如下情况:

指令合并
分析上图发现,镜像 optimize/redis:multiline 中清理数据的几层并没有降低镜像的大小,这就是上面说的共享镜像层带来的问题。所以指令合并的方法是通过在同一层中将缓存和不用的工具软件清理掉,以达到减小镜像体积的目的。

多阶段构建

多阶段构建方法是官方打包镜像的最佳实践,它是将精简层数做到极致的方法。通俗点讲它是将打包镜像分成两个阶段,一个阶段用于开发,打包,该阶段包含构建应用程序所需的所有内容;一个用于生产运行,该阶段只包含你的应用程序以及运行它所需的内容。这被称为“建造者模式”。两个阶段的关系有点像JDK和JRE的关系。 使用多阶段构建肯定会降低镜像大小,但是瘦身的粒度和编程语言有关系,对编译型语言效果比较好,因为它去掉了编译环境中多余的依赖,直接使用编译后的二进制文件或jar包。而对于解释型语言效果就不那么明显了。

依然还是上面打包 redis 镜像的需求,使用多阶段构建的 Dockerfile,打包后的进行大小为135M。

 1FROM ubuntu:focal AS build
 2
 3ENV REDIS_VERSION=6.0.5
 4ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz
 5
 6# update source and install tools
 7RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list &&\
 8    apt update &&\
 9    apt install -y curl make gcc &&\
10
11# download source code and install redis
12    curl -L $REDIS_URL | tar xzv &&\
13    cd redis-$REDIS_VERSION &&\
14    make &&\
15    make install
16
17FROM ubuntu:focal
18# copy
19ENV REDIS_VERSION=6.0.5
20COPY --from=build /usr/local/bin/redis* /usr/local/bin/
21
22CMD ["redis-server"]

相比 optimize/redis:singleline 改动有以下三点:

  1. 第一行多了As build, 为后面的COPY做准备
  2. 第一阶段中没有了清理操作,因为第一阶段构建的镜像只有编译的目标文件(二进制文件或jar包)有用,其它的都无用
  3. 第二阶段直接从第一阶段拷贝目标文件

同样的,使用 docker history 查看镜像体积情况:

多阶段构建

比较我们使用多阶段构建的镜像和官方提供 redis:6(无法和 redis:6-alpine 相比,因为 redis:6 和 ubuntu:focal 都是基于 debain 的镜像),发现二者有 30M 的空间。研究 redis:6 的 Dockerfile 发现如下"骚操作”:

1serverMd5="$(md5sum /usr/local/bin/redis-server | cut -d' ' -f1)"; export serverMd5; \
2find /usr/local/bin/redis* -maxdepth 0 \
3		-type f -not -name redis-server \
4		-exec sh -eux -c ' \
5			md5="$(md5sum "$1" | cut -d" " -f1)"; \
6			test "$md5" = "$serverMd5"; \
7		' -- '{}' ';' \
8		-exec ln -svfT 'redis-server' '{}' ';' \

编译 redis 的源码发现二进制文件 redis-server 和 redis-check-aof(aof持久化), redis-check-rdb(rdb持久化), redis-sentinel(redis哨兵)是相同的文件,大小为 11M。官方镜像通过上面的脚本将后三个通过 ln 来生成。

使用合适的基础镜像

基础镜像,推荐使用 Alpine。Alpine 是一个高度精简又包含了基本工具的轻量级 Linux 发行版,基础镜像只有 4.41M,各开发语言和框架都有基于 Alpine 制作的基础镜像,强烈推荐使用它。进阶可以尝试使用scratch和busybox镜像进行基础镜像的构建。 从官方镜像 redis:6(104M) 和 redis:6-alpine(31.5M) 就可以看出 alpine 的镜像只有基于debian镜像的 1/3。

使用 Alpine镜像有个注意点,就是它是基于 muslc的(glibc的替代标准库),这两个库实现了相同的内核接口。 其中 glibc 更常见,速度更快,而 muslic 使用较少的空间,侧重于安全性。 在编译应用程序时,大部分都是针对特定的 libc 进行编译的。如果我们要将它们与另一个 libc 一起使用,则必须重新编译它们。换句话说,基于 Alpine 基础镜像构建容器可能会导致非预期的行为,因为标准 C 库是不一样的。 不过,这种情况比较难碰到,即使碰到也有 解决方法

删除RUN的缓存文件

linux中大部分包管理软件都需要更新源,该操作会带来一些缓存文件,这里记录了常用的清理方法。

  • 基于debian的镜像

    1# 换国内源,并更新
    2sed -i "s/deb.debian.org/mirrors.aliyun.com/g" /etc/apt/sources.list && apt update
    3# --no-install-recommends 很有用
    4apt install -y --no-install-recommends a b c && rm -rf /var/lib/apt/lists/*
    
  • alpine镜像

    1# 换国内源,并更新
    2sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories
    3# --no-cache 表示不缓存
    4apk add --no-cache a b c && rm -rf /var/cache/apk/*
    
  • centos镜像

    1# 换国内源并更新
    2curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo && yum makecache
    3yum install -y a b c  && yum clean al
    

Dockfile实践

最佳实践点

  • 编写.dockerignore文件
  • 一个容器只运行单个应用
  • 基础镜像和生产镜像的标签不要使用latest
  • 设置WORKDIR和CMD
  • 使用ENTRYPOINT,并用exec启动命令(可选)
  • 相比ADD,优先使用COPY
  • 设置默认的环境变量,映射端口和数据卷
  • 使用LABEL设置镜像元数据
  • 添加HEALTHCHECK

多阶段构建样例

 1FROM golang:1.11-alpine AS build
 2
 3# 安装项目所需工具
 4# Run `docker build --no-cache .` to update dependencies
 5RUN apk add --no-cache git
 6RUN go get github.com/golang/dep/cmd/dep
 7
 8# 安装项目的依赖库(GO使用 Gopkg.toml and Gopkg.lock)
 9# These layers are only re-built when Gopkg files are updated
10COPY Gopkg.lock Gopkg.toml /go/src/project/
11WORKDIR /go/src/project/
12# Install library dependencies
13RUN dep ensure -vendor-only
14
15# 拷贝项目并进行构建
16# This layer is rebuilt when a file changes in the project directory
17COPY . /go/src/project/
18RUN go build -o /bin/project
19
20# 精简的生成环境
21FROM scratch
22COPY --from=build /bin/project /bin/project
23ENTRYPOINT ["/bin/project"]
24CMD ["--help"]

常见问题

alpine基础镜像使用

  1. 解决 glibc 问题

     1ENV ALPINE_GLIBC_VERSION="2.31-r0"
     2ENV LANG=C.UTF-8
     3
     4RUN set -x \
     5    && sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories \
     6    && apk add --no-cache wget \
     7    && wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub \
     8    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-$ALPINE_GLIBC_VERSION.apk \
     9    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-$ALPINE_GLIBC_VERSION.apk \
    10    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-bin-$ALPINE_GLIBC_VERSION.apk \
    11    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-i18n-$ALPINE_GLIBC_VERSION.apk \
    12    && apk add --no-cache glibc-$ALPINE_GLIBC_VERSION.apk  \
    13                    glibc-bin-$ALPINE_GLIBC_VERSION.apk \
    14                    glibc-i18n-$ALPINE_GLIBC_VERSION.apk \
    15    && /usr/glibc-compat/bin/localedef --force --inputfile POSIX --charmap UTF-8 "$LANG" || true \
    16    && echo "export LANG=$LANG" > /etc/profile.d/locale.sh \
    17    && apk del glibc-i18n \
    18    && rm glibc-$ALPINE_GLIBC_VERSION.apk glibc-bin-$ALPINE_GLIBC_VERSION.apk glibc-i18n-$ALPINE_GLIBC_VERSION.apk
    

多镜像打包

  1. docker-compose.yml 中有很多镜像,每次私有化部署时需要将所有镜像打包。同样的配置如何使打包的镜像尽量小:
    • 镜像尽量使用相同的基础镜像
    • docker save 后的镜像文件需要再使用 tar 进行压缩
    • 多个镜像打包成一个文件,而不是不同的镜像打包成多个文件(充分使用)

下面的截图中,kg-api 和 kg-build 使用了相同的基础镜像(包含了共用的 python3 环境以及依赖的第三方包),所以二者直接 docker save 后的大小在 537 MB 左右。通过 tar 压缩后得到 166 MB 左右的压缩包,缩小了 1/3。 通过一起打包镜像后, 发现二者的大小也是 537 MB 左右,基本相当于一个镜像的大小。这里的大小基本上就是基础镜像的大小。

多镜像压缩

参考文献

  1. Dockerfile最佳实践
  2. docker多阶段构建
  3. 三个技巧,将 Docker 镜像体积减小 90%
  4. 精简Docker镜像的五种通用方法
  5. 优化Dockerfile最佳实践
  6. alpine3.12镜像
技术茶话会
< 前一篇 后一篇 >