Run docker contianer with Spring Boot App - spring

I have a problem with the spring boot app below, I need to contain a spring boot app to run it locally on mac, to do it I wrote the dockerfile shown below, the container image is generated correctly but when I put it in run I have the error below, what is it due to and what can this be?
to do it all I use the shell file below,how do i fix the error?
Error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/reportserver/report/ReportApplication has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
docker.sh:
#!/bin/bash
#define docker name
dockername=quote
#Delete all containers and all volumes
docker system prune -a
#Build of container and image
docker build -t $dockername .
#Run container
docker run --publish 8081:8081 $dockername
Dockerfile:
FROM openjdk:alpine
EXPOSE 8081
ARG JAR_FILE=target/report-0.0.1-SNAPSHOT.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

you are using and older jvm version in your docker base image openjdk:alpine java 8 I guess and you need to use java 11 at least,
use this tag openjdk:11.0.12-jre instead or search for the equivalente alpine version.
Here is a list of java versions and their class version numbers List of Java class file format major version numbers?

Looks like you are using java 11 to build the jar file in your system.
In your docker file, it is using java 8 to run the jar.
Instead do this to your Dockerfile.
FROM openjdk:11-slim
EXPOSE 8081
ARG JAR_FILE=target/report-0.0.1-SNAPSHOT.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
From the official github docs, openjdk still doesnot fully support alpine as a base OS. "-slim" version will use debian instead.
The OpenJDK port for Alpine is not in a supported release by OpenJDK, since it is not in the mainline code base. It is only available as early access builds of OpenJDK Project Portola. See also this comment. So this image follows what is available from the OpenJDK project's maintainers.
You can go through the list of tags and their details at the below link.
https://github.com/docker-library/docs/blob/master/openjdk/README.md#supported-tags-and-respective-dockerfile-links

Related

Unable to create .exe using GraalVM docker image in Windows

In Windows 10 environment, with IntelliJ Idea, I have a sample Spring Boot application created with bootify, called Bootifytwo, which is located in the C:\CODIGO\IDEA_PROJECTS\bootifytwo folder.
In the pom.xml of said application I have the following dependency configured:
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
</plugin>
My intention is, using GraalVM, to get to generate the bootifytwo.exe and be able to run it correctly.
To do this, I have downloaded the following Docker image with GraalVM from the Oracle repositories; and performed the following commands:
docker pull container-registry.oracle.com/graalvm/community:ol8-java17-22.3.0-b1
docker images
docker run -it --rm container-registry.oracle.com/graalvm/community:ol8-java17-22.3.0-b1 bash
java -version
gu install native-image
native-image --version
Everything is working fine until I try to change to my project folder.
As long as I canĀ“t change to my project folder (cd C:\CODIGO\IDEA_PROJECTS\bootifytwo) I can't create the .exe with the following:
.\mvnw native:compile -Pnative
And finally locate myself in the target folder (cd C:\CODIGO\IDEA_PROJECTS\bootifytwo\target) and launch the desired bootifytwo.exe
I would appreciate help in this complex path. (I don't know if I need to define the GRAALVM_HOME variable, or map a volume...)
The solution to generate the .exe was:
Copy the app folder to (future) volume destination:
In my case:
C:\CODIGO\IDEA_PROJECTS\bootifytwo to C:\Volumenes-Docker\vol-graalvm-one\bootifytwo
Then launch the following commands:
docker run --name container-graalvm-one -v "C:\Volumenes-Docker\vol-graalvm-one:/app" -it container-registry.oracle.com/graalvm/community:ol8-java17-22.3.0-b1 bash
gu install native-image
cd bootifytwo
. ./mvnw native:compile -Pnative
Then, I was able to launch the app with:
./bootifytwo
But fails in the connection with my DB (that also was "inside" another docker/postgres container)

Application has been compiled by a more recent version of the Java Runtime (class file version 55.0), this versions up to 52.0

I am trying to run the docker image in AWS cloud so in the local ,compiled the application with jdk-11.0.1 and written docker file like this;
Please note that I have not installed any JDK in AWS ec2 instance because I have already included adoptopenjdk/openjdk11:latest image in the final image..
FROM adoptopenjdk/openjdk11:latest
ADD target/demo-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]
EXPOSE 8080
1)create the docker image
2)pushed the docker image to docker hub
3)when I run the docker container then getting below error.
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/example/demo/DemoApplication has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Most probably java got updated in local so you are compiling with a different version than you think. Or the local version is different than "adoptopenjdk/openjdk11:latest".
I suggest you use a multi-stage build so that your classes are always compiled against the same java version.
How you write your build stage depends on your environment so I don't have enough information to post an example. But basically you need to replicated everything you do in local inside the build stage. Then you just copy the jar to the last stage. And this will always work.
Try changing your openjdk version to latest i.e FROM:openjdk:12 work for me as i am using latest java version, use respective openjdk versions to match at runtime
To avoid this kind of issue It is recommend to be very specific about the images.
i.e. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine
For this kind of best practices I would suggest to go through this article I found while looking for the solution.

