As you mentioned, the docs are terrible. What makes that worse are the undocumented breaking changes between each release. They don't even pretend to follow semver, so v1.5 broke v1.4, and v1.6 broke v1.5. Each update you pray that it doesn't take your whole setup down. If anything goes wrong, since nothing is documented and there's often no logs explaining what went wrong, you might be down for an extended period while you make 100 best-guess changes to the config that worked in staging, but for whatever reason isn't working in production. May the odds be ever in your favor.
Last I checked, Traefik was 988,000 (!!!) lines of code. That's 20x the size of my very complex web application. I replaced it with 500 lines of go providing all the essential features for me. Higher reliability, way fewer bugs, no breaking changes.
You may encountered issues while using Traefik so giving your opinion is totally fine, but I don't think that's fair to overreact.
Many users (and I mean big companies) have been using Traefik in production for years without issue. I'm not saying there is not bug, which software can claim this, I'm just saying that many users have a good opinion on Traefik stability.
We follow semver, there shouldn't be any breaking change between 2 minor versions. But, yes, it can happen, sometimes, we may have forgot to check a specific use case. But hey, again, let's be fair, we don't want it. We are just human. And no, this does not happen at every minor version and this is pretty uncommon...
Finally, on Traefik size. You are including Traefik dependencies, in vendor/, which is a bit weird. In go, the convention is to push the dependencies in your repository to get reproducible builds, so that's not a good way to count. If you exclude vendor/:
golocc --no-vendor ./...
Lines of Code: 58532 (2987 CLOC, 55545 NCLOC)
Which is rather tiny.
So all in all, I regret you had such a bad experience with Traefik, but I just wanted to express the fact that many users are using it without any issue :) I would be happy to discuss further on this.
Fabio might be a good alternative, but we don't need Consul right now, so I don't want to have to manage yet another puzzle piece.
Should I go with nginx?
1. If you "just" want to map a hostname, to a private IP, you can assign the hostname to a variable, and use the variable in your backend config. This works because Nginx resolves static addresses at start, but resolves names pulled from variables at runtime.
2. If you need to map ports as well, you can use a Lua or Mruby script. E.g. I have a blog post on doing it with mruby here [1], and it's run production sites for a couple of years. This options lets you integrate against pretty much whatever you want.
It's extra hassle, though, of course.
[1] https://medium.com/@sigil66/dynamic-nginx-upstreams-from-con...
If that's happening super-frequently I could see the problem, but in practice I'd expect you to use `consul-template` and issue a `reload` to nginx to make it reload configurations with no downtime. This is the solution I've used and it works pretty well.
Just make sure consul-template never writes bad config as that will stop everything reloading. That's bit me a couple of times.
Limited blast radius don't really apply when it comes to nginx config errors (which given its origins is understandable). One error in one bit of config and it all stops.
It's super fun with haproxy :(
Like traefik or envoy or nginx when you pay for it or use the lua shit to do backend discovery (haproxy also has lua shit iirc)
I'm not going to lie; it works and does failover correctly, quickly, and plays nice with consul. Not to mention, the name brings back memories...
If I had my way though, we would use HAProxy, but that's just because there is more options, ways to properly route, and more battle-tested.
Traefik replaces Nginx: it's the reverse proxy that maps the incoming requests to your various services, which are advertising on some arbitrary localhost port.
The amazing thing is that Traefik integrates with Consul: you only need to point it to your Consul endpoint, and it can automatically publish your services! You can also do other dynamic configuration of Traefik, e.g. by publishing a service via a REST API, via Kubernetes, etc.
I've struggled for years to get Nginx configured correctly, and it's been frustrating to have no alternative. In Nginx, dynamic binding is a premium feature. In the free version, you have to rewrite the config and restart the service. That's not fun if you expect services to come and go as part of your natural life-cycle.
Traefik's still pretty young. Notably, the docs are shit. But the application is well-designed, and it compiles as a single self-contained binary (as it's written in Go).