4 ms·

nginx config increasingly feels like a bunch of foot guns waiting to go off for me. For smaller projects, I've really enjoyed Caddy's "best practice by default

by giobox 5y ago

nginx config increasingly feels like a bunch of foot guns waiting to go off for me. For smaller projects, I've really enjoyed Caddy's "best practice by default" approach to webserver/loadbalancer config where you can generally only choose to remove best practices, not try to build them up from scratch. Has SSL and LetsEncrypt enabled by default, etc. This avoids a lot of the pitfalls of incorrect webserver config altogether, keeps the configuration file really small and easy to read. I wish this style of config was more common. > https://caddyserver.com https://caddyserver.com

KronisLV 5y ago
I actually really like Caddy, though some of its defaults at least historically have been odd, such as responding with 200 where other web servers would respond with a 502 or something similar: https://caddy.community/t/why-does-caddy-return-an-empty-200-response-for-a-non-configured-host/7685 https://caddy.community/t/why-does-caddy-return-an-empty-200... Also, this is a bit of a personal preference, but v1 Caddy felt like maybe a bit easier to get started with than v2 Caddy, though sadly was abandoned. I'm sure that there were good reasons for doing it, but the few forks that started out from it with the intent to maintain it never really went everywhere, so v2 is the only possibility nowadays, unless you want to maintain it yourself or like dead software: https://github.com/WedgeServer/wedge https://github.com/WedgeServer/wedge Of course, that's not a criticism of Caddy itself, just how we as an industry sometimes need rewrites and that makes us keep up with the churn.
- francislavoie 5y ago
  The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really. The complete rewrite for Caddy v2 was necessary to make Caddy flexible enough to solve like half or more of the open issues the Caddy repo had at that point. Flexibility and simplicity are often at odds. But Caddy tries to keep smart defaults in general. Also, any time someone brings up the malicious fork "wedge", it saddens me. That was done at literally the most stressful moment in the project's history, and it only made things worse for everyone. I really hope people learn to chill out and give maintainers a bit of time to breathe and respond instead of taking such hostile measures like that. (You can probably pretty easily dig up the Github issue with the discussion if you really care to see what went down. Sigh.)
  - KronisLV 5y ago
    > The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really. You know, as someone who used Caddy v1 pretty extensively (still probably have it running on some of my homelab boxes), i never really ran into those supposed problems. Maybe they'd manifest in more complex configurations, but as a reverse proxy, file host, web server that's integrated with PHP or even something to allow setting up basicauth, i never found it to be lacking. That's not to say that Caddy v2 is bad, just that someone for whom v1 worked perfectly might find it a bit cumbersome to move to the newer version, as the old one is no longer supported. Of course, you can say the same about JDK 8 vs JDK 11+ etc. > Also, any time someone brings up the malicious fork "wedge", it saddens me. If i recall correctly, it just took the project and rebranded it, which isn't necessarily malicious (for example, aggregating and selling users' data would). That's the nature of open source - anyone who wants to do that, can. Of course, i think that the fork is also irrelevant because they couldn't actually be bothered to maintain the fork and nobody cared for it, much like how other projects, like Materialize.css, ended up. For example, here's the original: https://github.com/Dogfalo/materialize https://github.com/Dogfalo/materialize Then someone got upset that the project was abandoned (even though they were taking folks Patreon money): https://github.com/Dogfalo/materialize/issues/6615 https://github.com/Dogfalo/materialize/issues/6615 They created a fork of their own: https://github.com/materializecss/materialize https://github.com/materializecss/materialize Which promptly died down because there just wasn't enough interest in maintaining it. That's just how things go sometime.
seumars 5y ago
It seems caddyserver makes certificates a lot easier to work with. Certbot is pretty much on par with NGINX in terms of challenging documentation and foot guns.
freedomben 5y ago
I would guess nginx config is suffering greatly from the requirements of backwards compatibility. Would be really interesting to see what a fresh attempt would come up with (although reaching feature and performance parity would take a really long time).
sodality2 5y ago
I replaced 846 lines of Apache config files (or 400 lines of nginx config files) with a 29-line Caddyfile. I was worried about switching over but honestly it is really refreshing to not worry about the reverse proxy at all, unless I'm making a unique change. Sure, LOC is not a great indicator of size, but here's a simple comparison: https://pastebin.com/kmXMX6Yq https://pastebin.com/kmXMX6Yq And this doesn't include the pain of manually refreshing SSL certificates, certbot always managed to break on me and I could never get auto-SSL to work.
na85 5y ago
I've been using nginx for years because "everyone knows" (is it even true anymore?) that it's more performant than apache, and I use a single dedicated server that is rather low-end, because the applications hosted on it are personal/hobby in nature and I don't need AWS/Azure/GCP scalability. How does caddy compare, performance-wise, to apache and nginx?
- manigandham 5y ago
  At your scale they all have the same performance.
- xorcist 5y ago
  Why bother with performance? Does the performance of the http proxy really matter to any real world application? Serving http is usually completely I/O bound. The more efficient parser in nginx never mattered in the real world. It was used for the much more readable configuration and the fewer bundled foot guns. What matters for performance is mostly your tcp settings, your buffer sizes, and that disk logging. And that's only in the few cases where the upstream application isn't the bottleneck.
  - na85 5y ago
    >Why bother with performance? The common wisdom when I last looked into this was that apache uses more CPU, especially under load. Naturally, I want to use the httpd that's most efficient on CPU since it's a finite resource, I'm running several different applications on that box, and you never know when one of your side projects is going to meet the HN hug of death.
    - xorcist 5y ago
      > The common wisdom when I last looked into this was that apache uses more CPU, It can be hard to separate common wisdom from nonsense on the Internet. It's easy to test yourself. There are plenty of easy to use http benchmarks out there, including wrk and ab. Just be wary that the benchmark tool itself will use more cpu than the http server. Which on the other hand might tell you everything you need to know. If you want to spend your cpu cycles more wisely, you should tune your software and network stack to your request and response size, carefully consider caching and pipelining, not mindlessly switch software. For certain applications this will even make sense. Of course this has zero relevance if your application spits out a megabyte of content with every request.
ComodoHacker 5y ago
The problem is best practices change over time.

by giobox 5y ago

KronisLV 5y ago

I actually really like Caddy, though some of its defaults at least historically have been odd, such as responding with 200 where other web servers would respond with a 502 or something similar: https://caddy.community/t/why-does-caddy-return-an-empty-200-response-for-a-non-configured-host/7685 https://caddy.community/t/why-does-caddy-return-an-empty-200... Also, this is a bit of a personal preference, but v1 Caddy felt like maybe a bit easier to get started with than v2 Caddy, though sadly was abandoned. I'm sure that there were good reasons for doing it, but the few forks that started out from it with the intent to maintain it never really went everywhere, so v2 is the only possibility nowadays, unless you want to maintain it yourself or like dead software: https://github.com/WedgeServer/wedge https://github.com/WedgeServer/wedge Of course, that's not a criticism of Caddy itself, just how we as an industry sometimes need rewrites and that makes us keep up with the churn.

francislavoie 5y ago
The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really. The complete rewrite for Caddy v2 was necessary to make Caddy flexible enough to solve like half or more of the open issues the Caddy repo had at that point. Flexibility and simplicity are often at odds. But Caddy tries to keep smart defaults in general. Also, any time someone brings up the malicious fork "wedge", it saddens me. That was done at literally the most stressful moment in the project's history, and it only made things worse for everyone. I really hope people learn to chill out and give maintainers a bit of time to breathe and respond instead of taking such hostile measures like that. (You can probably pretty easily dig up the Github issue with the discussion if you really care to see what went down. Sigh.)
- KronisLV 5y ago
  > The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really. You know, as someone who used Caddy v1 pretty extensively (still probably have it running on some of my homelab boxes), i never really ran into those supposed problems. Maybe they'd manifest in more complex configurations, but as a reverse proxy, file host, web server that's integrated with PHP or even something to allow setting up basicauth, i never found it to be lacking. That's not to say that Caddy v2 is bad, just that someone for whom v1 worked perfectly might find it a bit cumbersome to move to the newer version, as the old one is no longer supported. Of course, you can say the same about JDK 8 vs JDK 11+ etc. > Also, any time someone brings up the malicious fork "wedge", it saddens me. If i recall correctly, it just took the project and rebranded it, which isn't necessarily malicious (for example, aggregating and selling users' data would). That's the nature of open source - anyone who wants to do that, can. Of course, i think that the fork is also irrelevant because they couldn't actually be bothered to maintain the fork and nobody cared for it, much like how other projects, like Materialize.css, ended up. For example, here's the original: https://github.com/Dogfalo/materialize https://github.com/Dogfalo/materialize Then someone got upset that the project was abandoned (even though they were taking folks Patreon money): https://github.com/Dogfalo/materialize/issues/6615 https://github.com/Dogfalo/materialize/issues/6615 They created a fork of their own: https://github.com/materializecss/materialize https://github.com/materializecss/materialize Which promptly died down because there just wasn't enough interest in maintaining it. That's just how things go sometime.

seumars 5y ago

It seems caddyserver makes certificates a lot easier to work with. Certbot is pretty much on par with NGINX in terms of challenging documentation and foot guns.

freedomben 5y ago

I would guess nginx config is suffering greatly from the requirements of backwards compatibility. Would be really interesting to see what a fresh attempt would come up with (although reaching feature and performance parity would take a really long time).

sodality2 5y ago

I replaced 846 lines of Apache config files (or 400 lines of nginx config files) with a 29-line Caddyfile. I was worried about switching over but honestly it is really refreshing to not worry about the reverse proxy at all, unless I'm making a unique change. Sure, LOC is not a great indicator of size, but here's a simple comparison: https://pastebin.com/kmXMX6Yq https://pastebin.com/kmXMX6Yq And this doesn't include the pain of manually refreshing SSL certificates, certbot always managed to break on me and I could never get auto-SSL to work.

na85 5y ago

I've been using nginx for years because "everyone knows" (is it even true anymore?) that it's more performant than apache, and I use a single dedicated server that is rather low-end, because the applications hosted on it are personal/hobby in nature and I don't need AWS/Azure/GCP scalability. How does caddy compare, performance-wise, to apache and nginx?

manigandham 5y ago
At your scale they all have the same performance.
xorcist 5y ago
Why bother with performance? Does the performance of the http proxy really matter to any real world application? Serving http is usually completely I/O bound. The more efficient parser in nginx never mattered in the real world. It was used for the much more readable configuration and the fewer bundled foot guns. What matters for performance is mostly your tcp settings, your buffer sizes, and that disk logging. And that's only in the few cases where the upstream application isn't the bottleneck.
- na85 5y ago
  >Why bother with performance? The common wisdom when I last looked into this was that apache uses more CPU, especially under load. Naturally, I want to use the httpd that's most efficient on CPU since it's a finite resource, I'm running several different applications on that box, and you never know when one of your side projects is going to meet the HN hug of death.
  - xorcist 5y ago
    > The common wisdom when I last looked into this was that apache uses more CPU, It can be hard to separate common wisdom from nonsense on the Internet. It's easy to test yourself. There are plenty of easy to use http benchmarks out there, including wrk and ab. Just be wary that the benchmark tool itself will use more cpu than the http server. Which on the other hand might tell you everything you need to know. If you want to spend your cpu cycles more wisely, you should tune your software and network stack to your request and response size, carefully consider caching and pipelining, not mindlessly switch software. For certain applications this will even make sense. Of course this has zero relevance if your application spits out a megabyte of content with every request.

ComodoHacker 5y ago

The problem is best practices change over time.