Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

j6b72.de

Post reply on HN
Print view View original

11–20 of 266 posts

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

#11

Post by djhworld »

I've been using traefik for a few years for all my self hosted things.

I abandoned the dynamic/discovery/docker labelling functionality though it was just too finicky and annoying to debug.

Instead I generate a static config file using a template engine, pretty much all my things are just a combination of host/target/port so very easy to generate the relevant sections - I don't really have any complicated middlewares other than handling TLS. It sounds like the author of the linked post has taken the same route.

The config gets generated through an ansible script and then gets copied to the machine where traefik is running - traefik watches the directory where that file is and auto-reloads on changes.

It's been working great!

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

#12

Post by candiddevmike »

iansinnott wrote: post #2

> Traefik is more comparable to HAProxy than to nginx/caddy/apache2 Aren't caddy and traefik fairly comparable? I've only used them both lightly so I may be missing the core point of each, but I thought of them as very similar.

Traefik can't serve static files, or interact with CGI providers like PHP.

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

#14

Post by remram »

psYchotic wrote: post #3

I'm considering moving reverse proxying to Traefik for my self-hosted stuff. Unlike the article's author, I'm running containerized workloads with Docker Compose, and currently using Caddy with the excellent caddy-docker-proxy plugin. What that gets me, currently: - Reverse proxying, with Docker labels for configuration. New workloads are picked up automatically (but I do need to attach workloads to Caddy's network b…

Those are giant limitations. This is the first I hear of any reverse proxy that has to restart and drop connections to update configuration. That is usually the first, most fundamental part of any such server's design.

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

#15

Post by simonw »

beestripes wrote: post #13

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.

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

#16

Post by Projectiboga »

silverquiet wrote: post #9

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.

ae is closest to y, or hi. So Tryfik, is my guess, otherwise is Trayfik. If it's European fik, might be feek. *Just taking a guess here.

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

#17

Post by wg0 »

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?

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

#18

Post by btbuilder »

When looking for a reverse proxy that is performant on Windows and Linux around 5 or 6 years ago the options were very limited. Traefik is what we ended up using.

I haven’t checked recently but at the time nginx on Windows used select() and envoy was either beta or needed a recent version of the Windows kernel that not all customers were running.

We still use it today.

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

#19

Post by IggleSniggle »

remram wrote: post #14
psYchotic wrote: post #3

I'm considering moving reverse proxying to Traefik for my self-hosted stuff. Unlike the article's author, I'm running containerized workloads with Docker Compose, and currently using Caddy with the excellent caddy-docker-proxy plugin. What that gets me, currently: - Reverse proxying, with Docker labels for configuration. New workloads are picked up automatically (but I do need to attach workloads to Caddy's network b…

Those are giant limitations. This is the first I hear of any reverse proxy that has to restart and drop connections to update configuration. That is usually the first, most fundamental part of any such server's design.

Caddy doesn't have to restart, I think it's related to the specifics of their setup. The simple/easy path that gets a lot of people into caddy has a workflow that's more like, run caddy, job done. The next level is, give caddy super simple configuration file, reload caddy with "caddy reload --config /etc/caddy/Caddyfile". After that, you use the REST API to make changes to the server while it is running, which uses a JSON configuration definition instead of a Caddyfile, so it ends up being a jump for users.

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

#20

Post by riedel »

Funnily I spend my weekend making a traefik config file to gitlab pages on a self hosted instance without pages enabled but using the artifact API. No code involved. Had to configure quite some rewriting logic and use three different plug-ins, which are mostly unmaintained. In the end probably something like nginx, Apache or caddy or a bit of code probably would have worked better, because of all the layering of different middleware. But it worked somehow. I guess it shines through still for easy SSL termination of docker and great observability. That is why at least I have been using it for the past years.
Post reply on HN