最小化 Java 镜像的常用技巧

柔光的暖阳◎ 2022-03-27 06:52 154阅读 0赞

#### 背景 ####

随着容器技术的普及，越来越多的应用被容器化。人们使用容器的频率越来越高，但常常忽略一个基本但又非常重要的问题 - 容器镜像的体积。本文将介绍精简容器镜像的必要性并以基于 spring boot 的 java 应用为例描述最小化容器镜像的常用技巧。

#### 精简容器镜像的必要性 ####

精简容器镜像是非常必要的，下面分别从安全性和敏捷性两个角度进行阐释。

**安全性**

基于安全方面的考虑，将不必要的组件从镜像中移除可以减少攻击面、降低安全风险。虽然 docker 支持用户通过 [Seccomp][] 限制容器内可以执行操作或者使用 [AppArmor][] 为容器配置安全策略，但它们的使用门槛较高，要求用户具备安全领域的专业素养。

**敏捷性**

精简的容器镜像能提高容器的部署速度。假设某一时刻访问流量激增，您需要通过增加容器副本数以应对突发压力。如果某些宿主机不包含目标镜像，需要先拉取镜像，然后启动容器，这时使用体积较小的镜像能加速这一过程、缩短扩容时间。另外，镜像体积越小，其构建速度也越快，同时还能减少存储和传输的成本。

#### 常用技巧 ####

将一个 java 应用容器化所需的步骤可归纳如下：

1.  编译 java 源码并生成 jar 包。
2.  将应用 jar 包和依赖的第三方 jar 包移动到合适的位置。

本章所用的样例是一个基于 spring boot 的 java 应用 [spring-boot-docker][]，所用的未经优化的 [dockerfile][] 如下：

FROM maven:3.5-jdk-8
    COPY src /usr/src/app/src
    COPY pom.xml /usr/src/app
    RUN mvn -f /usr/src/app/pom.xml clean package
    ENTRYPOINT ["java","-jar","/usr/src/app/target/spring-boot-docker-1.0.0.jar"]

由于应用使用 maven 构建，dockerfile 中指定`maven:3.5-jdk-8`作为基础镜像，该镜像的大小为 635MB。通过这种方式最终构建出的镜像非常大，达到了 719MB，这是因为一方面基础镜像本身就很大，另一方面 maven 在构建过程中会下载许多用于执行构建任务的 jar 包。

**多阶段构建**

Java 程序的运行只依赖 JRE，并不需要 maven 或者 JDK 中众多用于编译、调试、运行的工具，因此一个明显的优化方法是将用于编译构建 java 源码的镜像和用于运行 java 应用的镜像分开。为了达到这一目的，在 docker 17.05 版本之前需要用户维护 2 个 dockerfile 文件，这无疑增加了构建的复杂性。好在自 17.05 开始，docker 引入了[多阶段构建][Link 1]的概念，它允许用户在一个 dockerfile 中使用多个 From 语句。每个 From 语句可以指定不同的基础镜像并将开启一个全新的构建流程。您可以选择性地将前一阶段的构建产物复制到另一个阶段，从而只将必要的内容保留在最终的镜像里。优化后的 [dockerfile][dockerfile 1] 如下：

FROM maven:3.5-jdk-8 AS build
    COPY src /usr/src/app/src
    COPY pom.xml /usr/src/app
    RUN mvn -f /usr/src/app/pom.xml clean package
    
    FROM openjdk:8-jre
    ARG DEPENDENCY=/usr/src/app/target/dependency
    COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
    COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
    COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
    ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

该 dockerfile 选用`maven:3.5-jdk-8`作为第一阶段的构建镜像，选用`openjdk:8-jre`作为运行 java 应用的基础镜像并且只拷贝了第一阶段编译好的`.claass`文件和依赖的第三方 jar 包到最终的镜像里。通过这种方式优化后的镜像大小为 459MB。

**使用 distroless 作为基础镜像**

虽然通过多阶段构建能减小最终生成的镜像的大小，但 459MB 的体积仍相对过大。经调查发现，这是因为使用的基础镜像`openjdk:8-jre`体积过大，到达了 443MB，因此下一步的优化方向是减小基础镜像的体积。

Google 开源的项目 [distroless][] 正是为了解决基础镜像体积过大这一问题。Distroless 镜像只包含应用程序及其运行时依赖项，不包含包管理器、shell 以及在标准 Linux 发行版中可以找到的任何其他程序。目前，distroless 为依赖 [java][]、[python][]、[nodejs][]、[dotnet][] 等环境的应用提供了基础镜像。

使用 distroless 的 [dockerfile][dockerfile 2] 如下：

FROM maven:3.5-jdk-8 AS build
    COPY src /usr/src/app/src
    COPY pom.xml /usr/src/app
    RUN mvn -f /usr/src/app/pom.xml clean package
    
    FROM gcr.io/distroless/java
    ARG DEPENDENCY=/usr/src/app/target/dependency
    COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
    COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
    COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
    ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

