spring boot takes like forever to start up in Openshift - spring

I'm running a spring boot 1.4.3 app in openshift origin 1.3.
It takes more than 20 minutes to bring spring bootup.
the docker base container I'm using is alpine:3.4 with opendk8-jre.
the spring boot embedded container is using default tomcat one. I've installed the haveged and set -Djava.security.egd=file:/dev/./urandom
but if I run the image itself with docker run(I'm not using openshift), it can start up..
any idea why ?

Could it be the case that you don't have a maven proxy setup and are downloading all dependencies?
If it's the case your logs likely show that you are donwloading the same deps over and over.
run this command to see the logs:
oc logs _POD_NAME_
Also, have you tried the same in OpenShift Dev Preview and got similar results?

Related

Spring Boot 2.7.8 or 3.x upgrade - Tomcat HTTP Status 404 - Not Found on Azure

I'm currently upgrading an application from Spring Boot 2.7.7 to Spring Boot 3.0.2 and hit a 404 at the tomcat.
The interesting thing is that the application works fine on my local machine, but not in the Azure Cloud.
I have the log-level set to DEBUG for org.springframework.web and with Spring Boot 2.7.7 I see the call received in the logs (on Azure) for actuator/info, whereas in Spring Boot 3 I see the application starting successfully but then no further logs.
Any ideas what it could be or what I can try out to debug further?
The problem is related to a change in Tomcat version in Spring 2.7.8 (and therefore also Spring Boot 3.x) in relation to the Java-Agent used in Docker / within Azure.
Update to the latest java-agent version in the Docker-Image:
DockerFile
FROM eclipse-temurin:17
COPY "myBuiltApplication.jar" "app.jar"
ADD "https://github.com/microsoft/ApplicationInsights-Java/releases/download/**3.4.8**/applicationinsights-agent-*3.4.8*.jar" "agent.jar"
EXPOSE 80
ENTRYPOINT [ "java", "-javaagent:agent.jar", "-jar", "app.jar"]
Make sure that no other agent is active from Azure
I had to remove the JAVA_TOOL_OPTIONS and StartupBootstrapper from the docker run:
- docker run -d --expose=80 --name myapp
JAVA_TOOL_OPTIONS=-javaagent:/agents/java/applicationinsights-agent-codeless.jar -e StartupBootstrapper=Microsoft.ApplicationInsights.StartupBootstrapper -e
I experienced the same issue with Spring Boot version 2.7.8 with the exact same behavior: Starting the app local in IDE as well as starting the docker image locally worked perfect. When running this image in Azure as an App Service no http call is going to spring. For me it looks like Tomcat has an issue as the 404 seems to be produced by Tomcat.
Downgrading to Spring Boot 2.7.7 fixed the issue again.

Running Spring Boot application but Jenkins hijacks the port

I am following the IntelliJ "Hello World" Spring Boot tutorial (https://www.youtube.com/watch?v=5kOGdZmpSDI) and when I run the application it sets up the Tomcat server on port 8080, as expected, but when I go to localhost:8080 the Jenkins login page will appear instead as it was previously ran in a Docker container.
Is there a way to check what is running on Tomcat or a way to remove Jenkins entirely?
I have already deleted all running containers and images on Docker desktop and uninstalled Docker, but this issue still persists.
Any help would be appreciated as I am new to using Spring Boot as well as Docker - thank you.
By default springboot uses port 8080,you can change the port from 8080 to someother port,you can configure this in your application.properties file
Server.port= anyportnumber
I think this is the one you are looking for!,,Hope this helps

How to containerize the spring boot application without installing docker and deploying in centos

I have a spring boot application in my local machine , i want to containerize it without installing docker in local machine and i want to deploy it in a Cent Os machine which docker has installed in an offline mode .
while i have tried to containerizing it by building an image file , it is actually looking for Docker Daemon in local and the build is getting failed.
Using GoogleContainerTools' Jib you can easily build a Docker compliant container image without Docker installed.
You need to install the Jib plugin in your pom.xml or gradle.build file.
Here is a simple example: https://www.baeldung.com/jib-dockerizing
Without Docker engine you cannot containerize the application, Docker daemon is needed for creating the container for your spring boot application in unix. You can use ECS on AWS that can create the container without docker but lot of configurations and deep knowledge is needed for that.

Intellij, Spring dev tools remote, Docker, error Unexpected 404 response uploading class files

Im trying to use Spring Boot Dev tools (Spring Remote), and automatically upload recompiled files to my docker container.
I keep receiving
Unexpected 404 response uploading class files
This is my docker file:
FROM java:8
WORKDIR /first
ADD ./build/libs/first.jar /first/first.jar
EXPOSE 8080
RUN bash -c 'touch /first/first.jar'
ENTRYPOINT ["java","-Dspring.data.mongodb.uri=mongodb://mongodb/micros", "-Djava.security.egd", "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005","-jar", "first.jar"]
This is my configuration and the configuration
And this is the error I'm receiving:
As of Spring Boot 1.5.0, devtools defaults were changed to exclude the devtools from fat jars.
If you want to include them, you have to set the excludeDevtools flag to false.
However, the devtools documentation doesn't explain how to do this. The necessary documentation is actually in the spring-boot-gradle-plugin documentation.
To do it, you can put this snippet of code in your build.gradle file:
bootRepackage {
excludeDevtools = false
}
Unfortunately, this was buggy at first and had no effect as of Spring Boot 1.5.0. The workaround was to do this instead:
springBoot {
excludeDevtools = false
}
However, I have verified that the bootRepackage approach works for Spring Boot 1.5.8 .
I got the same issues as yours while using docker-compose to compose my application ( a web service + redis server + mongo server ).
As the Spring developer tools document point out "Developer tools are automatically disabled when running a fully packaged application. If your application is launched using java -jar or if it’s started using a special classloader, then it is considered a “production application”."
I think when we running Spring Web Application inside Docker container, the developer tool is disabled then we cant remotely restart it.
Currently, I'm running my web application on the host machine and set the redis server, mongo server inside containers so I can restart the web app quickly when the code is changing in development process.
In my case I had to put the application context on the argument of the IDE RemoteSpringApplication configuration.
For example, my application root context was /virtue so I had to configure it like so:

default fabric8 microservice errors out on integration test - Waiting for container:spring-boot. Reason:CrashLoopBackOff

Deployed fabric8 in Google Container Engine with 12 core 45GB RAM. Used gofabric8 0.4.69 for deploying fabric8 on GCE.
Tried to create a microservice, but it is failing in integration testing phase throwing the following error "Waiting for container:spring-boot. Reason:CrashLoopBackOff"
Please help to resolve this.
Which quickstart were you trying?
It sounds like the application terminated. I wonder if this shows any output:
kubectl get pod
kubectl logs nameofpod
where nameofpod is the pod that is crashing.
BTW the new fabric8-maven-plugin version (3.1.45 or later) now has a nicer fabric8:run goal.
If you clone the git repository to your local file system and update the version of fabric8-maven-plugin you should be able to run it via:
mvn fabric8:run
Then you get to see the output of the spring app in your console to see if something fails etc.

Resources