I'm new to spinnaker. Since the Jhipster uses microservice and it has its own load balancer(Netflix OSS).
How could it be connected to Spinnakers load balancer?
Spinnaker does not have load balancer itself. Cloud providers, handled by Spinnaker, does.
May I link the Load balancer definition in Spinnaker docs :
Load Balancer: A Load Balancer is associated with an ingress protocol and port range, and balances traffic among instances in the corresponding Server Group. Optionally, you can enable health checks for a load balancer, with flexiblity to define health criteria and specify the health check endpoint.
AFAIK JHipster is a framework to develop microservices more than "using" them. But I'm maybe wrong.
Assuming JHipster is configuring the spring-cloud client side load balancing with Eureka, a JHipster app would work well deployed with Spinnaker with the Eureka provider enabled - the Eureka status for the JHipster app would be reflected in the Spinnaker UI as well as being used to gate the progression through a deployment pipeline (Spinnaker would not proceed with the pipeline until the app entered the UP state)
Related
I have a standard load balancer existing in our environment and looking for ways to migrate to the Azure Application gateway. What would be the best way to minimize downtime and have a smooth transition?
The only I can see is deploying the application gateway and configure it and then delete the Azure Load balancer
The easiest solution would be to put Application Gateway in front of the Load Balancer and simply use load balancer as a backend. that would be the least disruptive scenario.
After this setup is working you can configure additional backend bypassing the load balancer and remove your load balancer
I have a service fabric cluster that hosts some number of identical applications. The application has two main components - a stateless service that hosts web api (it listens on unique port number) and an actor service.
In front of it there is an application gateway instance with multisite listeners to reach proper application instance based on the url. The scale set for the service faberic cluster is set as backend pool for the application gateway.
For each application I have separate http settings with a unique backend port to reach. One of the configuration options for a listener is a health probe that check the web api health, by default on each backend node.
There is no problem when the api is deployed on each node on the backend, but when the api is deployed only on subset of nodes, for the nodes without it the health probe reports this app as unhealthy.
Is there a supported way to configure the application gateway health probe to check health only on a subset of backend nodes. For apps running on a service fabric cluster like in my case it will be strongly desired.
I recommend that you use a reverse proxy on the cluster for this. You can use the built-in reverse proxy, or Traefik for this.
This ensures that all incoming traffic is routed to the services.
It does introduce an additional network hop, so there is a performance impact.
I would like to know how I can protect my Nodejs microservices so only the API gateway can access it. Currently the microservices are exposed on a unique port on my machine and can be access directly without passing through the gateway. That defeats the purpose of the gateway to serve as the only entry point in the system for secure and authorized information exchange.
The microservices and the gateway are currently built with Nodejs and express.
The plan is to eventually deploy it on the cloud (digital ocean). I'd appreciate any response. Thanks.
Kubernetes can solve this problem.
Kubernetes manages containers where each container can be a micro service.
While connecting your micro services to your gateway server, you can choose to only allow foreign connections to your gateway server. You would have a load balancer / nginx in your kubernetes cluster that redirects request to your gateway server.
Kubernetes has many other features such as:
service discovery: each of your micro service's IP could potentially change on restart/deployment unless you have static IP for all ur services. service discovery solves this problem.
high availability & horizontal scaling & zero downtime: you can configure to have several replicas for each of your service. So when one of the service goes down there still are other replicas alive to deal with the remaining requests. This also helps with CICD. With something like github action, you can make a smooth CICD pipeline. When you deploy a new docker image(update a micro service), kubernetes will launch a new container first and then kill the old container. So you have zero down time.
If you are working with micro services, you should definitely have a deep dive into kubernetes.
I have a jhipster generated microservice gateway and application that I run in Google's GKE by using the jhipster kubernetes generator. I have istio deployed in the kubernetes cluster and not using the jhipster-registry.
When I deploy the gateway with ServiceType=Ingress, the communication between the gateway and the application works great. I am trying to get up a GKE multi-cluster ingress which load balances the application deployed in clusters in different regions.
Google has a beta tool called kubemci which sets up all the plumbing for the load balancers. However, in order to use kubemci, the gateway needs to be deployed as a NodePort instead of ClusterIP. When I deploy with ServiceType=NodePort, I get errors when trying to create entities.
The error is:
translation-not-found[Http failure response for http://store.xxxx.com/product04/api/products?page=0&size=20&sort=id,asc: 404 Not Found]
I do not get this error when the app is deployed as a ClusterIP and I access it through the istio ingress gateway. Does anyone know what I need to do get the microservices to talk to the gateway when its defined as a NodePort?
Currently I have a Service Fabric cluster with 2 stateless services hosting Asp Web APIs. While creating the cluster also appropriate Azure Load Balancers got created.
Now I would like to add Application Gateway in front of my cluster for various reasons like SSL offloading, url-routing etc.
I'd like to understand how to configure the Application Gateway correctly. I see 2 options, not sure which one is valid:
Application Gateway replaces the existing Load Balancer and points directly to SF services hosting WebApi
I keep existing LB configuration and Application Gateway points to this LB (seems like 1 LB solution too many)
Which one is correct? Any advise how to configure?
Approach 2 is what we are using, We have kept the load balancer and that is routing any request received from the Application Gateway. We found this to be easiest and simplest choice, as this involves minimum changes to be done in Application Gateway.
Your two web api's can run on every node in the VM scale set. The Azure Load Balancer is used to distribute traffic over those nodes. Targeting a single service on a single node will reduce scalability and fault tolerance.
You could use the App Gateway to translate incoming request to different ports on the Load Balancer. (E.g. direct traffic to API 1 #url ~/1/ and API 2 #url ~/2/)
Favor using load balancing rules (using all nodes) over NAT redirections (to single nodes). This way you'll have a performant, reliable system.
Solution 2 would also provide possibly to create VPN connection e.g to manage your cluster. Then no need to expose management endpoint to the public. Internal lb also brings on additional features to utilize in the future.
I would go with your first option and to implement it create / modify your ARM template so that it doesn't contain the load balancer and instead contains the application gateway.
Here is a link to the quick starts for ARM templates which you can use. There isn't an out of the box example for service fabric with a gateway but it will give you a great starting place.
link