Quarkus Building a Native Executable NoSuchFileException: /project

I followed the steps from build quarkus native executable.
1.Bootstrapping the project:
mvn io.quarkus:quarkus-maven-plugin:0.11.0:create \
-DprojectGroupId=org.acme \
-DprojectArtifactId=getting-started \
-DclassName="org.acme.quickstart.GreetingResource" \
-Dpath="/hello"
2.Use docker in minishift
minishift start
eval $(minishift docker-env)
3.Generate package:
mvn package -Pnative -Dnative-image.docker-build=true
failed with the error trace below:
[INFO] [io.quarkus.creator.phase.nativeimage.NativeImagePhase] docker run -v /Users/.../quarkus/getting-started/target:/project:z --rm swd847/centos-graal-native-image-rc12 -J-Djava.util.logging.manager=org.jboss.logmanager.LogManager -H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy$BySpaceAndTime -jar getting-started-1.0-SNAPSHOT-runner.jar -J-Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -H:+PrintAnalysisCallTree -H:EnableURLProtocols=http -H:-SpawnIsolates -H:-JNI --no-server -H:-UseServiceLoaderFeature -H:+StackTrace
Error: Invalid Path entry getting-started-1.0-SNAPSHOT-runner.jar
Caused by: java.nio.file.NoSuchFileException: /project/getting-started-1.0-SNAPSHOT-runner.jar
As requested, the tree output is shown below:
The related Issue has been resolved at Quarkus github and remote container support is here.
Quoting the resolution comment:
Building native images using a remote docker daemon has been
implemented and merged for Quarkus 1.13 (PR #14635). Just use the flag
-Dquarkus.native.remote-container-build=true instead of
-Dquarkus.native.container-build=true.
So if you using minishift or minikube just use the
new option while building.
The -Dnative-image.docker-build=true feature of Quarkus will only work with the local docker daemon.
In your case you are using the Docker daemon from Minishift and the build files because the build artifacts are not present in the Minishift VM.
UPDATE
There is now a Quarkus issue that tracks this.
I think the best way is to combine the process of creating the application image and the actual compilation into one Dockerfile.
Your Dockerfile should contain 3 stages
build the java app
build the native image
build the final Docker image
First stage is for the fast fail if app has compilation issues ++ to build the jar file
Second stage is to produce native image from the jar + libs via native-image command or you can use "mvn -Pnative verify" if you are using an image which contains both maven and graalvm.
Third stage is to build the final Docker image based on the compiled native image and minimal base image such as alpine or fedora-minimal
An example of building the app ++ building the native image ++ building the final Docker image - https://github.com/quarkusio/quarkus-quickstarts/blob/master/getting-started-knative/Dockerfile

wrong java version in heroku

I've created a spring boot app and would like to run it on heroku.
My app is compiled using java 9.
As I'm deploying it to heroku using the CLI plugin I'm getting
Exception in thread "main" java.lang.UnsupportedClassVersionError: io/safeblocks/firewall/FirewallApplication has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Clearly this means java versions mismatch. I added the system.properties file to my resources folder with the property java.runtime.version=9 as explained but still getting the same error.
As I run the command heroku run java -version --app myApp I'm getting:
openjdk version "1.8.0_171-heroku"
OpenJDK Runtime Environment (build 1.8.0_171-heroku-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)
So it seems heroku is still not picking up the required java version.
Any ideas?
I see you added the system.properties file to your resources folder, I did the same mistake. The file system.properties must be placed under the root folder of your project.
The content of your file is correct:
java.runtime.version=9
After you moved the file to the root folder, commit your changes and do:
git push heroku master
Everything should be fine then.

Does it make sense to install the runtime on docker?

I'm considering deploying some apps on docker (aws beanstalk being the provider). Going though various resources I've found it's recommended to use a base images, in my case the official golang image but I'm wondering why would you need the runtime installed (i.e. Golang) on the container. Isn't the binary all you should deploy on the docker container?
I'm not a docker aficionado but in general, the Go runtime is compiled into your binary, and you don't need anything but that. The Go image includes the SDK, and is not the runtime. It's only useful if you want to build your app in the container. Otherwise you don't need it.
From that image's doc: The most straightforward way to use this image is to use a Go container as both the build and runtime environment.
So maybe it's a Docker pattern to just build your source on the image, or it's just a habit some people have from interpreted languages. Personally when I'm deploying Go applications (not via docker) I build an artifact on a CI machine and that's what I'm deploying, not the source.
I prefer to statically compile and then build a minimal container with only the user-space you need, here is an example.
I personally like to build inside the official container and then copy the binary to my deployment container, I inject docker into my build container with something like this
docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):$(which docker)
That way I build my docker container within my build container and just add the binary with a Dockerfile ADD

Resources