Boot Dashboard / Docker / Random host ports
Describe the bug Running SpringBoot applications from Eclipse IDE or Spring Tool Suite 4 with Boot Dashboard on a Docker instance, runs the application with random host ports.
To Reproduce Run any SpringBoot demo application using Eclipse IDE or Spring Tool Suite 4 with Boot Dashboard on a remote Docker instance. Notice that the container port is set to 8080 but the Docker host port is set to a ephemeral value.
Hey @eliasbalasis, your observation is absolutely correct, the tooling creates a port forward automatically for the running application and chooses the port on the host machine randomly.
We haven't implemented yet a way for the user to define the port-forwarding manually. Since there can be multiple apps running in a container using the exact same port, we cannot just port-forward every application on port 8080 - therefore the random port. But I agree that this could be improved. Is there anything specific you would suggest or propose?
Thanks @martinlippert
What I am having in mind is running a set of applications that interact with each other on a remote Docker server over Boot Dashbord to reduce RAM consumption and CPU overload on developer machines.
This ideally requires fixed Docker host TCP ports as entry points for front-end access or other access of public type or any interaction among the running applications in case some have to run on the developer's machine.
Internally the applications should still be able to talk to each other using the assigned hostname as they all run under the same Docker network (sts-bootdash).
I suggest that a mechanism to control the exposed Docker host ports is introduced as part of the Maven build. Perhaps something "Boot Dashboard" could consume from the project like a Maven plugin or some kind of Maven configuration or a special "SpringBoot" property etc.
Thanks @eliasbalasis for the additional details, good to understand the use case in more detail. I will put this in the backlog for discussion and some technical investigation to see what would be the best way to support this. The enhancement request makes a lot of sense to me.
Not sure about the Maven build suggestion yet, but as said, this needs a bit of further investigation here.
Thanks @martinlippert for adding this to 4.12.0.RELEASE
Let me know if you need any details.
Unfortunately I have to push this out to the December release...
Are there any plans for this?
I suspect further investigation is still required.
Hey @eliasbalasis, unfortunately we haven't worked on this one yet and I don't know when we will be able to dive into the details here. Let's get this going now.
As far as I can see, we have two ports involved here:
- one is the port which is used by the Spring Boot app itself, e.g. configured inside of the app via
application.propertiesviaserver.port=8085(for example) - one is the port that the docker integration inside of the tooling chooses (randomly at the moment) to port-forward the application to the local machine
Ideally we should find a way to allow users to configure both ports when they use the docker integration of the dashboard to run the application. Since we cannot identify any of those ports automatically, we user would have to specify those options manually, I think.
A rather heavyweight solution for this would be to implement a custom launch config type in Eclipse, and re-use that under the hood. The benefit of this would be that this would be in-line with the way the dashboard launches local apps, but requires quite some work to realize - which seems to be heavyweight if we want to specific those ports only.
Any thoughts on this?
Users indeed need to configure both ports. However, the values of such a configuration would be primarily driven by the environment, which is controlled by Maven in our case. I don't have enough expertise to suggest the correct course of action, but I can picture some SpringBoot Maven plugin involvement in combination to some relevant tooling extension. In more detail, users could define their configuration in the Maven plugin while tooling could read this configuration and run the Docker containers accordingly.
@eliasbalasis Could you share a sample project with that config that you mentioned? Sounds like a nice idea to take that config into account automatically, if possible.
I am afraid that the configuration has quite a few moving parts which makes it hard to replicate as part of a sample project.
In principle, it is microservice containers launched with STS and talking to each other using Docker networking.
Internally the applications should still be able to talk to each other using the assigned hostname as they all run under the same Docker network (sts-bootdash).
The primary interest is control of the Docker host port which is currently ephemeral. Control of the container ports would be much welcome but it is a secondary goal in my view.
In theory, this can be supported by STS, probably using additional STS launcher options I guess.
I hope this helps you.
I will try to revive the experiment in the meantime and extract more details as it has been quite a while since last time I had to study this topic.