springboot docker运行镜像配置文件_SpringBoot 项目构建 Docker 镜像深度调优

点击上方☝ SpringForAll社区  轻松关注! 及时获取有趣有料的技术文章

本文来源:http://www.mydlq.club/article/16/

. 一、探究常规 Springboot 如何编译 Docker 镜像

. 1、准备编译镜像的 SpringBoot 项目

. 2、准备 Dockerfile 文件

. 3、构建 Docker 镜像

. 4、将镜像推送到镜像仓库

. 5、拉取镜像

. 6、修改 Java 源码重新打包 Jar 后再次尝试

. 7、使用镜像过程中的感受

. 二、了解 Docker 分层及缓存机制

. 1、Docker 分层缓存简介

. 2、SpringBoot Docker 镜像的分层

. 三、是什么导致 Jar 包臃肿

. 1、解压 Jar 包查看内容

. 2、解决臃肿的新思路

. 3、如何解决 lib 和 class 文件分离

. 四、聊聊如何改造 Springboot 编译 Docker 镜像

. 1、修改 Dockerfile 文件

. 2、改造 Docker 镜像后的首次编译、推送、拉取

. 3、再次编译、推送、拉取

. 五、最后总结


PS:已经在生产实践中验证,解决在生产环境下,网速带宽小,每次推拉镜像影响线上服务问题,按本文方式构建镜像,除了第一次拉取、推送、构建镜像慢,第二、三…次都是几百K大小传输,速度非常快,构建、打包、推送几秒内完成。

前言:

以前的 SpringCloud 微服务时代以 “Jar包” 为服务的基础,每个服务都打成 Jar 供服务间相互关联与调用。而 现在随着 Kubernetes 流行,已经变迁到一个镜像一个服务,依靠 Kubernetes 对镜像的统一编排进行对服务进行统一管理。在对 Kubernetes 微服务实践过程中,接触最多的肯定莫过于 Docker 镜像。由于本人使用的编程语言是 Java,所以对 Java SpringBoot 项目接触比较多,所以比较关心如何更好的通过 Dockerfile 编译 Docker 的镜像。

Kubernetes 微服务简单说就是一群镜像间的排列组合与相互间调的关系,故而如何编译镜像会使服务性能更优,使镜像构建、推送、拉取速度更快,使其占用网络资源更少这里优化,更易使用成为了一个重中之重的事情,也是一个非常值得琢磨的问题。这里我将对 SpringBoot 项目打包 Docker 镜像如何写 Dockerfile 的探究进行简单叙述。

系统环境:

  • Docker 版本: 18.09.3

  • Open JDK 基础镜像版本:openjdk:8u212-b04-jre-slim

  • 测试用的镜像仓库:阿里云 Docker Hub

  • 项目 Github: https://github.com/my-dlq/blog-example/tree/master/springboot/springboot-dockerfile


一、探究常规 Springboot 如何编译 Docker 镜像

这里将用常规 SpringBoot 编译 Docker 镜像的 Dockerfile 写法,感受下这种方式编译的镜像用起来如何。

1、准备编译镜像的 SpringBoot 项目

这里准备一个经过 Maven 编译后的普通的 springboot 项目来进行 Docker 镜像构建,项目内容如下图所示,可以看到要用到的就是里面的应用程序的 Jar 文件,将其存入镜像内完成镜像构建任务。

  • jar 文件大小:70.86mb

f2b78887e97ce041cd68384c7573bbcf.png

2、准备 Dockerfile 文件

构建 Docker 镜像需要提前准备 Dockerfile 文件,这个 Dockerfile 文件中的内容为构建 Docker 镜像执行的指令。下面是一个常用的 SpringBoot 构建 Docker 镜像的 Dockerfile,将它放入 Java 源码目录(target 的上级目录),确保下面设置的 Dockerfile 脚本中设置的路径和 target 路径对应。

FROM openjdk:8u212-b04-jre-slim

VOLUME /tmp

