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

71–80 of 266 posts

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

#71

Post by san-fran »

deepersprout wrote: post #68
sph wrote: 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 usually feed all the documentation to an llm and ask the question to the llm that fetches the info with rag. For example: > how do i configure Traefik to proxy traffic to two backend services? Configuring Traefik to proxy traffic to multiple backend services is a common use case. You can achieve this by defining multiple entry points and routers in Traefik's configuration, each pointing to a different backend servi…

This might be an additional way to quickly iterate on the content of the documentation itself. If I were the one writing, an easy test is passing the documentation to a lay person and asking them if they have what they need to perform X by following the documentation.

Perhaps having a focused LLM generate the steps could help catch some documentation deficiencies.

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

#72

Post by engine_y »

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 indefinite amount of time.

We're moving back to NGINX.

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

#73

Post by freedomben »

deepersprout wrote: post #68
sph wrote: 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 usually feed all the documentation to an llm and ask the question to the llm that fetches the info with rag. For example: > how do i configure Traefik to proxy traffic to two backend services? Configuring Traefik to proxy traffic to multiple backend services is a common use case. You can achieve this by defining multiple entry points and routers in Traefik's configuration, each pointing to a different backend servi…

Can you describe more on your process? Which LLM are you using? Are you doing soething specific to make it us RAG or is that automagic (might be obvious depending on which LLM you are using but)? How do you feed the documentation in? for example, when the documentation has more than one page, how do you get that content in to the LLM? Is it part of the prompt or something you've tuned it on? have to clone the docs site, turn it into plan text and feed that in to the prompt or can you pass a URL and have it crawl ahead of time or something?

This is the system I've been dreaming about but haven't had time to dig into yet. I've got ollama and openwebui set up now though, and with OpenAI getting bigger context windows it seems like it might be possible to inject the whole set of docs into the prompt, but I'm not sure how to go about that

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

#74

Post by freedomben »

san-fran wrote: post #71
deepersprout wrote: post #68

Earlier quoted context omitted.

I usually feed all the documentation to an llm and ask the question to the llm that fetches the info with rag. For example: > how do i configure Traefik to proxy traffic to two backend services? Configuring Traefik to proxy traffic to multiple backend services is a common use case. You can achieve this by defining multiple entry points and routers in Traefik's configuration, each pointing to a different backend servi…

This might be an additional way to quickly iterate on the content of the documentation itself. If I were the one writing, an easy test is passing the documentation to a lay person and asking them if they have what they need to perform X by following the documentation. Perhaps having a focused LLM generate the steps could help catch some documentation deficiencies.

> If I were the one writing, an easy test is passing the documentation to a lay person and asking them if they have what they need to perform X by following the documentation.

What kind of documentation is this though? Is this how to bake a cake or tie a necktie, or is it how to setup a reverse proxy for the services in your k8s cluster?

If it's something a lay-person could do then I think this is a good strategy (though depending on the size/scope of the project/documentaiton it does seem like a pretty big effort to undertake without compensation), but if it's something highly technical like Traefik, I expect a lay-person to not even understand half the words/vocabulary in the documentation, let alone be able to perform X by reading it and following it.

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

#75

Post by johanbcn »

sph wrote: 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…

> 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 https://diataxis.fr

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

#76

Post by freedomben »

throwaway984393 wrote: post #69
sph wrote: post #67

Earlier quoted context omitted.

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…

I like that it forces users to read the docs to find the functionality. Users don't read the docs, and then they wander around the internet looking for a random blog post with a snippet for one problem, and they don't ever really learn how to use the program. Users are a bit like high school students just skimming books for an answer to fill in on a test. They need to be forced to learn.

This doesn't make a lot of sense in the context of the parents. Did you post this to the wrong parent? To accomplish what you are asking, a project needs actual good documentation. Everyone has agreed that is good. The only real disagreement here is whether Ansible docs have this, and regardless whether they do, they definitely have the example-driven docs that I think you are saying you don't think should exist, so you definitely aren't supporting the Ansible status quo.

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

#78

Post by meonkeys »

xorax wrote: post #50
znpy wrote: post #43

> you mount the docker socket into the traefik container and gain the ability to auto-detect other containers that you might want to expose using traefik. Totally not a security issue. Source: trust me bro.

https://github.com/traefik/traefik/issues/4174

Related:

https://doc.traefik.io/traefik/providers/docker/#docker-api-...

https://www.reddit.com/r/Traefik/comments/g46lhh/does_bindin...

https://github.com/wollomatic/traefik-hardened

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

#79

Post by sureglymop »

pricci wrote: post #60
arush15june wrote: post #56

I use caddy rather traefik. It's much easier to manage the Caddyfile compared to the traefik YAML config IMO, and we just keep three separate Caddyfiles for local, production and on-prem deployments. There are a plethora of great plugins, we use the coraza WAF plugin for caddy and it works well.

I moved from Traefik to Caddy with caddy-docker-proxy for my self-hosting setup. All the features I need but *much* simpler. https://github.com/lucaslorentz/caddy-docker-proxy

Looks interesting but I don't see the benefits really. Still looks like a lot of labels exactly like with traefik. Why should one switch?

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

#80

Post by freedomben »

sph wrote: post #67
linsomniac wrote: post #57

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…

I'm not GP, but I agree with both them and you so thought I'd chime in.

You're absolutely right that there are big omissions/holes in the Ansible docs, but I also think that using Google is not "cheating." My ideal of great documentation sounds like exactly what you would agree with: A complete and comprehensive "book" (could become a physical printed book, but needn't have to as it should be equally usable with good old-fashioned hyperlinks). It should have a logical flow, introductory sections to describe pre-requisite knowledge/concepts and things that are broadly applicable to the project as a whole. It should have a table of contents, and it should definitely have an index and comprehensive lists/tables of API details such as available field/properties, which options are valid (for enum fields), etc. Your example of Jinja filters supported by Ansible is a great one. I really miss the 90's era here where such manuals were common practice, even for things like PCs.

With that ideal described, though, I think it's important to recognize pragmatism and feasibility. Documentation takes time and money to produce. Search tools (including Google) already exist and can provide a valuable addition without spending time/effort on it, so I think they should be used. That said, I agree that it's not a good idea for doc writers to rely on that for things to be found! Table of contents, logical flow, and indexes should absolutely be thought through. If the documentation is just a bunch of random unorganized and uncatalogued pages that can only be found with a search engine, that is really bad and they should feel bad.

I think Ansible falls right in the middle there. It undoubtedly has some real glaring omissions/holes in it, but it is also not nearly the worst I've seen as well. I do dread having to go the Ansible docs though, which is an indictment against their quality, and the more I think/write about this the more I agree with you lol.

Post reply on HN