Improve Dockerfile example to extract the application jar based on an argument #18932
Conversation
|
@glours Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
|
@glours Thank you for signing the Contributor License Agreement! |
spring-projects-issues
added
the
status: waiting-for-triage
philwebb
added
type: documentation
glours
force-pushed
the
update_dockerfile_deployment
branch
from
d15fba6 to
f1d6492
Compare
There was a problem hiding this comment.
Thanks for the PR. I understand that part of this PR is to show how docker could take care of extracting the fat jar in such a way that its content can be layered in the image. I think this makes the example less generic as described further in a comment below. Thoughts?
| ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.MyApplication"] | ||
| FROM openjdk:8-jdk-alpine AS builder | ||
| WORKDIR target/dependency | ||
| COPY ./target/*.jar . |
There was a problem hiding this comment.
There might be more than one jar in this directory. The regular build and the fat jar output. A build may also have other classified artifacts and we can't really know in advance which one is going to be the fatjar.
There was a problem hiding this comment.
Ok I was focused on the user flow experience, and try to resolve the forgetting of unzip the jar, got your point maybe I should remove this section
There was a problem hiding this comment.
Or maybe we can use a build arg with the name of the fatjar & add a command example for the docker build, wdyt?
ex:
docker build --build-arg fatjar=my-fat-jar-version-1.0.0
&
FROM openjdk:8-jdk-alpine AS builder
WORKDIR target/dependency
ARG fatjar
COPY ./target/${fatjar}.jar
RUN jar -xf ./${fatjar}.jar
There was a problem hiding this comment.
target is a usual location for Maven but I like the idea of the argument. Can we improve this so that we give the (full) path to the fat jar and then it does everything else without assuming a directory?
There was a problem hiding this comment.
yes of course, I'll update in that way 😉
| RUN jar -xf ./*.jar | ||
|
|
||
| FROM openjdk:8-jre-alpine | ||
| EXPOSE 8080 |
There was a problem hiding this comment.
I am not really a Docker expert but I don't understand why hardcoding 8080 here is something we should do. This might not be a webapp. It might be a webapp running on a different port.
There was a problem hiding this comment.
My bad, not need at all.
It's some rest of local testing, sorry 😕
There was a problem hiding this comment.
By the way the main point here was to use a jre instead of a jdk alpine image
snicoll
added
the
status: waiting-for-feedback
glours
force-pushed
the
update_dockerfile_deployment
branch
from
f1d6492 to
2f427e7
Compare
Add stage build to unpack jar Change runtime base image by a jre-alpine Signed-off-by: Guillaume Lours <guillaume.lours@docker.com>
glours
force-pushed
the
update_dockerfile_deployment
branch
from
2f427e7 to
6acd83e
Compare
snicoll
removed
the
status: waiting-for-feedback
|
Hi @snicoll |
|
I actually removed it as you’ve addressed it. Thanks! |
snicoll
changed the title
|
Thank you for making your first contribution to Spring Boot. |
Add stage build to unpack jar
Change runtime base image by a jre-alpine