该 dockerfile 和上一版的唯一区别在于将运行阶段依赖的基础镜像由`openjdk:8-jre`（443 MB）替换成了`gcr.io/distroless/java`（119 MB）。经过这一优化，最终镜像的大小为 135MB。

使用 distroless 的唯一不便是您无法 attach 到一个正在运行的容器上排查问题，因为镜像中不包含 shell。虽然 distroless 的 [debug 镜像][debug]提供 busybox shell，但需要用户重新打包镜像、部署容器，对于那些已经基于非 debug 镜像部署的容器无济于事。 但从安全角度来看，无法 attach 容器并不完全是坏事，因为攻击者无法通过 shell 进行攻击。

**使用 alpine 作为基础镜像**

如果您确实有 attach 容器的需求，又希望最小化镜像的大小，可以选用 [alpine][] 作为基础镜像。Alpine 镜像的特点是体积非常下，基础款镜像的体积仅 4 MB 左右。

使用 alpine 后的 [dockerfile][dockerfile 3] 如下：

FROM maven:3.5-jdk-8 AS build
    COPY src /usr/src/app/src
    COPY pom.xml /usr/src/app
    RUN mvn -f /usr/src/app/pom.xml clean package
    
    FROM openjdk:8-jre-alpine
    ARG DEPENDENCY=/usr/src/app/target/dependency
    COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
    COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
    COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
    ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

这里并未直接继承基础款 alpine，而是选用从 alpine 构建出的包含 java 运行时的`openjdk:8-jre-alpine`（83MB）作为基础镜像。使用该 dockerfile 构建出的镜像体积为 99.2MB，比基于 distroless 的还要小。

执行命令`docker exec -ti <container_id> sh`可以成功 attach 到运行的容器中。

**distroless vs alpine**

既然 distroless 和 alpine 都能提供非常小的基础镜像，那么在生产环境中到底应该选择哪一种呢？如果安全性是您的首要考虑因素，建议选用 distroless，因为它唯一可运行的二进制文件就是您打包的应用；如果您更关注镜像的体积，可以选用 alpine。

**其他技巧**

除了可以通过上述技巧精简镜像外，还有以下方式：

1.  将 dockerfile 中的多条指令合并成一条，通过减少镜像层数的方式达到精简镜像体积的目的。
2.  将稳定且体积较大的内容置于镜像下层，将变动频繁且体积较小的内容置于镜像上层。虽然该方式无法直接精简镜像体积，但充分利用了镜像的缓存机制，同样可以达到加快镜像构建和容器部署的目的。

想了解更多优化 dockerfile 的小窍门可参考教程 [Best practices for writing Dockerfiles][]。

#### 总结 ####

1.  本文通过一系列的优化，将 java 应用的镜像体积由最初的 719MB 缩小到 100MB 左右。如果您的应用依赖其他环境，也可以用类似的原则进行优化。
2.  针对 java 镜像，google 提供的另一款工具 [jib][] 能为您屏蔽镜像构建过程中的复杂细节，自动构建出精简的 java 镜像。使用它您无须编写 dockerfile，甚至不需要安装 docker。
3.  对于类似 distroless 这样无法 attach 或者不方便 attach 的容器，建议您将它们的日志中心化存储，以便问题的追踪和排查。具体方法可参考文章[面向容器日志的技术实践][Link 2]。

--------------------

本文作者：吴波bruce\_wu

[阅读原文][Link 3]

本文为云栖社区原创内容，未经允许不得转载。

[Seccomp]: https://docs.docker.com/engine/security/seccomp/
[AppArmor]: https://docs.docker.com/engine/security/apparmor/
[spring-boot-docker]: https://github.com/brucewu-fly/spring-boot-docker
[dockerfile]: https://github.com/brucewu-fly/spring-boot-docker/tree/master/dockerfiles/avoid/Dockerfile
[Link 1]: https://docs.docker.com/develop/develop-images/multistage-build/
[dockerfile 1]: https://github.com/brucewu-fly/spring-boot-docker/blob/master/dockerfiles/multi-stage/Dockerfile
[distroless]: https://github.com/GoogleContainerTools/distroless
[java]: https://github.com/GoogleContainerTools/distroless/blob/master/java/README.md
[python]: https://github.com/GoogleContainerTools/distroless/blob/master/experimental/python2.7/README.md
[nodejs]: https://github.com/GoogleContainerTools/distroless/blob/master/experimental/nodejs/README.md
[dotnet]: https://github.com/GoogleContainerTools/distroless/blob/master/experimental/dotnet/README.md
[dockerfile 2]: https://github.com/brucewu-fly/spring-boot-docker/blob/master/dockerfiles/distroless/Dockerfile
[debug]: https://github.com/GoogleContainerTools/distroless#debug-images
[alpine]: https://github.com/gliderlabs/docker-alpine
[dockerfile 3]: https://github.com/brucewu-fly/spring-boot-docker/blob/master/dockerfiles/alpine/Dockerfile
[Best practices for writing Dockerfiles]: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
[jib]: https://github.com/GoogleContainerTools/jib
[Link 2]: https://yq.aliyun.com/articles/672054
[Link 3]: https://yq.aliyun.com/articles/686040?utm_content=g_1000036538