Closed jdubois closed 6 years ago
I have been thinking of Traefik support for some time as well. For me Traefik is great as it can be complementary to Zuul. For example you can use Traefik eureka back-end to load balance between several zuul gateways.
However I'm not ready to move away from Zuul completely as Zuul offer many powerful API management features. Then it can be an interesting option to have Traefik powered gateway. So :+1:
I had already the first contact with traefik as k8s ingress solution and I like the light weight of it. I'm not a big fan of TOML, but if it really works well with Eureka and consul backend, it is a competitive alternative to eureka + Zuul, as both have a high resource consumption and bootup time, compared to consul + traefik.
So +1 from me
On Fri, Sep 22, 2017 at 12:16 PM Pierre Besson notifications@github.com wrote:
I have been thinking of Traefik support for some time as well. For me Traefik is great as it can be complementary to Zuul. For example you can use Traefik eureka back-end to load balance between several zuul gateways.
However I'm not ready to move away from Zuul completely as Zuul offer many powerful API management features. Then it can be an interesting option to have Traefik powered gateway. So 👍
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/6397#issuecomment-331409019, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoVc07XGuoPl6ghJjpARtnJp2LgUWdaks5sk4jwgaJpZM4Pgep2 .
The things I like in Eureka: I know it :) and it"s written in Java integrated in Spring Cloud. What I don't like: slow startup, memory leaks that require to restart the registry every month or so.
Consul is great, starts fast, integrated in Spring Cloud but written in Go. Commercial support is expensive.
The fact that the gateway is a java app does matter a lot to me as I have been able to customize or add some endpoints, filters.
And as of #5812 our gateway is also handling JWT over http cookies, what enables a great experience with uaa in general. Another point is the rate limiting. So if there will be traefik support, that solution will lack of some features our gateway currently has
On Fr., 22. Sep. 2017, 13:55 Gaël Marziou notifications@github.com wrote:
The things I like in Eureka: I know it :) and it"s written in Java integrated in Spring Cloud. What I don't like: slow startup, memory leaks that require to restart the registry every month or so.
Consul is great, starts fast, integrated in Spring Cloud but written in Go. Commercial support is expensive.
The fact that the gateway is a java app does matter a lot to me as I have been able to customize or add some endpoints, filters.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/6397#issuecomment-331426932, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoVc_5ZZY__t2jyGdpOQ7nUoAu5RIkwks5sk6AugaJpZM4Pgep2 .
Yes our gateway does much more than routing: API documentation, rate limiting, authentication... In terms of feature it's by far the best solution. Same for the JHipster Registry vs Consul: it's totally free, secured (no "enterprise version" for that), includes monitoring and better Spring Cloud support, etc. It's also easier for us to hack and improve, as it's in Java. Traefic and Consul would be an alternative stack, that has its own strengths and weaknesses.
I tested Consul this afternoon:
I would personnaly love to see a revival of our Consul support. I was thinking that one day I might manage to add consul support for the registry (obviously it would only be for the UI, the embedded Eureka server would be disabled). What about my point that you can use Traefik with Eureka : https://docs.traefik.io/configuration/backends/eureka/ as a load balancer ? @jdubois When you speak with Traefik devs can you ask them what would they recommend ?
For information, apart from eureka and consul, the spring cloud stack can be made to work with the following service discovery backends: Zookeeper (not currently supported by Traefik), etcd and kubernetes.
Great job for the initial PR !
However, I had a look at the approach taken in the PR and I have many ideas for improvements. What it does currently is generating a simple config file for Traefik which route every service to /serviceName
. IMO this is not enough to have real "gateway" functionality.
With Zuul, all routes and configuration properties (eg: timeout, retry, healthchecks) can be configured from the central config so we should be able to do the same for our Traefik gateway. I checked the docs and it is possible to configure Traefik to read its config file from consul k/v store (I think this would be the entire config file stored in one kv entry). An alternative would be to use Consul Template to dynamically update the traefik configuration from values contained in the k/v store (this would abstract the traefik config file from users).
Questions :
To answer @PierreBesson
Closing as the PR is merged :-) This should be released very soon (with a BETA tag, of course!), I'm currently doing the documentation
I am very satisfied by the Netflix stack, but it is not going fast enough for me: we've been waiting for Eureka 2 and Zuul 2 for months, and I don't see them being released anytime soon
Of course we already support Consul. What we also need is support for a Zuul competitor, so we can have a full Eureka + Zuul alternative.
Our architecture would change a bit: the current gateway would be replaced, and become a "front-end" that is served by the new gateway. Not a big change, in fact, just moving a box.
I see several alternatives: Apache (which I use for https://start.jhipster.tech ), HAProxy (I've never used it), Fabio (which is used by my current client), and Traeffic.
Traeffic seems to have a lot of traction today, and I have some interesting news about it:
-> So my goal is to have this support quite soon, is this fine with everyone?