Closed tobiasake closed 4 years ago
Could this have been caused by #151? IIRC I tested passing environment variables (like the path to application.properties) but that's basically the only change between 2.0.9 and 2.0.10 so I'd be surprised if it was unrelated. I don't see anything in the dockerfile or it's support files that would cull the environment variables available to the program.
It is some Docker-ish functionality that forward the properties to the java application/instance. I have no clue how its handled, but it has always worked. I can check if I can figure out what needs to be changed to bring back the docker-ish forwarding of properties to the java application.
I have done some testing in different ways with the Dockerfile, java spring application properties never ends up in the java application. We have had this working with other Spring based applicaitons earlier with java base image: "fabric8/java-jboss-openjdk8-jdk:1.2"
But when I look at some old Dockerfiles(internally at Ericsson) for remrem-generate we have always used Tomcat as base image.
So it might be a Pom dependency/plugin issue/conflict in pom.xml that stops java properties to be injected to remrem-generate java application.
But its a bit strange that it works as a Tomcat webapp and not when executed in normal java execution.
I have been testing a bit more and the images seems to run fine Docker command, e.g: docker run -e server.port=8043 --expose 8043 -p 8043:8043 eiffelericsson/eiffel-remrem-generate:2.0.10 And RemRem-Generate Swagger page becomes accessible from web-browser on 8043. But when image is executed from Docker-compose then java applications don't read any application properties, not event the application.properties from resource folder inside the war file. So something strange is going on when container is executed from docker-compose.
Are there any relevant differences in the docker inspect $CONTAINER_NAME
output in the two cases (standalone container and container started via Docker Compose)?
Hi again, Got it working know. It was no issue with the image. I have same application configurations for both Docker and Kubernetes deployments and in these configurations files a port number was wrong, 8095, on the "server.port=8095" property and I expose 8080 from the container. Due to this RemRem-Generate never responded on my request. This was a bit hard to see due to the RemRem-Generate logs doesn't say that much about what configuration it uses. Maybe that is something that can be improved in the RemRem-Generate logs. I think when it is executed in Tomcat it is printed which port webserver is started, but not in this java environment.
Sorry for taken up your time for this issue.
So the issue is solved and I close this ticket.
Reopen the issue due to I found out no properties is read when executed in Docker and Kubernetes.
Found the issue in Kubernetes. Needed to modify the helm charts for the new Java base image.
Description
Docker image fails to start with docker-compose due to the java properties never reach the RemRem-generate java application inside the container. Starting RemRem-Generate has worked with version 2.0.9 and earlier versions. When I use version 2.0.10 it fails and don't use the application properties configuration from docker-compose yaml file.
This issue is stopping the deployment of remrem-generate in our docker-compose environments.
Motivation
This has worked before and should continue to work as it has worked.
Exemplification
In docker-compose yaml file it has been possible to set "environment" field with applications properties and java applications has read and used the properties: environment:
Benefits
Possible Drawbacks