关于前端:Docker镜像瘦身

2次阅读

共计 7071 个字符，预计需要花费 18 分钟才能阅读完成。

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

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

Docker 镜像是由很多镜像层（Layers）组成的（最多 127 层），Dockerfile 中的每条指定都会创立镜像层，不过 只有 RUN, COPY, ADD 会使镜像的体积减少 。这个能够通过命令 docker history image_id 来查看每一层的大小。
这里咱们以官网的 alpine:3.12 为例看看它的镜像层状况。

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

比照 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 文件形成。

理解了镜像构建中体积增大的起因，那么就能够隔靴搔痒：精简层数 或精简每一层大小。

精简层数的办法有如下几种：
1. RUN 指令合并
2. 多阶段构建
精简每一层的办法有如下几种：
1. 应用适合的根底镜像（首选 alpine）
2. 删除 RUN 的缓存文件

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

抉择根底镜像，更新软件源，装置打包工具
下载源码并进行打包装置
清理不须要的安装文件

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

FROM ubuntu:focal

ENV REDIS_VERSION=6.0.5
ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz

# update source and install tools
RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list 
RUN apt update 
RUN apt install -y curl make gcc

# download source code and install redis
RUN curl -L $REDIS_URL | tar xzv
WORKDIR redis-$REDIS_VERSION
RUN make
RUN make install
 