ADD target/*.jar app.jar

RUN sh -c 'touch /app.jar'

ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

ENV APP_OPTS=""

ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

3、构建 Docker 镜像

通过 Docker build 命令构建 Docker 镜像,观察编译的时间。

由于后续需要将镜像推送到 Aliyun Docker 仓库,所以镜像前缀用了 Aliyun。

  • time:此参数会显示执行过程经过的时间

$ time docker build -t registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1 .

构建过程

Sending build context to Docker daemon 148.7MB

Step 1/7 : FROM openjdk:8u212-b04-jre-slim

8u212-b04-jre-slim: Pulling from library/openjdk

743f2d6c1f65: Already exists

b83e581826a6: Pull complete

04305660f45e: Pull complete

bbe7020b5561: Pull complete

Digest: sha256:a5bcd678408a5fe94d13e486d500983ee6fa594940cbbe137670fbb90030456c

Status: Downloaded newer image for openjdk:8u212-b04-jre-slim

---> 7c6b62cf60ee

Step 2/7 : VOLUME /tmp

---> Running in 13a67ab65d2b

Removing intermediate container 13a67ab65d2b

---> 52011f49ddef

Step 3/7 : ADD target/*.jar app.jar

---> 26aa41a404fd

Step 4/7 : RUN sh -c 'touch /app.jar'

---> Running in 722e7e44e04d

Removing intermediate container 722e7e44e04d

---> 7baedb10ec62

Step 5/7 : ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

---> Running in 2681d0c5edac

Removing intermediate container 2681d0c5edac

---> 5ef4a794b992

Step 6/7 : ENV APP_OPTS=""

---> Running in 5c8924a2a49d

Removing intermediate container 5c8924a2a49d

---> fba87c19053a

Step 7/7 : ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

---> Running in c4cf97009b3c

Removing intermediate container c4cf97009b3c

---> d5f30cdfeb81

Successfully built d5f30cdfeb81

Successfully tagged registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

real 0m13.778s

user 0m0.078s

sys 0m0.153s

看到这次编译在 14s 内完成。

4、将镜像推送到镜像仓库

将镜像推送到 Aliyun 仓库,然后查看并记录推送时间

$ time docker push registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

执行过程

The push refers to repository [registry.cn-beijing.aliyuncs.com/mydlq/springboot]

cc1a2376d7c0: Pushed

2b940d07e9e7: Pushed

9544e87fb8dc: Pushed

feb5d0e1e192: Pushed

8fd22162ddab: Pushed

6270adb5794c: Pushed

0.0.1: digest: sha256:dc60d304383b1441941ca4e9abc08db775d7be57ccb7c534c929b34ff064a62f size: 1583

real 0m24.335s

user 0m0.052s

sys 0m0.059s

看到这次在 25s 内完成。

5、拉取镜像

这里切换到另一台服务器上进行镜像拉取操作,观察镜像拉取时间。

$ time docker pull registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

拉取过程

0.0.1: Pulling from mydlq/springboot

743f2d6c1f65: Already exists

b83e581826a6: Pull complete

04305660f45e: Pull complete

bbe7020b5561: Pull complete

4847672cbfa5: Pull complete

b60476972fc4: Pull complete

Digest: sha256:dc60d304383b1441941ca4e9abc08db775d7be57ccb7c534c929b34ff064a62f

Status: Downloaded newer image for registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

real 0m27.528s

user 0m0.033s

sys 0m0.192s

看到这次拉取总共用时 28s 内完成。

6、修改 Java 源码重新打包 Jar 后再次尝试

这里将源码的 JAVA 文件内容修改,然后重新打 Jar 包,这样再次尝试编译、推送、拉取过程,由于 Docker 在执行构建时会采用分层缓存,所以这是一个执行较快过程。

(1)、编译

$ time docker build -t registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2 .

Sending build context to Docker daemon 148.7MB

Step 1/7 : FROM openjdk:8u212-b04-jre-slim

---> 7c6b62cf60ee

Step 2/7 : VOLUME /tmp

---> Using cache

---> 52011f49ddef

Step 3/7 : ADD target/*.jar app.jar

---> c67160dd2a23

Step 4/7 : RUN sh -c 'touch /app.jar'

---> Running in 474900d843a2

Removing intermediate container 474900d843a2

---> 3ce9a8bb2600

Step 5/7 : ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

---> Running in f48620b1ad36

Removing intermediate container f48620b1ad36

---> 0478f8f14e5b

Step 6/7 : ENV APP_OPTS=""

---> Running in 98485fb15fc8

Removing intermediate container 98485fb15fc8

---> 0b567c848027

Step 7/7 : ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

---> Running in e32242fc6efe

Removing intermediate container e32242fc6efe

---> 7b223b23ebfd

Successfully built 7b223b23ebfd

Successfully tagged registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

real 0m3.190s

user 0m0.039s

sys 0m0.403s

可以看到在编译镜像过程中,前1、2层用的缓存,所以速度非常快。总编译过程耗时 4s 内完成。

(2)、推送

$ time docker push registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

The push refers to repository [registry.cn-beijing.aliyuncs.com/mydlq/springboot]

d66a2fec30b5: Pushed

f4da2c7581aa: Pushed

9544e87fb8dc: Layer already exists

feb5d0e1e192: Layer already exists

8fd22162ddab: Layer already exists

6270adb5794c: Layer already exists

real 0m20.816s

user 0m0.024s

sys 0m0.081s

可以看到只推送了前两层,其它四次由于远程仓库未变化,所以没有推送。整个推送过程耗时 21s 内完成。

(3)、拉取

$ time docker pull registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

0.0.2: Pulling from mydlq/springboot

743f2d6c1f65: Already exists

b83e581826a6: Already exists

04305660f45e: Already exists

bbe7020b5561: Already exists

d7e364f0d94a: Pull complete

8d688ada35b1: Pull complete

Digest: sha256:7c13c40fa92ec2fdc3a8dfdd3232be1be9c1a1a99bf123743ff2a43907ee03dc

Status: Downloaded newer image for registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

real 0m23.214s

user 0m0.053s

sys 0m0.097s

本地以及缓存前四层,只拉取有变化的后两层。这个过程耗时 24s 内完成。

7、使用镜像过程中的感受

通过这种方式对 SpringBoot 项目构建 Docker 镜像来使用,给我的感受就是只要源码中发生一点点变化,那么 SpringBoot 项目就需要将项目经过 Maven 编译后再经过 Docker 镜像构建,每次都会将一个 70M+ 的应用 Jar 文件存入 Docker 中,有时候明明就改了一个字母,可能又得把整个程序 Jar 重新存入 Docker 镜像中,然后在推送和拉取过程中,每次都得推一个大的镜像或者拉取一个大的镜像来进行传输,感觉非常不方便。

二、了解 Docker 分层及缓存机制

1、Docker 分层缓存简介

Docker 为了节约存储空间,所以采用了分层存储概念。共享数据会对镜像和容器进行分层,不同镜像可以共享相同数据,并且在镜像上为容器分配一个 RW 层来加快容器的启动顺序。

在构建镜像的过程中 Docker 将按照 Dockerfile 中指定的顺序逐步执行 Dockerfile 中的指令。随着每条指令的检查,Docker 将在其缓存中查找可重用的现有镜像,而不是创建一个新的(重复)镜像。

Dockerfile 的每一行命令都创建新的一层,包含了这一行命令执行前后文件系统的变化。为了优化这个过程,Docker 使用了一种缓存机制:只要这一行命令不变,那么结果和上一次是一样的,直接使用上一次的结果即可。

为了充分利用层级缓存,我们必须要理解 Dockerfile 中的命令行是如何工作的,尤其是RUN,ADD和COPY这几个命令。

参考 Docker 文档了解 Docker 镜像缓存:https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

2、SpringBoot Docker 镜像的分层

SpringBoot 编译成镜像后,底层会是一个系统,如 Ubantu,上一层是依赖的 JDK 层,然后才是 SpringBoot 层,最下面两层我们无法操作,考虑优化只能是 SpringBoot 层琢磨。

e7f8d472179191a79858b605418c1c16.png

三、是什么导致 Jar 包臃肿

从上面实验中了解到之所以每次编译、推送、拉取过程中较为缓慢,原因就是庞大的镜像文件。了解到 Docker 缓存概念后就就产生一种想法,如果不经常改变的文件缓存起来,将常改动的文件不进行缓存。由于 SpringBoot 项目是经常变换的,那么应该怎么利用缓存机制来实现呢?如果强行利用缓存那么每次打的镜像不都是缓存中的旧的程序内容吗。

所以就考虑一下应用 Jar 包里面都包含了什么文件, Java 的哪些文件是经常变动的,哪些不经常变动,对此,下面将针对 SpringBoot 打的应用 Jar 包进行分析。

1、解压 Jar 包查看内容

显示解压后的列表,查看各个文件夹大小

$ tree -L 3 --si --du

.

├── [ 74M] BOOT-INF

│ ├── [2.1k] classes

│ └── [ 74M] lib

├── [ 649] META-INF

│ ├── [ 552] MANIFEST.MF

│ └── [ 59] maven

└── [ 67] org

└── [ 38] springframework

可以看到最大的文件就是 lib 这个文件夹,打开这个文件夹,里面是一堆相关依赖 Jar,这其中一个 Jar 不大,但是一堆 Jar 组合起来就非常大了,一般 SpringBoot 的项目依赖 Jar 大小维持在 40MB ~ 160MB。

6fcea7b6ed088308d27f7107be179260.png

在看看 org 文件夹,里面代码加起来才几百 KB。故此 SpringBoot 程序 Jar 包就是这些 Classes 文件和依赖的 Jar 组成,这些依赖 Jar 总共 74 MB,几乎占了这个应用 Jar 包的全部大小。

41c23227f82955802467841b338cb703.png

2、解决臃肿的新思路

如果一个 Jar 包只包含 class 文件,那么这个 Jar 包的大小可能就几百 KB。现在要探究一下,如果将 lib 依赖的 Jar 和 class 分离,设置应用的 Jar 包只包含 class 文件,将 lib 文件夹下的 Jar 文件放在 SpringBoot Jar 的外面。

当我们写一个程序的时候,常常所依赖的 Jar 不会经常变动,变动多的是源代码程序,依赖的 Jar 包非常大而源代码非常小。仔细思考一下,如果在打包成 Docker 镜像的时候将应用依赖的 Jar 包单独设置一层缓存,而应用 Jar 包只包含 Class 文件,这样在 Docker 执行编译、推送、拉取过程中,除了第一次是全部都要执行外,再往后的执行编译、推送、拉取过程中,只会操作改动的那个只包含 Class 的 Jar 文件,就几百 KB,可以说是能够瞬间完成这个过程。所以思考一下,如何将 lib 文件夹下的依赖 Jar 包和应用 Jar 包分离开来。

9d381d7684e42a570a264756360ecc6f.png

3、如何解决 lib 和 class 文件分离

经过查找很多相关资料,发现 SpringBoot 的 Maven 插件在执行 Maven 编译打 Jar 包时候做了很多事情,如果改变某些插件的打包逻辑,致使打应用 Jar 时候将 lib 文件夹下所有的 Jar 包都拷贝到应用 Jar 外面,只留下编译好的字节码文件。

将这几个 Maven 工具引入到项目 pom.xml 中

org.apache.maven.plugins

maven-jar-plugin

true

lib/

org.springframework.boot

spring-boot-maven-plugin

nothing

nothing

org.apache.maven.plugins

maven-dependency-plugin

copy-dependencies

prepare-package

copy-dependencies

${project.build.directory}/lib

执行 Maven 命令打包 Jar

$ mvn clean install

当 Maven 命令执行完成后,查看 target 目录如下图:

fb21d1f81aaf1674c5efcbd14d7577c8.png

然后测试下这个 Jar 文件是否能正常运行

$ java -jar springboot-helloworld-0.0.1.jar

然后看到运行日志,OK!下面将继续进行 Dockerfile 改造工作。

四、聊聊如何改造 Springboot 编译 Docker 镜像

84ab5c45e8b60da94975b05089985d51.png

项目 Github 地址:https://github.com/my-dlq/blog-example/tree/master/springboot-dockerfile

1、修改 Dockerfile 文件

这里修改上面的 Dockerfile 文件,需要新增一层指令用于将 lib 目录里面的依赖 Jar 复制到镜像中,其它保持和上面 Dockerfile 一致。

FROM openjdk:8u212-b04-jre-slim

VOLUME /tmp

COPY target/lib/ ./lib/

ADD target/*.jar app.jar

RUN sh -c 'touch /app.jar'

ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

ENV APP_OPTS=""

ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

这里新增了一层指令,作用为将 lib 文件夹复制到镜像之中,由于 Docker 缓存机制原因,这层一定要在复制应用 Jar 之前,这样改造后每次只要 lib/ 文件夹里面的依赖 Jar 不变,就不会新创建层,而是复用缓存。

2、改造 Docker 镜像后的首次编译、推送、拉取

在执行编译、推送、拉取之前,先将服务器上次镜像相关的所有资源都清除掉,然后再执行。

(1)、编译

$ time docker build -t registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1 .

Sending build context to Docker daemon 223.2MB

Step 1/8 : FROM openjdk:8u212-b04-jre-slim

8u212-b04-jre-slim: Pulling from library/openjdk

743f2d6c1f65: Already exists

b83e581826a6: Pull complete

04305660f45e: Pull complete

bbe7020b5561: Pull complete

Digest: sha256:a5bcd678408a5fe94d13e486d500983ee6fa594940cbbe137670fbb90030456c

Status: Downloaded newer image for openjdk:8u212-b04-jre-slim

---> 7c6b62cf60ee

Step 2/8 : VOLUME /tmp

---> Running in 529369acab24

Removing intermediate container 529369acab24

---> ad689d937118

Step 3/8 : COPY target/lib/ ./lib/

---> 029a64c15853

Step 4/8 : ADD target/*.jar app.jar

---> 6265a83a1b90

Step 5/8 : RUN sh -c 'touch /app.jar'

---> Running in 839032a58e6b

Removing intermediate container 839032a58e6b

---> 5d877dc35b2b

Step 6/8 : ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

---> Running in 4043994c5fed

Removing intermediate container 4043994c5fed

---> 7cf32beb571f

Step 7/8 : ENV APP_OPTS=""

---> Running in b7dcfa10458a

Removing intermediate container b7dcfa10458a

---> b6b332bcf0e6

Step 8/8 : ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

---> Running in 539093461b59

Removing intermediate container 539093461b59

---> d4c095c4ffec

Successfully built d4c095c4ffec

Successfully tagged registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

real 0m22.983s

user 0m0.051s

sys 0m0.540s

(2)、推送

$ time docker push registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

The push refers to repository [registry.cn-beijing.aliyuncs.com/mydlq/springboot]

c16749205e05: Pushed

7fef1a146748: Pushed

a3bae74bbdf2: Pushed

9544e87fb8dc: Pushed

feb5d0e1e192: Pushed

8fd22162ddab: Pushed

6270adb5794c: Pushed

0.0.1: digest: sha256:e2f4db740880dbe5338b823112ba9467fedf8b27cd75572611d0d3837c80f157 size: 1789

real 0m30.335s

user 0m0.052s

sys 0m0.059s

(3)、拉取

$ time docker pull registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

0.0.1: Pulling from mydlq/springboot

743f2d6c1f65: Already exists

b83e581826a6: Pull complete

04305660f45e: Pull complete

bbe7020b5561: Pull complete

de6c4f15d75b: Pull complete

7066947b7d89: Pull complete

e0742de67c75: Pull complete

Digest: sha256:e2f4db740880dbe5338b823112ba9467fedf8b27cd75572611d0d3837c80f157

Status: Downloaded newer image for registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.1

real 0m36.585s

user 0m0.024s

sys 0m0.092s

3、再次编译、推送、拉取

(1)、编译

$ time docker build -t registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2 .

Sending build context to Docker daemon 223.2MB

Step 1/8 : FROM openjdk:8u212-b04-jre-slim

---> 7c6b62cf60ee

Step 2/8 : VOLUME /tmp

---> Using cache

---> ad689d937118

Step 3/8 : COPY target/lib/ ./lib/

---> Using cache

---> 029a64c15853

Step 4/8 : ADD target/*.jar app.jar

---> 563773953844

Step 5/8 : RUN sh -c 'touch /app.jar'

---> Running in 3b9df57802bd

Removing intermediate container 3b9df57802bd

---> 706a0d47317f

Step 6/8 : ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

---> Running in defda61452bf

Removing intermediate container defda61452bf

---> 742c7c926374

Step 7/8 : ENV APP_OPTS=""

---> Running in f09b81d054dd

Removing intermediate container f09b81d054dd

---> 929ed5f8b12a

Step 8/8 : ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

---> Running in 5dc66a8fc1e6

Removing intermediate container 5dc66a8fc1e6

---> c4942b10992c

Successfully built c4942b10992c

Successfully tagged registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

real 0m2.524s

user 0m0.051s

sys 0m0.493s

可以看到,这次在第 3 层直接用的缓存,整个编译过程才花了 2.5 秒时间

(2)、推送

$ time docker push registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

The push refers to repository [registry.cn-beijing.aliyuncs.com/mydlq/springboot]

d719b9540809: Pushed

d45bf4c5fb92: Pushed

a3bae74bbdf2: Layer already exists

9544e87fb8dc: Layer already exists

feb5d0e1e192: Layer already exists

8fd22162ddab: Layer already exists

6270adb5794c: Layer already exists

0.0.2: digest: sha256:b46d81b153ec64321caaae7ab28da0e362ed7d720a7f0775ea8d1f7bef310d00 size: 1789

real 0m0.168s

user 0m0.016s

sys 0m0.032s

可以看到在 0.2s 内就完成了镜像推送

(3)、拉取

$ time docker pull registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

0.0.2: Pulling from mydlq/springboot

743f2d6c1f65: Already exists

b83e581826a6: Already exists

04305660f45e: Already exists

bbe7020b5561: Already exists

de6c4f15d75b: Already exists

1c77cc70cc41: Pull complete

aa5b8cbca568: Pull complete

Digest: sha256:b46d81b153ec64321caaae7ab28da0e362ed7d720a7f0775ea8d1f7bef310d00

Status: Downloaded newer image for registry.cn-beijing.aliyuncs.com/mydlq/springboot:0.0.2

real 0m1.947s

user 0m0.017s

sys 0m0.042s

可以看到在 2s 内就完成了镜像拉取

五、最后总结

由于网络波动和系统变化,所以时间只能当做参考,不过执行编译、推送、拉取过程的确快了不少,大部分用文件都进行了缓存,只有几百 KB 的流量交互自然速度比几十 MB 甚至几百 MB 速度要快很多。

最后说明一下,这种做法只是提供了一种参考,现在的微服务服务 Docker 镜像化以来,维护的是整个镜像而不是一个服务程序,所以关心的是 Docker 镜像能否能正常运行,怎么构建镜像会使构建的镜像更好用。

在生产环境下由于版本变化较慢,不会动不动就更新,所以在生产环境下暂时最好还是按部就班,应用原来 SpringBoot 镜像编译方式以确保安装(除非已大量实例验证该构建方法)。

a002a8ddfaa6c5be77ddb2d96f3534ce.gif

● CentOS7 安装 Maven

● Spring Cache 操作 Redis 实现数据缓存(下)

● Spring Cache 操作 Redis 实现数据缓存(上)

● Java人应该知道的SpringBoot For Kafka (上)

● Java人应该知道的SpringBoot For Kafka (下)

● SpringBoot 多种读取配置文件中参数的方式

● SpringBoot 操作 ElasticSearch 详解

● SpringBoot 使用 Caffeine 本地缓存

● Github推出了GitHub CLI

● (很全面)SpringBoot 集成 Apollo 配置中心

● 你知道如何成为一名靠谱的架构师不?

● Tomcat 在 SpringBoot 中是如何启动的?

● SpringBoot 深度调优,让你的项目飞起来!

● 8种经常被忽视的SQL错误用法,你有没有踩过坑?

● Java面试应该知道之深入理解Java的接口和抽象类

5a52c914c27eff91d36d659f7b6e111c.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值