Jib 构建镜像问题从定位到深入分析
欢迎访问我的 GitHub
这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos
问题简述
通过 Jib 插件将 SpringBoot 工程制作成 Docker 镜像成功，但是运行镜像的时候报错 (Could not find or load main class ${start-class}) ，今天来一起分析这个问题，希望能帮读者跳过小坑。
关于 Jib 插件
在 Maven 工程中可以使用 Jib 插件将当前 Java 工程构建成 Docker 镜像，详情请参考：
环境信息
操作系统：macOS Mojave 10.14.6 (18G103)
JDK：10.14.6 (18G103)
Docker：10.14.6 (18G103)
SpringBoot：2.1.8.RELEASE
Jib 插件版本：1.6.1
源码下载
为了重现问题，我将出现问题的 SpringBoot 工程上传到 GitHub，地址和链接信息如下表所示：
这个 git 项目中有多个文件夹，本章的应用在 jib-error-demo 文件夹下，如下图红框所示：
问题：
在 pom.xml 文件所在目录执行命令 mvn clean compile -U ，镜像可以构建成功，但是控制台输出了警告信息，如下图：
尝试用此镜像创建容器，行命令 docker run --name=test bolingcavalry/hellojib:0.0.1-SNAPSHOT ，报错如下：
docker ps -a 查看容器信息如下，只能看到状态是"退出"，别的没啥了：
不甘心，用命令 docker ps -a --no-trunc 查看未截断的容器信息：
这次有新发现，容器启动时执行命令是 java -Xms4g -Xmx4g -cp /app/resources:/app/classes:/app/libs/ ${start-class}* ，怪哉！这个 ${start-class} 是什么？我们来看一个正常镜像的启动命令：
如上所示， com.bolingcavalry.jiberrordemo.JibErrorDemoApplication 是 main 方法所在类，此命令可以正常运行 JibErrorDemoApplication 类的 main 方法；
小结问题：容器启动时执行 java 命令，把 ${start-class} 作为参数传给 java，导致 java 无法处理此参数，所以进程报错，导致容器退出；
问题原因
此问题的原因很简单： java 工程中带有 main 方法的类不止一个 ，去查看 jib-error-demo 工程的代码，发现 Utils.java 中果然有个 main 方法：
将上述 main 方法删除掉，再构建镜像并运行容器，证实问题已经解决。
另一种解决问题的方法
如果不想动 Utils 类的代码(也许 jar 包中某个类带有 main 方法)，请打开 pom.xml 文件，在 jib 插件的配置中增加 mainClass 节点，节点内容是指定的 class 类，如下图红框所示：
经过上面的设置，问题也可以解决。
接下来，如果您有兴趣了解更深层次的原因，咱们一起来深度探险吧。
查找问题
这个问题在 Jib 的官方 GitHub 上是有记录的，先看第一条，地址是：https://github.com/GoogleContainerTools/jib/issues/1601 ，如下图红框所示，同样的问题，最后 issue 的发起人自己关闭了这个 issue，因为他发现这自己的项目中有两个带有 main 方法的类：
再来看看这个 issue， https://github.com/GoogleContainerTools/jib/issues/170 ，Jib 的作者 Q Chen 推测是 Spring 将 ${start-class} 这个字符串设置为 Main-Class 属性的值(个人感觉，这里说的 Spring 应该是 spring boot 的 mave 插件吧)，于是 Jib 插件在使用 Main-Class 的值得时候，拿到的就是 ${start-class} 这个字符串了：
170 这个 issue 的后续情节很有意思，Jib 作者 Q Chen 对这个问题也很纠结，如果 Java 工程中发现了多个带有 main 方法的类，Jib 究竟该如何处理呢？Q Chen 最后决定输出警告，如下图：
一起来看看这段代码吧，也就是上图中 #288，地址是：https://github.com/GoogleContainerTools/jib/pull/228/files/c8757e1f9ea47edd78df18142de7836a68f22034 ，如果 mainClass 不像一个 class 类的名称，就输出警告，这个逻辑在 Gradle 和 Maven 插件中都写入了：
最后一个问题：上面代码中的 mainClass 从哪来的？打开上图的源码，地址是：https://github.com/GoogleContainerTools/jib/blob/c8757e1f9ea47edd78df18142de7836a68f22034/jib-maven-plugin/src/main/java/com/google/cloud/tools/jib/maven/BuildImageMojo.java ，如下图红框，从方法名可以推测，该值来自构建 SpringBoot 工程的 maven 插件，所以前面 Q Chen 提到 main-class 变量的值是 Spring 修改的，应该是来自这段代码：
此时的您，如果依然意犹未尽，咱们再来巩固一下 SpringBoot 的 start-class
关于 start-class
熟悉 SpringBoot 的同学其实对 ${start-class} 并不陌生，当工程中多个类中都有 main 方法时，使用该参数来指定 SpringBoot 的启动类；
先看 SpringBoot 官方文档熟悉一下 start-class ，地址是：https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/ ，下图内容比较关键：我们设置的启动类被指定到 Start-Class 属性中，而 Main-Class 属性变成了 org.springframework.boot.loader.JarLauncher ，这才是 SpringBoot 真正的启动类：
如下图，这是个补充说明， Main-Class 属性的值被转移到 Start-Class 属性这个动作，是 maven 插件在构建 jar 的时候做的：
所以 start-class 的值是来自 main-class，再看 main-class 的值从哪里来，如下图红框所示，maven 插件会去查找带有 public static void main(String[] args) 的类：
至此，Jib 构建的镜像问题分析完毕，一个小小的问题引发了这么多学习和探索，虽然有点费时间，但是可以让人再次感受到"技术是相通的"感觉，不知道您有没有这种感觉呢？
欢迎关注 InfoQ：程序员欣宸
版权声明: 本文为 InfoQ 作者【程序员欣宸】的原创文章。
原文链接:【http://xie.infoq.cn/article/93c4ac537702b0057c4217d28】。文章转载请联系作者。
搜索"程序员欣宸"，一起畅游Java宇宙 2018-04-19 加入
前腾讯、前阿里员工，从事Java后台工作，对Docker和Kubernetes充满热爱，所有文章均为作者原创，个人Github：https://github.com/zq2599/blog_demos
评论