Change in default Service host-port - quarkus

I'm upgrading a project that uses the kubernetes extension from quarkus 1.13 to 2.2.2.
The http Service generated in the kubernetes.yml went from using port 8080 to 80. That however did not work on minikube for me when adding a loadbalancer to expose that service for testing (minikube expose service ...). I was able to workaround by adding an override to the configuration:
quarkus.kubernetes.ports.http.host-port=8080
Is this an expected change in quarkus 2.x?

Yes, this is expected the expected behavior for 2.0.
See https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#service-port-mapping

Related

is there any way to resolve liveness probe failure issue in Kubernetes environment after upgrading to spring boot 3.0.0 from spring boot 2.7,7?

I have upgraded spring boot application from version 2.7.7 to 3.0.0.
After upgrading it is working fine on local machine and able to access all the actuator health endpoints.
But, after deploying the same code to Kubernetes cluster we are getting error as "Readiness probe failed. 404 not found".
It is not able to call health endpoints and giving 404 error.
From the pod logs we can see that application is started properly on port 8080.
Please refer following image for error.
enter image description here
We tried the same on local machine it is working fine.
We redeployed the previous build with old springboot version it is working fine.
We also tried deploying the jar in minikube environment it is working fine.We are expecting to resolve the readiness probe issue.
We are expecting to resolve this issue and start the app with springboot 3.0.0 in kubernetes environment.
Verify you actuators didn't move to a different port. In v3 there is a configuration for management port where by default the actuators are served.
https://docs.spring.io/spring-boot/docs/3.0.0/reference/htmlsingle/#actuator.endpoints.kubernetes-probes
management.server.port
Also make sure they are enabled
management.endpoint.health.probes.enabled

Spring Boot Actuator + Spring Boot Admin - Is there a way to define a custom management url?

Is there a way I can define the port for the management URLs (not the management.server.port) so that spring boot admin can identify the actuator URLs from the spring boot app for monitoring?
I'm running the spring boot app in a docker container and it's externally exposed on a different port using the Kubernetes NodePort.
If you are using service discovery for application lookup you could define the exposed management port in instance metadata. This metadata is used to build up the management URL.
More details documented here:
http://codecentric.github.io/spring-boot-admin/current/#spring-cloud-discovery-support
Handling is done in de.codecentric.boot.admin.server.cloud.discovery.DefaultServiceInstanceConverter
Example for Eureka:
eureka.instance.metadata-map.management.port=[K8S-EXPOSED-PORT]
If you are using Service Discovery, take a look into DefaultServiceInstanceConverter, try specifying the management.port property.
If you are not using Service Discovery, then take a look into de.codecentric.boot.admin.server.domain.values.Registration, you might need to use the builder apis to register your application correctly (try to set managementUrl properly). Note, you will need to do this in your client application (the one which is being monitored).

Spring Cloud Sidecar is not working as expected

Based on the documentation, the #EnableSidecar annotation acts as a proxy for non-JVM applications that wish to register in Eureka. Accordingly, the configuration to be set is:
sidecar:
port: 81 <-- Port of the non-JVM application
health-uri: http://10.135.16.50:${sidecar.port}/api/health.php <-- URI of the non-JVM application's health endpoint
home-page-uri: http://10.135.16.50:${sidecar.port}/
Once the "sidecar" is up and running, we should be able to invoke one of the non-JVM endpoints through the service registry just by using the name that the "sidecar" application used to register in Eureka. So for example, if our "sidecar" application was registered in Eureka as "php-sidecar" to proxy a PHP application with an endpoint such as:
http://10.135.16.50:81/api/microservice.php
Then we should be able to invoke the following endpoint to get to the non-JVM application (assuming "sidecar" is in "localhost" and port 8080):
http://localhost:8080/php-sidecar/api/microservice.php
However, this is not working as expected. When we request the URI just above, a request to "localhost:81" is actually issued, because somehow the "sidecar" is picking up its host URI and not the home-page-uri defined as part of the sidecar's properties.
If we run the non-JVM application locally using localhost, then everything works as expected, but this is definitively not the realistic use case.
Therefore, what am I missing in my configuration to tell Spring Cloud (Zuul in this particular case) to use the non-JVM home-page-uri and not my local host URI?
Thanks for your support.
After some research, it turns out that the sidecar must always be deployed in the same host as the non-JVM application.
After some research, it turns out that the sidecar must always be deployed in the same host as the non-JVM application.
No, You can add sidecar.ip-address = 10.135.16.50 to your yaml config file
I'm using spring-boot-starter-parent version is 1.5.6.RELEASE
working fine

How to disable tomcat 8 websocket server endpoint autodiscovery

I need to do some processing on the endpoint classes before they can be deployed and then deploy them manually. However it seems simply having a class annotated with #ServerEndpoint in my war is enough to deploy the endpoint in Tomcat and when I try to manually deploy later obviously I can't because the URL has been deployed already. Is there any way to disable the autodiscovery of endpoints?
Looking at the source for the version I'm using - 8.0.28, there's no dedicated option. The code deploying the endpoints is in org.apache.tomcat.websocket.server.WsSci. The quickest 'shurest' hack is to put my endpoints into the javax.websocket package. I elected to use their ServerApplicationConfig hook instead which serves my purposes if with some minor issues.

JBoss Fuse: Using default Jetty port for CXF endpoints

I am working on a CXF based web service in Jboss Fuse environment. Is it okay if I use the default org.osgi.service.http.port=8181 defined in the pax.web.cfg or should I always specify an explicit port in my cxf endpoints?
For the first option, my cxf endpoint would look like:
<cxf:cxfEndpoint id="myWebService.endpoint"
address="/services/WebService/1.0"
...
For the second option, it would look like:
<cxf:cxfEndpoint id="myWebService.endpoint"
address="http://0.0.0.0:{port}/services/WebService/1.0"
...
Is it allowed to use port 8181 for all my CXF web services?
It is totally possible to use default service port for web service address. Looks like only when want to apply SSL, we should do that with httpj:engine settings for server side SSL.
Link to Fuse HTTPS settings

Resources