Separate binding/port config for non application endpoints

[kenfinnigan]

Description
Once #13144 is complete, add the ability for the non-application endpoints to be configured as local binding only and a separate port.

A separate port can be defined without local binding, but local binding requires a separate port to be configured.

If either of these items are specified in the configuration, they should be ignored in development and test.

When a different port is specified, the Vert.x HTTP server will redirect all traffic that doesn't include the \q framework root prefix to that endpoint. There should be nothing served at \ of the framework endpoint server

[gastaldi]

Is this a duplicate of #7893?

[kenfinnigan]

We could probably close that one as this makes it apply to all non application endpoints and not just metrics/health

[rverma-dev]

Is there any update on this?

[kenfinnigan]

Not at present no

[sirAlexander]

@kenfinnigan now that #13144 is closed, any word on this?

[kenfinnigan]

I'm not aware of any. It's not something I'm working on, but we'd be happy for contributions from the community for it

[vsevel]

hi, is this likely to be done at some point? thanks.

[kenyee]

Seconding this...was looking for a way to move the /metrics/health endpoints to different ports and followed the trail here.

Micronaut has this feature and it's not a bad idea IMHO. It lets you segregate APIs more easily...

[KarlScheibelhofer]

This would be a very useful feature, because you want only the application endpoints exposed to your clients. Health, metrics and similar are strictly internal. If they are available on a separate port only, you do not have to worry when you deploy to kubernetes. You would expose and route port 8080 only. Done. Easy to get right, hard to get wrong.

If you have health and metrics on endpoints on the same port, however, you have to filter these endpoints carefully. If you don't care they are exposed by default. That is easy to miss. It is rather likely that people get this wrong sometimes. With different ports it is rather hard to get this wrong unintentionally.

For large scale deployments I consider this an essential feature to get them robust and secure.

[PixelJonas]

+1

If you use the same Port for your application and metrics/health you also use up the same ConnectionPool, right?
If the ConnectionPool of your application is exhausted, you'll also not be able to respond to live/readiness, resulting in the application being killed and restarted. Most likely the application is just not "ready" anymore and needs some time to process and not be killed.

In a recent scenario on the production side, this led to a cascade of services shutting each other down.

[ccarv]

Another use case (perhaps an edge case) for separating this configuration:

The cloud service provider that we use requires an HTTP health check endpoint to be available to properly load balance across our containers. This was one of the challenges we faced when going to production with a Quarkus-written application. Our Spring microservices don't have this problem.

[kkcmadhu]

is this feature on cards any time soon?

[rossbrigoli]

any updates on this? Or are there at least, any plans to include this in the roadmap?

[kenyee]

🎉 Been waiting for this for a while 😄
Looks like it'll make it into Quarkus 3 alpha 7? (alpha 6 was released before this)

[kenyee]

Ended up in the just released today Quarkus 3.0.0.Beta1