[Feature] Integrate Traefik into the microservice architecture

[jdubois]

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:

• There's a team at Ippon who is ready to do that support on Tuesday next week
• I'm speaking with @emilevauge (the Traeffic lead dev) on Monday next week

-> So my goal is to have this support quite soon, is this fine with everyone?

[PierreBesson]

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:

[xetys]

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 .

[gmarziou]

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.

[xetys]

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 .

[jdubois]

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:

• my whole stack consumed much more memory than with Eureka (10 Gb wasn't enough, everything was crashing, when 8 Gb is usually largely enough). Surprising!
• Consul becomes a SPoF so you need to configure a cluster (more complex, more issues, more resources)

[PierreBesson]

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.

[jdubois]

• Yes you can use Traefic as a load balancer in front of our gateways
• My idea was to use it to replace Zuul: it has different capabilities (so that's not the same use case as the point above), and I'd first like to work on "simple" architectures. Having Traefic + Zuul is a lot more complex, not sure we should go this far -> people doing this are likely to have their own setup for this, and won't use our Docker Compose configuration

[PierreBesson]

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 :

• ‎How do we deal with security if we have no Zuul gateway ? If an OAuth server is required how do we configure applications so that security works out of the bow.
• How do we provide swagger docs ?

[jdubois]

To answer @PierreBesson

• Yes it just does a basic Zuul route opening, nothing more
• To have it configured dynamically, I think the Consul K/V store is the best solution. Then, an interesting feature of Traefik is that it also supports Eureka: should we allow the Traefik/Eureka combination? That looks strange and complex for us (if you use Eureka, you take the rest of the stack and use Zuul). So +1 for using the Consul K/V store.
• At the moment the security would be done by our "former" gateway, which is now behind Traefik. That should work technically, but it is not ideal. In the future, I would only support the OAuth2 configuration from @mraible (see #6361 ). That would solve everything and fit well with the rest of the architecture. And in that case, the former gateway would just become a static front-end, with no security -> that should be easy to do as we already have the "client only" option. And this would be served by an NGinx server.
• For Swagger docs -> either it is pushed in the new "static front-end" option (see point above), it can't be aggregated anymore (but is this a big issue?)

[jdubois]

Closing as the PR is merged :-) This should be released very soon (with a BETA tag, of course!), I'm currently doing the documentation