The standard behaviour for wildfly-17 (and 18) with microprofile-health-smallrye is, that the /health endpoints are published under the management port.
Is there a way to configure it to use a different port?
That behaviour is difficult in some situations (with docker and kubernetes) to open up the management port completely, and make it accessible, for other "machines" than localhost.
Thanks in advance,
Gabriel
Jeff Mesnil answered my thread on the wildfly-user chat -> It is not possible to run health endpoint on application port. WildFly only expose them to the managment port.
Whilst I could not find a direct answer I did have a similar issue myself and implemented a solution.
I added the flag Dswarm.port.offset=100. For my thorntail set up this shifted all the port by 100.
My solution to publish metrics within a docker swarm, where port 9990 is not exposed, was to write a Proxy-Servlet registered under /metrics that returns the contents of http://127.0.0.1:9990/metrics.
That way you don't expose the whole admin panel, but only the metrics part.
Related
at my firm we have a jupyterhub/lab installed and is used by roughly 70-100 people in a secure network that can only be accessed to from work. Recently the idea of hosting web-applications for short time use came up, but we are having port problems. User A is running a web application on port 5000, and User B can’t use the port because it is already in use. Port 5000 is default, it can be changed but this is not the behavior we want. Does anyone know of a way for web-applications to run on the same port in the same environment? Have looked into server-proxy but i do not really understand it. Is the way to achieve this really to be running a vm for each user securing that the port is not in use?
Any help is appreciated
I know that 'servicePort' is used by marathon-lb to identify an app. Is there any other user of this setting besides marathon-lb?
If the answer is no, why is it mandatory (omitting it well generate one for me)? I have many marathon apps which are not managed by marathon-lb, and they all take up service ports by default.
From the documentation: ""servicePort" is a helper port intended for doing service discovery using a well-known port per service. The assigned servicePort value is not used/interpreted by Marathon itself but supposed to be used by the load balancer infrastructure."
So service ports seem to have no other use other than for marathon-lb.
When you don't specify a servicePort, its as if you put in "servicePort": 0.
See closed issue here.
Here's a discussion about the re-architected networking API.
If you look at the Jira ticket, you will see that the new API model lets you define services without servicePorts at all.
By default, applications in wildfly are deployed to localhost:8080/app. How to deploy application on dedicated port, i.e. open it on localhost:8282 without application name ending?
I need to change the port for certain application, not the default port.
I have not tried this, but AFAICT it should be possible to:
run a single Wildfly instance listening on multiple HTTP ports. This is, in theory at least, possible (ref: https://developer.jboss.org/thread/233414?start=0&tstart=0)
Configure undertow subsystem as a reverse proxy, and proxy your app to the other port/location (ref: http://www.mastertheboss.com/jboss-server/wildfly-8/configuring-a-reverse-proxy-with-undertow). That said, I have never used undertow for a reverse proxy and as such cannot speak for whether this really works.
Once you have done this, you have effectively just turned your Wildfly instance into an overly complex application server and reverse proxy in one. Ultimately however, the app in question would still be running on both ports, but you redirect the traffic using the proxy the way you would like.
The same proxy configuration in an Apache (ref: https://httpd.apache.org/docs/current/mod/mod_proxy.html#forwardreverse or https://www.leaseweb.com/labs/2014/12/tutorial-apache-2-4-transparent-reverse-proxy/) or NGINX (ref: https://www.nginx.com/resources/admin-guide/reverse-proxy/) would be IMHO less complex and better tested in countless production scenarios.
forgive the triviality of my question. I was asked this question and I wasn't able to find a proper answer so I decided to research this myself and understand. I have spring ,maven etc background. Supposing I deployed my web app on a box 192.168.0.10 in my network, can I listen on the port say 9090 of the 192.168.0.10 and do something with it in my application itself running on tomcat7 on the usual port 8080.
What all this is supposed to do is listen on a port and display a graph on the client side based on the value received.
I was thinking using maven, I will have a jar packaged project handling the networking bit and transfer the control to the web app.Event that it's really blur in my mind.
Can anyone clarify things a little bit for me?
Thanks in advance
Why do you need a different port, effectively your web app is already callable on the port provided by tomcat. You can have various servlets each distinguished by URL, and one can return graphs. There's lots more possibilities, but I don't see any need for another port.
Just curious. When developing with Casini development server, one has an infinite number of ports. But, the production servers seem to give a particular importance to port 80.
Has that to do with a technical requirement, a convention, or both? I've checked the web but haven't been able to find a clear response so far.
Thanks for helping.
Many services have specifically-assigned ports This allows users to type, for example http://stackoverflow.com and get the website for SO, without needing to enter a port as well. This isn't a technical requirement; however, using a different port requires the user to know an extra piece of information, which must be entered into the URL every time.
When you connect to a server via TCP/IP you specify particular port you connect to. You do not connect to a server and hope that server guesses which port you would like to talk to.
So in most cases you tell browser to use protocol http, say "http://example.com/" then browser uses default port number assigned to that protocol (http) to connect to server "example.com". In this case port is 80. If for example you specify "https://example.com/" then browser looks for default port for https and then connects to port 443 instead.
So if you do not want to tell to every of your users to specify some non-default port for your service (say "http://example.com:60765/") you better use default one.
BTW there is a way to get port number your service listens to by it's protocol name (by asking a service's host's daemon at port 0) but this method seems to be rarely used (if at all).
See also other answers: default protocol numbers are assigned by IANA
It's a convention: you can use whatever port you feel like. You can look at the evolution of RFCs to see when the convention was official (http://www.faqs.org/rfcs/rfc1700.html)
You can see in the RFC 1060 (http://www.faqs.org/rfcs/rfc1060.html ) that it's the ISO Internet Protocol :)
In a production environment your web server is embedded in a server infrastructure (firewalls, proxies) protecting you against attacks from the internet. In such an environment port 80 is normally open for HTTP traffic. If you use this port there is no need to configure your server infrastructure.