131–140 of 154 posts
I don't use any of the dynamic features though like labels in docker containers etc, all of it is configured using the static configuration. It's been working well but I don't think about it really.
With Envoy ( https://www.envoyproxy.io/ ) and Contour ( https://projectcontour.io/ ) being official CNCF sanctioned projects in the Service Proxy space, Istio ( https://istio.io/ ) and Linkerd ( https://linkerd.io/ ) being official CNCF sanctioned projects in the Service Mesh space and Emissary Ingress ( https://emissary-ingress.dev/ ) the same in the API Gateway space, just to name a few, naming yourself a standard…
Yea, envoy is the premier open source (not open core+ paid features) proxy right now in my opinion. Modern, well supported, big community, reliable. If I was making a bet long term I would be looking at envoy and not some open core crap where they can rug pull you at any moment.
Earlier quoted context omitted.
I really like how it can be easily configured from Docker labels (from Portainer for example), or from your big production Consul cluster alike. But yeah, the docs need a lot of work, it’s difficult to figure out the format many times, it lacks examples, and things that need to be enabled together have their docs at different places.
Your point about having to enable two different things at the same time in two different places is a concise way of expressing my extreme frustration with that project. I burned the better part of a Saturday trying to figure out why a relatively straightforward configuration wasn't applying and it's because one half of the configuration that I was trying to apply has to be done in the static manner and not the dynami…
Earlier quoted context omitted.
Is there a way to use Envoy with common self-hosting software stacks like Docker Swarm?
Isn’t Docker Swarm dead?
Earlier quoted context omitted.
Caddy is dead simple. Like, send https://example.com to 1.2.3.4:5000. That’s it! Certificate provisioning, TLS configs, TLS termination, mTLS and client certificates, sticking in middlewares, … are all simple. The config is a straightforward text file. Really good webserver! Traefik is docker centric, and had various obscure labels. Too much text for a simple proxy. The debugging can be an issue if it doesn’t work. I…
Does Caddy automatically detect when you deploy a new Docker service and reconfigure itself to route traffic to that service? That's pretty much the main value preposition of Traefik for me. I don't want to be messing with config files when I'm deploying.
For the use case of network routing for services running in containers, OpenRun provides a simpler abstraction. It does the container management and the network proxying.
I use Traefik for local development on daily basis, where I have to run double digit https services. It works, but it was a pain to set up. The documentation sucks ** and the config is confusing AF. I would never recommend this to anyone. If i will have to reinstall my computer one day, Traefik will not be welcomed back.
Traefik maintainer here. Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides. Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.
I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.
I have some feedback I'd offer of my own, too:
1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.
2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.
3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.
4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.
[1] Here are some concrete examples:
- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.
- https://doc.traefik.io/traefik/setup/kubernetes/ and https://doc.traefik.io/traefik/getting-started/kubernetes/ are different pages which seem to explain mostly the same things. They both include too much irrelevant information, like overly explaining what Helm commands do. Similar to the previous point, it is not the job of Traefik's documentation to explain Helm to me.
I use Traefik for local development on daily basis, where I have to run double digit https services. It works, but it was a pain to set up. The documentation sucks ** and the config is confusing AF. I would never recommend this to anyone. If i will have to reinstall my computer one day, Traefik will not be welcomed back.
To each their own but it's interesting you find it useful (you use it) yet it won't be welcome back. Maybe, as others have noted, try it in Docker (or k3s/k8s/etc). Once the base configuration you want is configured and deployed all you need to do is place labels in for dynamic service configuration.
Earlier quoted context omitted.
Your point about having to enable two different things at the same time in two different places is a concise way of expressing my extreme frustration with that project. I burned the better part of a Saturday trying to figure out why a relatively straightforward configuration wasn't applying and it's because one half of the configuration that I was trying to apply has to be done in the static manner and not the dynami…
Sticking to nginx seems not to be an option for many as at least ingress-nginx will not be get any new features anymore (as mentioned in the article).
For k8s, yeah. It should still be a useful tool for other things? Or did i miss a memo about nginx being EOLd?
Still not entirely sure how to pronounce the name though...
Earlier quoted context omitted.
Traefik maintainer here. Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides. Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.
Hi there. I'm a brand new Traefik user. It's bundled with k3s, so I set it up for my homelab on a single node cluster. I'm a technology professional who has worked in infrastructure and software roles for more than 15 years. I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing…
We're going to work through these points with the team. Appreciate you sticking with Traefik despite the documentation friction.