3 ms·
> It's funny that he goes on to compare the two configuration files, where one is a bit verbose, but very clear and easy to understand, while the "Caddyfile" [.
by vog 10y ago
> It's funny that he goes on to compare the two configuration files, where one is a bit verbose, but very clear and easy to understand, while the "Caddyfile" [...] is four lines that mean basically nothing without a manual.
I strongly disagree with this one. In general, I observe that too many super-configurable tools are essentially putting manual work onto the administrator that should really be solved in the software itself, where it is solved once and for all, and can be improved for all at once.
For example, the following line in Caddy:
transparent
It replaces the following lines in nginx:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
The nginx config is more transparent, for sure. However, for many scenarios this isn't the full list of additional headers on your reverse proxy. Every admin will stumble sooner or later on strange wrongly generated "internal" links by some applications, and will learn the hard way to add more headers, and will never be sure if they really chaught everything. Sure there is community support, but this still means every admin has to do the same kind of research.
It may be good for your ego, some "secret" knowledge that distiguishes you from beginners. But as soon as you get over it, you realize this is just a waste of time.
If this is the task of the software, however, the whole developer community can collect the list of headers and their exact values. Everyone who updates their webserver will benefit immediately. Everyone who installs their webserver for the first time don't even have to bother with that exact header list.
- mdekkers 10y agoAs an ops guy that needs to look after many different configs for many different clients all using many different stacks, your comment surprises me. Configuration being solved within the software itself? Either I am going to end up with "magic" that may or may not work, and may or may not behave predictably in a given scenario (predictable behaviour is somewhat important for ops), or I am going to end up with every single config scenario enshrined within the software itself, something that I thought was established as a software anti-pattern around the time of Ada Lovelace. As the OP stated, the "transparent" option is meaningless without a manual. The nginx (or whatever verbose software config option set) syntax is meaningful, and more importantly, predictable. By spelling out those lines I know exactly what I can expect the software to do in some given scenario. The whole "I don't want to worry about/understand configuration" meme is dangerous. You end up with no real understanding of how your stack functions. You are trading off deep understanding of your stack - a benefit for the lifetime of your product - with reducing 30 minutes configuring stuff to 5, which buys you 25 minutes not having to grok the engine of your app. I personally don't care about having to spend time to configure. I don't care if it is written in Golang, Python, C++, or Sanskrit. I care about performance, security, footprint, and configurability. Remove any of those, and your fancy new toy service just went from "might be interesting for production" to "useless". Ops and magic don't mix very well. I'm surprised this actually needs to be explained. As for it being good for an ego, that kind of statement is ridiculous.
- gshulegaard 10y agoThe thing I don't understand is why do you need a new underlying engine in order to achieve "smaller config files". To me that reads as a non-sequitur. If you want an nginx directive that auto-magically does something, create one...don't build an entire reverse proxy just to add less verbose directives.