Live data from Hacker News

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

j6b72.de

211–220 of 266 posts

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

#211

Earlier quoted context omitted.

> Technical writers: documentation by example is good only for newbies skimming through. People familiar with your product need a reference and exhaustive lists, not explanation for different fields spread over 10 tutorial pages. Focus on those that use the product day in and day out, not solely on the "onboarding" procedure. I agree. We all would benefit by giving more exposure to documentation frameworks such as ht…

Also https://docs.divio.com/documentation-system/

[deleted]

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

#212
post #67

Earlier quoted context omitted.

Do not agree WRT ansible, been using it for well over 5 years and usually a google search points me right at the correct part of the documentation to answer my question. Ansible, the tool itself, can be a bit obtuse, largely IMHO because of the YAML source language, so some concepts are hard to translate into the tool, but the documentation has never bothered me. As far as "a lot of words written, can't find what you…

Alright, please link me to an exhaustive list of Jinja filters supported by Ansible out of the box. I'll wait. What you are given is https://docs.ansible.com/ansible/latest/playbook_guide/playb... and you need basically to read/scan each example until you find what you need [1]. Do you call that good , especially when these are basically the only way of doing anything a little complex? That's a sure way of killing my…

Maybe you use ansible in a more complex environment than I do. I use ansible to provision servers, and jinja2 filters are some of the least-used things for me. I try to keep my ansible roles short and simple, and needing obscure jinja2 filters is a clue to me that I might be getting too fancy.

That said, when I have a question about jinja2, I find that the jinja2 docs are better than the ansible docs.

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

#213

Earlier quoted context omitted.

My primary use case for LLMs so far has indeed been to avoid terrible technical documentation.

I'm on the lookout for an LLM that is relatively small and focused on technical documentation. I don't need it to write prose or haiku, just answer my questions based on documentation

Yep. Build it into an editor and I'd be the first customer.

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

#214
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…

Possibly unpopular opinions to follow. This is made even worse by:

- Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3.

- Supporting multiple config formats (TOML and YAML) which makes it that much harder to hunt down relevant forum posts for support. That wouldn't be a huge problem if it weren't for things that you need that aren't in the documentation (above)

- Multiple configuration _modes_. You can set options on the CLI, or in config files, and they are not 100% reflected between the two; some things must be in config files no matter what. Config files themselves are split between "dynamic" and "static" configs, and you must place the correct options in the right file.

- The one thing that Traefik does well is routing traffic to/from containers. Container labels are used to drive this. How to map those label namespaces to various internal and user provided aspects of Traefik is unclear in the docs, at best.

- Traefik exposes a dashboard web GUI by default. Yet much of the useful diagnostic and troubleshooting information is only found in the container logs.

Retiring v1 completely, picking a single configuration language/mode, and providing a rich library of example docker-compose configs, would go a very long way to securing this project's future.

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

#215
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…

From this point of view the Oracle RDBMS handbooks ca. 1998 were pretty good. Come to think of it, they were pretty good all around.

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

#216
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.

I did the same thing. After some bad downtime from Traefik introducing breaking changes in a point release, I decided to write my own.

My reverse proxy offered a service mesh, live config reloads, managed TLS certs, and automatically rerouted traffic around down services. The whole thing was a few hundred LOC anyone could understand in its entirety. It ran in production for years unchanged and never caused an outage.

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

#217
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…

One of the problems that the yaml interpreter class of languages, or whatever you'd call them, suffer from is the fact that yaml itself is a language and tends to be more or less undocumented in the interpreter docs. It's sort of assumed that you are going to do extremely simple tasks on very flat data structures. That doesn't tend to be the reality that most of us live in. And to really get the most out of these lan…

I honestly wonder why not just write your web server in node or something. It would be traceable and testable and probably performant enough. There's just so much arcana inside platforms like traefik or nginx where they do all this miraculous stuff if you just add the right flags, but also when it doesn't work it's a total black box and there's no way to discover what it thinks it's doing.

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

#218
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…

Those are great points. Even the page layout of the documentation is terrible. Whywe have huge monitors and millions of pixels if I have to read content from a very narrow column, which is a mile long?

Eg: https://doc.traefik.io/traefik/routing/services/

If you visit that page in your desktop browser you'll get less words per column then seeing this on the iPad (works even in dev tools window). Mind blowing.

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

#219
post #193
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 share the same sentiments. I dread having to go through Ansible docs because it's so densely packed. Meanwhile Caddy's docs feel too sparse, and too many spread out tutorials. The reference isn't well thought out either imo.

We're revamping the Caddy docs this year.

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

#220
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…

Possibly unpopular opinions to follow. This is made even worse by: - Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3. - Supporting multiple config formats (TOML and YAML) which makes it that mu…

The documentation split is unfortunate and the GUI really just a status page. The other points are a strength. A pattern that works well: Put all Traefik config in your Docker container definitions, as command line flags and labels, plus the dynamic config provided as a volume. That gives you all the flexibility and only one or two places to look for the config (e.g. a Docker compose file and the dynamic config file)
Post reply on HN