Live data from Hacker News

Take a look at Traefik, even if you don't use containers

j6b72.de

91–100 of 266 posts

Re: Take a look at Traefik, even if you don't use containers

#91
post #52

Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…

I'm using the Traefik and have the same experience with the documentation. It can be time consuming to configure it properly if you are not a power user.

I'm happy with it though, it's a great piece of software. I wonder is there any other product out there with a similar feature set?

Re: Take a look at Traefik, even if you don't use containers

#92

I use Traefik in production (with containers), and my favorite aspect of it is that the configuration is carried via the labels on containers which means I rarely if ever need to make any modifications to the Traefik config itself. I'd say the biggest con is trying to figure out how to pronounce the name - I think it's just regular traffic, but I can't help wanting to call it "trey-feek" or something like that.

I just pronounce it "traffic". I'm not playing their damn head games.

Re: Take a look at Traefik, even if you don't use containers

#93
post #17

Side question - what people use to hide (and make accessible) the internal services such as grafana, prometheus, rabbit mq (the web interface) and such? Should they be public behind such a proxy? (seems odd) Or should they be totally internal and then setup a Wireguard VPN to reach them?

Cloudflare tunnels are super convenient and provide lots of auth mechanisms. If you set up a tunnel using cloudflared and proxy the IP through cloudflare, there's nothing even exposed directly to the internet. You can even have different auth requirements for urls (like /admin) or punch holes for stuff like webhooks.

I have set up quite a few as kubernetes pods that direct to private hostnames in different namespaces and pretty happy with it for internal apps.

Re: Take a look at Traefik, even if you don't use containers

#94

Earlier quoted context omitted.

Investing a lot of time and trying really hard is not the same as adding a lot of value. If your users don't find value in your documentation, saying "But we spent a lot of time on it!" doesn't really change anything. And, to be clear, I have no idea if the person you're responding to's criticism is valid. But I also know that your response does not negate their criticism at all.

How about submitting a PR to improve the documentation instead of complaining about it?

This is why OSS looks like a cult at times. People are allowed to criticize your project and complain about it. They have no obligation to become a contributor. "Submit a PR" is such a conversation killer.

Re: Take a look at Traefik, even if you don't use containers

#95
I’d stay away from it. The magical way to set it up via docker compose tags is nice but doesn’t allow for zero downtime deployment at least until recently.

Getting true zero downtime deployments only worked with their file provider but that’s a bit archaic these days.

Re: Take a look at Traefik, even if you don't use containers

#96

Why traefik over nginx for my modest needs, a couple docker hosts and a few dozen containers. I use https://github.com/NginxProxyManager/nginx-proxy-manager , would traefik provide a benefit on such a small scale?

Yeah I agree with this. Nginx config is easy and you can just set it and forget it. Most of the time you're copypasting from other configs you already have anyways. Automatic LE is kinda a strange selling point when Certbot is available everywhere and supports more scenarios. Traefik's and Caddy's selling points just don't make any sense to me because they don't make anything easier than the alternatives that are already widely supported.

Re: Take a look at Traefik, even if you don't use containers

#97
post #15

Why traefik over nginx for my modest needs, a couple docker hosts and a few dozen containers. I use https://github.com/NginxProxyManager/nginx-proxy-manager , would traefik provide a benefit on such a small scale?

If what you've got already works then no, I don't think you would see any benefit from switching. The moment you need a feature which Traefik provides that isn't in Nginx is when I would consider the switch.

But what features does Traefik have that nginx doesn't?

Re: Take a look at Traefik, even if you don't use containers

#99
I have used traefik a lot. But I mostly got frustrated with all the docker-compose labels and layers and so many lines just to have a rev proxy. Then I found Caddy. Never looked back.

I guess I was never the audience for Traefik. I just need an https enabled rev proxy. Or a basic-auth layer. In Caddy both are just 1 line, very concise, no layers (which I still don’t understand…)

Re: Take a look at Traefik, even if you don't use containers

#100
post #88

We've been using Traefik in prod for 2 years. While I used NGINX in the past, I decided to migrate to Traefik mainly because of the automatic let's encrypt integration. I am sorry for that decision. Traefik's documentation does not make sense to me or my team. It is finicky and misbehaves without proper logging. As an example - when I want to recreate the certificates - it fails sporadically leaving prod down for an…

I’ve always just used go’s built in reverse proxy if I need an API gateway. You can adapt it to meet any specific need, easily find libraries to do common tasks (CORS, rate limiting, retries, etc), and the best part: no configuration language. You just write go.

curious what are the performance characteristics here? I would assume something like Nginx that has been optimized over a longer period of time / a more specific use case would have non-negligible performance benefits at scale?
Post reply on HN