Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boot Dashboard / Docker / Random host ports #626

Open
eliasbalasis opened this issue Apr 15, 2021 · 10 comments
Open

Boot Dashboard / Docker / Random host ports #626

eliasbalasis opened this issue Apr 15, 2021 · 10 comments

Comments

@eliasbalasis
Copy link

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.

@martinlippert
Copy link
Member

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?

@eliasbalasis
Copy link
Author

eliasbalasis commented Apr 16, 2021

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.

@martinlippert
Copy link
Member

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.

@martinlippert martinlippert added this to the 4.11.0.RELEASE milestone Apr 27, 2021
@eliasbalasis
Copy link
Author

Thanks @martinlippert for adding this to 4.12.0.RELEASE

Let me know if you need any details.

@martinlippert
Copy link
Member

Unfortunately I have to push this out to the December release...

@martinlippert martinlippert removed this from the 4.13.0.RELEASE milestone Dec 16, 2021
@eliasbalasis
Copy link
Author

Are there any plans for this?

I suspect further investigation is still required.

@martinlippert
Copy link
Member

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.properties via server.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?

@eliasbalasis
Copy link
Author

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.

@martinlippert
Copy link
Member

@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.

@eliasbalasis
Copy link
Author

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.

@martinlippert martinlippert added this to the Backlog milestone Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants