Docker化Kotlin Spring Boot应用：两种Dockerfile方案哪个正确？

首先明确一点：这两个方案都是正确可用的，但适用场景和最佳实践程度不同，下面我来逐个拆解，同时帮你解决多阶段构建遇到的“主类不存在”问题。

方案一：本地构建jar后复制到容器 #

这个方案的核心是先在本地完成Maven构建，生成target目录下的jar包，再通过Dockerfile把jar复制到轻量的JRE容器中运行。

• 优势：
  • 镜像构建速度快，因为不需要在容器中安装Maven和完整JDK，只需要复制已构建好的jar
  • 适合开发阶段快速迭代测试，本地改完代码打包后就能快速构建镜像
• 劣势：
  • 依赖本地的Maven、JDK环境，不同开发者的环境版本差异可能导致构建出的jar不一致，出现“在我这能跑，在你那不行”的问题
  • Dockerfile的复用性差，其他人拿到你的Dockerfile如果没先执行mvn install，直接构建镜像会失败

方案二：多阶段构建（更推荐的最佳实践） #

这个方案把构建和运行分成两个独立阶段，完全在容器环境中完成jar包的构建，最后只把产物复制到轻量运行容器中，是目前Docker化Java应用的标准最佳实践。

• 优势：
  • 构建环境完全隔离，不依赖本地任何开发工具，所有开发者用同一个Dockerfile构建出来的镜像完全一致
  • 最终的运行镜像依然是轻量的openjdk:8-jre-alpine，体积小、安全性高
• 你遇到的“主类不存在”问题，大概率是这几个原因导致的，对应解决方法如下：
  1. 构建阶段的jar包生成异常：
     可以在BUILD阶段的RUN mvn install之后加一句RUN ls -la /usr/src/service/target/，查看是否真的生成了预期的app-DEV-SNAPSHOT.jar，以及文件大小是否正常（如果是几KB的话，大概率是构建失败生成的空jar）。如果构建失败，检查是否是依赖下载失败、代码编译错误等问题。
  2. jar包名称不匹配：
     有时候Maven构建出来的jar名称可能和你预期的不一致（比如带版本号），你可以用通配符来复制jar包，避免名称匹配错误：

     COPY --from=BUILD /usr/src/service/target/*.jar ./app.jar
     CMD ["java", "-jar", "./app.jar"]
     

     或者在BUILD阶段输出实际的jar名称，确保COPY路径正确。
  3. Spring Boot主类配置问题：
     如果你用的是Spring Boot，需要确保pom.xml中配置了spring-boot-maven-plugin插件，这个插件会自动把主类信息写入jar的MANIFEST.MF文件，否则Java无法找到主类。典型的插件配置如下：

     <plugin>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-maven-plugin</artifactId>
         <version>你的Spring Boot版本</version>
         <configuration>
             <mainClass>你的主类全路径，比如com.example.Application</mainClass>
         </configuration>
         <executions>
             <execution>
                 <goals>
                     <goal>repackage</goal>
                 </goals>
             </execution>
         </executions>
     </plugin>
     

总结 #

方案一适合快速开发测试，但存在环境一致性问题；方案二是更规范的生产级实践，解决环境一致性问题的同时保持镜像轻量。你只需要排查上述几个点，就能解决多阶段构建中的“主类不存在”错误。

内容的提问来源于stack exchange，提问作者Idir Ouhab Meskine