GCP Cloud Build中Dockerfile的COPY命令执行失败求助

你遇到的核心问题是误解了Docker COPY指令的作用范围：COPY是从本地/Cloud Build的构建上下文目录复制文件到容器内，而你在容器里通过mvn package生成的jar包是存放在容器内部的/app/my-project/target/目录，不属于构建上下文，所以Cloud Build执行COPY时根本找不到这个文件。

本地构建能成功，大概率是因为你本地之前执行过mvn package，构建上下文里已经有target/目录，COPY直接用了本地的jar；但Cloud Build的构建上下文是从Git仓库拉取的，而target/通常在.gitignore里被排除，所以构建上下文里没有这个目录——即使你加了.cloudignore的!target/也没用，因为.cloudignore是用来调整构建上下文的文件筛选，而你本来就没把target/提交到Git，构建上下文里根本不存在这个目录，自然无法通过!指令包含。

最合理的做法是使用Docker多阶段构建，把代码构建和应用运行的环境分离，既避免在运行容器里冗余安装Maven，也彻底解决文件路径的问题：

修改后的Dockerfile #

# 第一阶段：构建Jar包（仅用于编译，最终不会包含在运行镜像里）
FROM maven:3.9-eclipse-temurin-21 AS builder
WORKDIR /app
# 先复制pom.xml下载依赖，利用Docker缓存优化构建速度
COPY pom.xml .
RUN mvn dependency:go-offline -Dspring.profiles.active=stage
# 复制所有源码文件
COPY src ./src
# 执行打包命令生成Jar包
RUN mvn clean package -DskipTests=true

# 第二阶段：运行Jar包（最终的轻量镜像）
FROM openjdk:21-slim
WORKDIR /etc/my-project
# 从构建阶段复制生成好的Jar包到当前镜像
COPY --from=builder /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-Dspring.profiles.active=stage", "-jar", "app.jar"]

方案优势 #

• 构建环境和运行环境彻底分离，最终镜像只包含Java运行环境，体积更小、更安全
• 利用Docker缓存机制，修改源码时无需重复下载Maven依赖，构建速度更快
• 完全绕开构建上下文的限制，不需要处理.gitignore/.cloudignore的规则冲突

如果一定要保留原有的容器内构建逻辑，那不需要使用COPY指令，直接使用容器内部生成的Jar包即可，修改ENTRYPOINT的路径：

FROM openjdk:21-slim
WORKDIR /app
COPY . /app/my-project/
RUN apt-get update -y && apt-get install -y default-jdk maven
WORKDIR /app/my-project
RUN mvn clean compile -Dspring-boot.run.jvmArguments='-Dspring.profiles.active=stage'
RUN mvn clean package -DskipTests=true
EXPOSE 8080
# 直接引用容器内生成的Jar包路径，无需COPY
ENTRYPOINT ["java", "-Dspring.profiles.active=stage", "-jar", "/app/my-project/target/my-project-0.0.1-SNAPSHOT.jar"]

这种方式的弊端很明显：容器体积大（包含Maven等构建工具）、构建耗时久，仅适合临时调试场景。

如果后续你需要将本地某些文件纳入构建上下文，需注意：

• .cloudignore的执行逻辑是先应用.gitignore的排除规则，再叠加.cloudignore的规则
• 如果target/在.gitignore里，即使你在.cloudignore写!target/，也需要确保本地存在target/目录，且Cloud Build能访问到——但通常不建议把target/这类构建产物提交到Git，所以多阶段构建仍是最优解

内容的提问来源于stack exchange，提问作者Sael Torres-Diaz