We would like to use Spring Cloud Gateway to implement a CloudFoundry Route Service.
In short: every request coming in to the 'Route Service' needs to be forwarded to a url defined as a Request Header (X-CF-Forwarded-Url). The request can be modified/blocked by the 'Route Service' id required.
From what I see (and as the name implies) Spring Cloud gateway is only able to proxy a request. Is it possible to do something like that?
Why 'Spring Cloud Gateway'? I think it provides a very nice API and lots of thoughts have gone into it. It also just feels as a very related usecase/extension to the whole API.
Related
I have currently a doubt about how are people doing this the right way.
As of today I have a Spring Cloud Gateway microservice and behind it I have other two microservices, the security microservice is tasked in registering clients, log in, logout and validate JWT, the other microservice is one that I have mainly for CRUDS.
My problem is that I had the idea that in my Spring Cloud Gateway I was going to redirect first EVERY request to the /token endpoint in my security microservice to validate the JWT and if it's successful, reroute the request back to where it initially was requested for example "/clients".
My gateway doesn't handle anything about security or tokens that is just tasked on the other security microservice. How are people doing it these days? If i wanna go these route is it possible?
I have been looking to implement my idea but haven't found something like this or if this idea is actually bad and I should migrate my security microservice to be in the gateway somehow.
TLDR : Is it okay to use controller class in spring gateway instead of routing in config class? I want to take data from one service and then pass it the response from that service to another.
I used spring cloud gateway to create an api gateway. I have several services that need to communicate. I currently only use the gateway for routing to the first service and then the first service is going to talk to other service by itself. But this is becoming troublesome now that I have a lot of services.
I recently have learnt and practicing Microservice using Spring technology. I am currently writing a small program that has Eureka Server, Configuration Server, Gateway and Account service. I have all of my services register its instance to Eureka and have my Gateway gets its configuration from Configuration Server. After that, I got some question, should I my Account Service fetch its configuration directly from Configuration Server, or from Gateway because it can be done in both way. I think, if I decide to fetch it through Gateway, it might be better because Gateway is a load balancer, so in case if there are multiple Configuration Servers out there, I don't need to worry if any of them failed or down as Gateway can handle this for me. But, doing so, isn't I put too much weight on Gateway because it need to handle this and another requests. Furthermore, I am not sure and I can't find any information about if there is a way to load balancing Gateway or is it makes sense to do so?
Please advice and explain. Thank you.
Only user's requests from UI need to be passed via Gateway. Services should be able to fetch their configuration during startup disregarding whether gateway is online or doesn't exist at all.
Also I'd advise you to avoid registering config service in Discovery (Eureka). I suppose there is no need for your users to send requests to config service.
Along with spring cloud config and gateway documentation I'd recommend you to get familiar with these 2 books:
https://www.manning.com/books/enterprise-java-microservices
https://www.manning.com/books/spring-microservices-in-action
I'm wondering what to do with an API Endpoint when using a API Gateway. For example when you following the tutorial here: https://wiredcraft.com/blog/securing-components-in-a-microservice-context
You are using keycloak and kong (api-gateway) to secure the api. With kong you're getting an new Endpoint under http://localhost:8000/data. But the "original" express Server is still listening on http://localhost:3001/data.
That means that when a user/attacker knows the url of the "orignal" service and doesn't use the kong url (port 8000) he/she can still work with the api.
So my question is about the strategy and what to do with the original api? How could that be secured. Shall we implement the keycloak request on the api as well? But where are the benefits of kong then?
Your API gateway gives you a single entrypoint that simplifies how client applications access your services. You could add keycloak security on the gateway and not on the services behind - perhaps if you've a setup where you can block network access for clients to any services except the gateway. But even then you might still want the gateway and keycloak on the services behind.
The reason you might put keycloak on the services behind is because they are likely to need to know the identity of the user making the request. If they are going to read the token anyway then it might be most straightforward to add keycloak to them. And you'd still want the gateway to simplify life for clients. You'd then also want the gateway to forward the token to the services behind the gateway. (We're using keycloak and spring cloud gateway on the Activiti Cloud project and this is essentially how we decided to secure the services themselves with keycloak and have the gateway forward the token to them.)
I have a simple Zuul app that has a single route in the application.yml to route to my microservice. It's working.
However, what I'm looking for is a more dynamic solution where I can wire up routes dynamically, either through code or perhaps by POSTing to some Zuul endpoints during a build (possibly by using springfox and a swagger definition from microservices). I could not find an API for Zuul.
I'm somewhat aware of Eureka and that seems like a solution to abstract away the routing by doing discovery. However, I'm curious if there's a solution without introducing Eureka. If there's a way to wire up these routes in Zuul during a build vs. having to edit the application.yml every time.
Thanks in advance.
If you go for Eureka this will actually work ootb. Zuul as packaged in spring cloud will automatically expose every service using its name. So if you register a service called users in Eureka, Zuul will automatically create a route /users forwarding to the instances by default. That will only allow simple url structures but should solve your problem.
Please see the official documentation for details:
By convention, a service with the ID "users", will receive requests from the proxy located at /users (with the prefix stripped). The proxy uses Ribbon to locate an instance to forward to via discovery, and all requests are executed in a hystrix command, …
I'm actually editing a blog post about this exact topic (Routing and Filtering using Spring Cloud Zuul Server) but the source code has been available and working for some time now. Feel free to use it as a reference:
https://bitbucket.org/asimio/zuulserver
https://bitbucket.org/asimio/discoveryserver (in case routes are configured with serviceIds)
https://bitbucket.org/asimio/demo-config-properties/src (Zuul-Server-refreshable.yml where routes are dynamically updated).
Look at the refreshable Spring profile settings. This Zuul setup works with both, hard-coding routes url or discovered using Eureka.
It also acting as a Spring Cloud Config client so that routes could be dynamically updated via Git, which is also covered in another blog post: Refreshable Configuration using Spring Cloud Config Server, Spring Cloud Bus, RabbitMQ and Git.