We run Zuul/Spring Boot Admin/Spring Config Server/Eureka Server all on the same server. In the process of upgrading to latest Spring Boot(to pass our Veracode scan), we had multiple roadblocks and now trying to figure out my options. Below are some options we tried
Upgraded the vulnerable transitive dependencies(of Spring Boot 2.2.13.RELEASE) without upgrading Spring Boot. Ended up with either compilation or runtime issues
Upgraded to 2.6 and made respective Cloud Config changes successfully, and had to specify Zuul with version 2.2.10.RELEASE as Maven BOM won't bring this anymore. Ended up with errors mentioned in Zuul Forwarding error, Load balancer does not have available server for client. we have yet to try out solution mentioned in this post, but, hesitant to do this
Upgraded to 2.6 and converted Zuul routes to Spring Cloud Gateway. This apparently won't work as Eureka doesn't work with Webflux and Gateway needs Webflux. Ended up with errors mentioned in Could not initialize Eureka servlet context
Hoping for potential solutions that meet the following two desires
Still run Eureka and Zuul/Gateway on same server - Just to avoid infrastructure changes at this point
Do not want to specify the URLs of services i.e instead use Eureka to get list of instances/servers. If we put complete URL for Zuul my-service.routes.path, it seem to work. Also, there are other solutions which are suggesting the same to specify comma separated instances/urls which I want to avoid.
We are very aware that Ribbon and Zuul are no longer supported. That said, are we missing any other option ?
Vulnerable deps:
xstream 1.4.15
thymeleaf-spring5-3.0.12.RELEASE.jar (This was the one we couldn't upgrade. Rest of them we could add as direct dep and bump the version)
spring-beans-5.2.12.RELEASE.jar
Related
What is meaning of (https://www.keycloak.org/archive/downloads-17.0.1.html)
Keycloak: Distribution powered by Quarkus
Keycloak WildFly (deprecated): Distribution powered by WildFly
When i see documentation it says:
The default distribution of Keycloak is now powered by Quarkus, which brings a number
of breaking changes to you configure Keycloak and deploy custom providers.
For more information check out the Quarkus Migration Guide.
The WildFly distribution of Keycloak is now deprecated, with support ending June 2022.
We recommend migrating to the Quarkus distribution as soon as possible.
However, if you need to remain on the legacy WildFly distribution for some time,
there are some changes to consider
I am using Wildfly as application Server where projects are deployed.
Shall this means i use Wildfly distribution of Keycloak only whose support is ending June 2022.
or
Does this mean that Keycloak use Wildfly underneath and not use that anymore and quarkus is used? (now here can quarkus distribution work fine with wildfly settings we currently have)
Unfortunately, it has nothing to do with WildFly anymore. Until recent versions, the Keycloak was being packaged as a Java EE archive file (or as WildFly module) that you could deploy into WildFly application server.
Quarkus on the other hand is a framework to develop cloud native Java applications. It's runtime relies on many open source projects for underlying services (e.g. Vertx, SmallRye projects, etc.) and has a completely different architecture. As part of such a migration, Keycloak is now being packaged as an standalone java application (that is a typical output for an app developed using Quarkus) and contains all its dependencies. So there is no deployment/installation on WildFly anymore.
Quarkus applications are being designed by default to be run on cloud environments like Kubernetes. So you may also require to consider if you can benefit from this if you have such an infrastructure in your organization (however it's not mandatory and you can just run it as a normal java app on your server). But you can definitely not use your WildFly specific configurations (e.g. the Keycloak subsystem or OpenID subsystem) anymore.
You can find more details here.
Quarkus is a variation of Wildfly that is packaged in such a way as to make containerization (i.e. Docker, Kubernetes, etc.) much easier. Applications written for Wildfly (and JEE in general) can be made to run in Quarkus quickly.
Wildfy 25 and above include OIDC functionality internally. Therefore, you don't need to install the Keycloak extensions like you used to. And Keycloak, as of version 15, is based on Quarkus too. Because of this there is a build phase of the installation that lets you set many of the options before the run phase. For example, I used to setup a data source in the standalone.xml for my database. Now, I use the resources.properties to setup my database for Keycloak. The concepts are similar.
If you're using a version of Wildfly less than 25 then you'll still want the Keycloak adapter.
I know that Spring Cloud at some version (3.0?) dropped direct support for some Netflix libraries like Ribbon or Hystrix. Now I'm trying to make a smooth migration of around 20 microservices running on production having some custom code extending Ribbon (and Hystrix to a lesser degree). The main goal is to upgrade from Spring Boot 2.3 to 2.6. As a consequence I need to upgrade Spring Cloud to 3.1.x, right?
My guess was to proceed with 2-step upgrade to avoid a one big-step migration:
Upgrade to Spring Boot 2.6 and Spring Cloud 3.1 while still using Ribbon and Hystrix
Make a way through a jungle of an old code and getting rid of Ribbon and Hystrix in smaller increments.
However to achieve this I'm trying to use simultanously Spring Boot 2.6, Spring Cloud with release train 2021.01 and 2 selected starters from older Spring Cloud (latest versions of these artifacts):
spring-cloud-starter-netflix-hystrix 2.2.10.RELEASE
spring-cloud-starter-netflix-ribbon 2.2.10.RELEASE
Is this possible at all? We are heavilly using Feign and Spring WebClient - client-side load-balancing must work for these. So far I found out Feign clients are not automatically integrated with Ribbon.
#spencergibb #OlgaMaciaszek - especially counting on you.
Answering my own question after receiving confirmation from Spring Cloud team by other means: this is a bad idea to try use Ribbon with Spring Cloud 2021.01 and it would require a really hard work to make it working.
So short answer is: "no".
For Spring Boot based microservices communicating with each other via load-balanced clients (with Spring Cloud LoadBalancer) which client should be used, WebClient or OpenFeign?
From what I’ve read they both support Spring Cloud LoadBalancer. I know that WebClient also supports reactive, but that is not a feature we need.
Are both clients going to continue to be supported by Spring for the foreseeable future?
From what I can see Spring seems to be pushing WebClient. However, I still see development activity going on in the spring-cloud-openfeign github repo.
OpenFeign seems to be an easier/cleaner to use way of creating the clients, but are there any drawbacks compared to WebClient?
I want to run a restapi server, a spring boot app, to kick start other docker containers inside of the same kubernetes cluster. I found these 2 packages:Spring Cloud Kubernetes and Kubernetes API Client. I am confused on what the difference between the two and which one should I use.
With Spring cloud cal version (2020.x.x), spring cloud Kubernetes comes with two implementations - Fabric8 and Kubernetes Java Client. See here.
NOTE - Prior to spring-cloud cal version spring-cloud-kubernetes used fabric8 impl
Both implementations works fine. While there are many, here is one of the blog comparing the two. In general Fabric8 seems to have more features.
I am not sure if the Spring community prefers any particular impl. Both projects are active.
Spring example here.
I too have an example using Frabric8 on github.
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html
Spring boot allows changing the web server, other than the embedded Tomcat server. Does Vertx provide similar capability?
Vert.x is implemented over netty (A lightweight event-driven network application framework).
Under the hood, starting a Vert.x HttpServer bootstraps a Netty server by default: meaning you cannot switch to another implementation.
While it should be possible to use Vertx with any web server, Vertx comes with a HttpServer in the Vert.x-Web package that can deliver static files and has routing options, role and security features and many more.
All of these are optional, yet pretty easy to use/implement if you follow the documentation. Also see all the other available modules.
If you use the Vertx webserver module you don't need a container like Tomcat, you can deploy a fat-jar and start that like any java application.
You could as well use nginx as a reverse proxy in front of vertx. This setup gives you more flexibility and you can use the full power of nginx for serving static files, your ssl configuration, gziping etc.