eiffel-community / eiffel-remrem-generate

Apache License 2.0
8 stars 70 forks source link

Docker image fails to run with docker-compose from version 2.0.10 #156

Closed tobiasake closed 4 years ago

tobiasake commented 4 years ago

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

magnusbaeck commented 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.

tobiasake commented 4 years ago

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.

tobiasake commented 4 years ago

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.

tobiasake commented 4 years ago

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.

magnusbaeck commented 4 years ago

Are there any relevant differences in the docker inspect $CONTAINER_NAME output in the two cases (standalone container and container started via Docker Compose)?

tobiasake commented 4 years ago

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.

tobiasake commented 4 years ago

Reopen the issue due to I found out no properties is read when executed in Docker and Kubernetes.

tobiasake commented 4 years ago

Found the issue in Kubernetes. Needed to modify the helm charts for the new Java base image.