# clean up
RUN rm  -rf /var/lib/apt/lists/* 

CMD ["redis-server"]

指令合并是最简略也是最不便的升高镜像层数的形式。该操作节俭空间的原理是在同一层中清理“缓存”和工具软件。
还是打包 redis 的须要，指令合并的 Dockerfile 如下，打包后的镜像大小为 292M。

FROM ubuntu:focal

ENV REDIS_VERSION=6.0.5
ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz

# update source and install tools
RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list &&\
    apt update &&\
    apt install -y curl make gcc &&\

# download source code and install redis
    curl -L $REDIS_URL | tar xzv &&\
    cd redis-$REDIS_VERSION &&\
    make &&\
    make install &&\

# clean up
    apt remove -y --auto-remove curl make gcc &&\
    apt clean &&\
    rm  -rf /var/lib/apt/lists/* 

CMD ["redis-server"]

应用 docker history 剖析 optimize/redis:multiline 和 optimize/redis:singleline 镜像，失去如下状况：

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

多阶段构建办法是官网打包镜像的最佳实际，它是将精简层数做到极致的办法。艰深点讲它是将打包镜像分成两个阶段，一个阶段用于开发，打包，该阶段蕴含构建应用程序所需的所有内容；一个用于生产运行，该阶段只蕴含你的应用程序以及运行它所需的内容。这被称为“建造者模式”。两个阶段的关系有点像 JDK 和 JRE 的关系。
应用多阶段构建必定会升高镜像大小，然而瘦身的粒度和编程语言有关系，对编译型语言成果比拟好，因为它去掉了编译环境中多余的依赖，间接应用编译后的二进制文件或 jar 包。而对于解释型语言成果就不那么显著了。

仍然还是下面打包 redis 镜像的需要，应用多阶段构建的 Dockerfile，打包后的进行大小为 135M。

FROM ubuntu:focal AS build

ENV REDIS_VERSION=6.0.5
ENV REDIS_URL=http://download.redis.io/releases/redis-$REDIS_VERSION.tar.gz

# update source and install tools
RUN sed -i "s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list &&\
    apt update &&\
    apt install -y curl make gcc &&\

# download source code and install redis
    curl -L $REDIS_URL | tar xzv &&\
    cd redis-$REDIS_VERSION &&\
    make &&\
    make install

FROM ubuntu:focal
# copy
ENV REDIS_VERSION=6.0.5
COPY --from=build /usr/local/bin/redis* /usr/local/bin/

CMD ["redis-server"]

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

第一行多了 As build, 为前面的 COPY 做筹备
第一阶段中没有了清理操作，因为第一阶段构建的镜像只有编译的指标文件（二进制文件或 jar 包）有用，其它的都无用
第二阶段间接从第一阶段拷贝指标文件

同样的，应用 docker history 查看镜像体积状况：

比拟咱们应用多阶段构建的镜像和官网提供 redis:6（无奈和 redis:6-alpine 相比，因为 redis:6 和 ubuntu:focal 都是基于 debain 的镜像），发现二者有 30M 的空间。钻研 redis:6 的 Dockerfile 发现如下 ” 骚操作 ”:

serverMd5="$(md5sum /usr/local/bin/redis-server | cut -d' '-f1)"; export serverMd5; \
find /usr/local/bin/redis* -maxdepth 0 \
        -type f -not -name redis-server \
        -exec sh -eux -c ' \
            md5="$(md5sum"$1"| cut -d" "-f1)"; \
            test "$md5" = "$serverMd5"; \
        '--'{}'';' \
        -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 库是不一样的。
不过，这种状况比拟难碰到，即便碰到也有解决办法。

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

基于 debian 的镜像

# 换国内源，并更新
sed -i“s/deb.debian.org/mirrors.aliyun.com/g”/etc/apt/sources.list && apt update
# --no-install-recommends 很有用
apt install -y --no-install-recommends a b c && rm -rf /var/lib/apt/lists/*

alpine 镜像

# 换国内源，并更新
sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories
# --no-cache 示意不缓存
apk add --no-cache a b c && rm -rf /var/cache/apk/*

centos 镜像

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

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

FROM golang:1.11-alpine AS build

# 装置我的项目所需工具
# Run `docker build --no-cache .` to update dependencies
RUN apk add --no-cache git
RUN go get github.com/golang/dep/cmd/dep

# 装置我的项目的依赖库（GO 应用 Gopkg.toml and Gopkg.lock）# These layers are only re-built when Gopkg files are updated
COPY Gopkg.lock Gopkg.toml /go/src/project/
WORKDIR /go/src/project/
# Install library dependencies
RUN dep ensure -vendor-only

# 拷贝我的项目并进行构建
# This layer is rebuilt when a file changes in the project directory
COPY . /go/src/project/
RUN go build -o /bin/project

# 精简的生成环境
FROM scratch
COPY --from=build /bin/project /bin/project
ENTRYPOINT ["/bin/project"]
CMD ["--help"]

解决 glibc 问题

ENV ALPINE_GLIBC_VERSION="2.31-r0"
ENV LANG=C.UTF-8

RUN set -x \
    && sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories \
    && apk add --no-cache wget \
    && wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub \
    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-$ALPINE_GLIBC_VERSION.apk \
    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-$ALPINE_GLIBC_VERSION.apk \
    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-bin-$ALPINE_GLIBC_VERSION.apk \
    && wget -O https://github.com/sgerrand/alpine-pkg-glibc/releases/download/$ALPINE_GLIBC_VERSION/glibc-i18n-$ALPINE_GLIBC_VERSION.apk \
    && apk add --no-cache glibc-$ALPINE_GLIBC_VERSION.apk  \
                    glibc-bin-$ALPINE_GLIBC_VERSION.apk \
                    glibc-i18n-$ALPINE_GLIBC_VERSION.apk \
    && /usr/glibc-compat/bin/localedef --force --inputfile POSIX --charmap UTF-8 "$LANG" || true \
    && echo "export LANG=$LANG" > /etc/profile.d/locale.sh \
    && apk del glibc-i18n \
    && rm glibc-$ALPINE_GLIBC_VERSION.apk glibc-bin-$ALPINE_GLIBC_VERSION.apk glibc-i18n-$ALPINE_GLIBC_VERSION.apk

Dockerfile 最佳实际
docker 多阶段构建
三个技巧，将 Docker 镜像体积减小 90%
精简 Docker 镜像的五种通用办法
优化 Dockerfile 最佳实际
alpine3.12 镜像

如果该文章对您产生了帮忙，或者您对技术文章感兴趣，能够关注微信公众号：技术茶话会，可能第一工夫收到相干的技术文章，谢谢！

本篇文章由一文多发平台 ArtiPub 主动公布

正文完

前端

发表至：前端

2021-01-16

0

关于前端:回答网友提问如何自学-SAP-电商云销售云营销云这些产品的业务知识

关于前端:你不知道的-console让-JS-调试更简单

关于前端:SAP-UI5-智能控件-Smart-Controls-的初步认识试读版

关于前端:什么是thisnextTick

关于机器学习:机器学习一5分钟理解机器学习并上手实践

关于前端:Docker镜像瘦身

镜像构建

构建形式

体积剖析

瘦身办法

镜像瘦身

RUN 指令合并

多阶段构建

应用适合的根底镜像

删除 RUN 的缓存文件

Dockfile 实际

最佳实际点

多阶段构建样例

常见问题

alpine 根底镜像应用

参考文献

站内搜索