In my current project we deploy our applications in an application server and provide load balancing via an Apache httpd server deployed in the DMZ. I'm in the early stage of considering the move to Spring Cloud and while studying it, I came across Zuul as an API Gateway providing reverse proxing, routing and load balancing. Here are my questions:
1) Is Zuul a replacement for an httpd server for the functions described above? (there are probably other functions that the httpd server might supply that Zuul can't, but I'd like to keep the answers limited to reverse proxy, routing and load balancing if possible)
2) Is it redundant to have Zuul front-ended by an httpd server? Or are there benefits of doing this?
Thank you in advance for your answers.
Related
I have a cluster on AWS installed via kops. Now I need to expose a WebSocket service (with security enabled, the wss://) to the outside world. There are different ingress controllers, nginx, traefik, ELBs, ALBs. Which one is the suggested and:
easy to deploy and config
support http://, https://, ws://, and wss://
In my opinion this question is opinion based and too broad. Please try to avoid such questions as there is not one solution that is the best.
I was able to find plenty resources about nginx and websockets. I do not have production experience with configuring this, but I think you might find this helpful.
NGINX is a popular choice for an Ingress Controller for a variety of
features:
Websocket, which allows you to load balance Websocket applications.
SSL Services, which allows you to load balance HTTPS applications.
Rewrites, which allows you to rewrite the URI of a request before sending it to the application.
Session Persistence (NGINX Plus only), which guarantees that all the requests from the same client are always passed to the same
backend container.
Support for JWTs (NGINX Plus only), which allows NGINX Plus to authenticate requests by validating JSON Web Tokens (JWTs).
The most important part with nginx is the annotation - which specifies which services are Websocket services. Some more information about usage and configuration. Also useful tutorial about configuration of nginx ingress, although it is about GKE it might be useful.
Context
I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".
To name just a few of the options for service discovery that I've considered:
AWS Route 53 Service Registry
Kubernetes
Hashicorp Consul
Spring Cloud Netflix Eureka
Specifics Of My Stack
I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.
Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.
Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.
However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.
My Own Assessment Of Pros/Cons
AWS Route 53 Service Registry
Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).
Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.
AWS native, no managing service registries or extra "moving parts".
Spring Cloud Eureka
Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage.
Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.
I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.
Questions
If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.
Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?
Possible Challenges I Anticipate
We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.
Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...
Final Note
Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.
Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.
Is is right to set up the architect by using Keepalived and SpringCloud Zuul (work as gateway)?
Previously our architect is Keepalived + Nginx + Tomcat as shown below.
For now, we plan to use SpringCloud, nginx will be replaced by SpringCloud Zuul since Zuul (Ribbon) has similar functions as Nginx and we don't have very high concurrent requests. The new architect shows below
The questions are:
Is this design OK or any better designs?
Keepalived has to use IP points to SpringZuul, is it possible to use serivce name? If yes, what addtional softwares should be used?
What is the simplest solution to integrate Akka HTTP service with / into Lagom?
I have two services - akkahttp:8000 and lagom:9000, they are serving methods for Angular application. It would be great to have one endpoint for all the services - x:8888 for x:8888/akkahttp and x:8888/lagom.
This problem is often solved by using some kind of reverse proxy server that faces clients and forwards traffic to your Akka HTTP and Lagom services over an internal network.
Popular reverse proxy solutions include:
HAProxy
nginx
AWS Application Load Balancer (for AWS deployments)
Lightbend ConductR is the recommended and supported deployment environment for Lagom and Akka based services. It includes a built-in, HAProxy-based dynamic proxy that supports this kind of configuration.
Currently our application uses a hardware load balancer for SSL termination. We are beginning to implement a new architecture that breaks the one big application into a set of smaller ones, likely using the Netflix & Spring Cloud tools.
As we look at Zuul one of the questions from the operations team is where are people usually terminating the SSL connections when having lots of connections (and Zuul services)? We did in the load balancer years ago due to the CPU costs of terminating the SSL on the single application server, but if we deploy a set of services on multiple machines does that remove that concern?
So where are people terminating their SSL when using Zuul?
Thanks,
Chris
We have been struggling with this same question. I hate to put yet another proxy in front of Zuul. If it really is an edge service and can handle global load balancing and other concerns I would think that Zuul is the likely place to handle SSL.
For now we are going to use an F5 because we have them available. You could also use a HAProxy software load balancer, NGinX or Apache.
If you are using Zuul as proxy, what's wrong terminating tls/ssl at zuul? (Assuming all requests goes thru zuul).