4 ms·

I am not sure I would agree with the assertion that config for HAProxy is just as easy. In fact I use HAProxy in production pretty regularly because it is soli

I am not sure I would agree with the assertion that config for HAProxy is just as easy. In fact I use HAProxy in production pretty regularly because it is solid but its config one of the main reasons I would choose something else. A basic HAProxy config is fine but it feels like after a little bit each line is just a collection of tokens in a random order that I have to sit and think about to parse.

bmurphy1976 4y ago
I feel the same way. I'm not a fan of haproxy's configuration system. It's really difficult for me to understand it, whereas I feel I can read most nginx/apache configs and immediately know what is supposed to be happening. I still maintain servers under load in production that use all three to this day and I always go back to nginx because of the configuration alone.
- kilburn 4y ago
  I can't comment on haproxy because I haven't used it enough, but I think that the "nginx's config is easy to grasp" posture has a bit of Stockholm syndrome in it. - Do you want to add a header in this "location" block? Great, you better remember to re-apply all the security headers you've defined at a higher level (server block for instance) because of course adding a new header will reset those. - Oh, you mixed prefix locations with exact location with regex locations. Great, let's see if you can figure out by which location block will a request end up being processed. The docs "clearly" explain what the priority rules for those are and they're easy to grasp [1]. - I see you used a hostname in a proxy_pass directive (e.g.: http://internal.thing.com http://internal.thing.com). Great, I will resolve it at startup and never check again, because this is the most sensible thing to do of course. - Oh... now you used a variable (e.g.: http://$internal_host http://$internal_host). That fundamentally changes things (how?) so I'll respect the DNS's TTL now. Except you'll have to set up a DNS resolver in my config because I refuse to use the system's normal resolver because reasons. - Here's an `if` directive for the configuration. It sounds extremely useful, doesn't it? Well.. "if is evil" [2] and you should NOT use it. There be dragons, you've been warned. I could go on... but I think I've proved my point already. Note that these are not complaints, it's just me pointing out that nginx's configuration has its _very_ significant warts too. [1] https://nginx.org/en/docs/http/ngx_http_core_module.html#location https://nginx.org/en/docs/http/ngx_http_core_module.html#loc... [2] https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
  - hinkley 4y ago
    All that may be true, but for a lot of us old timers we were coming from apache to nginx and apache's configs can eat a bag of dicks. Unfortunately it's likely I worked in the same building as one of the people responsible for either creating or at least maintaining that mess, but I didn't know at the time that he needed an intervention.
  - slivanes 4y ago
    Yes, I've experienced most of these with nginx and it can be a minefield. The best experience I've had configuring a webserver was lighttpd.
    - iforgotpassword 4y ago
      Yes, also a lighttpd fan here. It's not as refined a reverse proxy, but for the halfway trivial use case it's doing fine, and as a web server it's light (duh) and fast. Much more readable configuration than nginx or apache.
  - bmurphy1976 4y ago
    To be clear I never said it was easy. I have a LOT of issues with Nginx's configuration, I just find it to be significantly less bad than the other options. Other than Caddy, Caddy has been great so far but I have only used it for personal projects.
  - TimWolla 4y ago
    Exactly all of this. I've mentioned the first point about add_header redefining instead of appending in a previous HN comment of mine: https://news.ycombinator.com/item?id=27253579 https://news.ycombinator.com/item?id=27253579. As mentioned in that comment, HAProxy's configuration is much more obvious, because it's procedural. You can read it from top to bottom and know what's happening in which order. Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.
gunapologist99 4y ago
For simple things, Caddy is nice and easy, but I've struggled with Caddy quite a bit, too, especially for more complex setups. I usually break out haproxy or nginx for really challenging setups, because caddy's documentation and examples are quite sparse (esp v2)
- mholt 4y ago
  What do you struggle with about the documentation or "more complex setups"? I was just on the phone recently with Stripe who has a fairly complex, large-scale deployment, and they seemed to have figured it out with relative ease. I'm currently on a push to improve our docs, especially for beginners, so feel free to review the changes and leave your feedback: https://github.com/caddyserver/website/pull/263 https://github.com/caddyserver/website/pull/263
  - GordonS 4y ago
    I'm not the GP, but I've had a similar experience, with the Caddy docs seeming good for simple configurations, but lacking for more complex ones. I last setup a Caddy config maybe 6- 9 months ago, and everything related to client certificates was either scantily documented, wrongly documented, or not documented at all. It might be I got unlucky, as some of the client cert features were fairly new, but it wasn't a great experience. Still, I much prefer Caddy's config system to Nginx or HAProxy. Oh, something else I'd really love to see are more fully-featured example configs, as it can be hard to know how to start sometimes.
    - gunapologist99 4y ago
      I agree completely. Fully-featured examples would be extremely helpful, especially with things like proxying to different servers for different paths and domains, static file serving set up differently for different paths and domains, various plugin setups, etc.
      - mholt 4y ago
        Oh, just saw this. You wrote your comment while I wrote mine. If you can enumerate specifically what you want to see, please submit it to our issue tracker: https://github.com/caddyserver/website https://github.com/caddyserver/website Generally we encourage examples in our community wiki though: https://caddy.community/c/wiki/13 https://caddy.community/c/wiki/13 -- much easier to maintain that way.

bmurphy1976 4y ago

I feel the same way. I'm not a fan of haproxy's configuration system. It's really difficult for me to understand it, whereas I feel I can read most nginx/apache configs and immediately know what is supposed to be happening. I still maintain servers under load in production that use all three to this day and I always go back to nginx because of the configuration alone.

kilburn 4y ago
I can't comment on haproxy because I haven't used it enough, but I think that the "nginx's config is easy to grasp" posture has a bit of Stockholm syndrome in it. - Do you want to add a header in this "location" block? Great, you better remember to re-apply all the security headers you've defined at a higher level (server block for instance) because of course adding a new header will reset those. - Oh, you mixed prefix locations with exact location with regex locations. Great, let's see if you can figure out by which location block will a request end up being processed. The docs "clearly" explain what the priority rules for those are and they're easy to grasp [1]. - I see you used a hostname in a proxy_pass directive (e.g.: http://internal.thing.com http://internal.thing.com). Great, I will resolve it at startup and never check again, because this is the most sensible thing to do of course. - Oh... now you used a variable (e.g.: http://$internal_host http://$internal_host). That fundamentally changes things (how?) so I'll respect the DNS's TTL now. Except you'll have to set up a DNS resolver in my config because I refuse to use the system's normal resolver because reasons. - Here's an `if` directive for the configuration. It sounds extremely useful, doesn't it? Well.. "if is evil" [2] and you should NOT use it. There be dragons, you've been warned. I could go on... but I think I've proved my point already. Note that these are not complaints, it's just me pointing out that nginx's configuration has its _very_ significant warts too. [1] https://nginx.org/en/docs/http/ngx_http_core_module.html#location https://nginx.org/en/docs/http/ngx_http_core_module.html#loc... [2] https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
- hinkley 4y ago
  All that may be true, but for a lot of us old timers we were coming from apache to nginx and apache's configs can eat a bag of dicks. Unfortunately it's likely I worked in the same building as one of the people responsible for either creating or at least maintaining that mess, but I didn't know at the time that he needed an intervention.
- slivanes 4y ago
  Yes, I've experienced most of these with nginx and it can be a minefield. The best experience I've had configuring a webserver was lighttpd.
  - iforgotpassword 4y ago
    Yes, also a lighttpd fan here. It's not as refined a reverse proxy, but for the halfway trivial use case it's doing fine, and as a web server it's light (duh) and fast. Much more readable configuration than nginx or apache.
- bmurphy1976 4y ago
  To be clear I never said it was easy. I have a LOT of issues with Nginx's configuration, I just find it to be significantly less bad than the other options. Other than Caddy, Caddy has been great so far but I have only used it for personal projects.
- TimWolla 4y ago
  Exactly all of this. I've mentioned the first point about add_header redefining instead of appending in a previous HN comment of mine: https://news.ycombinator.com/item?id=27253579 https://news.ycombinator.com/item?id=27253579. As mentioned in that comment, HAProxy's configuration is much more obvious, because it's procedural. You can read it from top to bottom and know what's happening in which order. Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.

gunapologist99 4y ago

For simple things, Caddy is nice and easy, but I've struggled with Caddy quite a bit, too, especially for more complex setups. I usually break out haproxy or nginx for really challenging setups, because caddy's documentation and examples are quite sparse (esp v2)

mholt 4y ago
What do you struggle with about the documentation or "more complex setups"? I was just on the phone recently with Stripe who has a fairly complex, large-scale deployment, and they seemed to have figured it out with relative ease. I'm currently on a push to improve our docs, especially for beginners, so feel free to review the changes and leave your feedback: https://github.com/caddyserver/website/pull/263 https://github.com/caddyserver/website/pull/263
- GordonS 4y ago
  I'm not the GP, but I've had a similar experience, with the Caddy docs seeming good for simple configurations, but lacking for more complex ones. I last setup a Caddy config maybe 6- 9 months ago, and everything related to client certificates was either scantily documented, wrongly documented, or not documented at all. It might be I got unlucky, as some of the client cert features were fairly new, but it wasn't a great experience. Still, I much prefer Caddy's config system to Nginx or HAProxy. Oh, something else I'd really love to see are more fully-featured example configs, as it can be hard to know how to start sometimes.
  - gunapologist99 4y ago
    I agree completely. Fully-featured examples would be extremely helpful, especially with things like proxying to different servers for different paths and domains, static file serving set up differently for different paths and domains, various plugin setups, etc.
    - mholt 4y ago
      Oh, just saw this. You wrote your comment while I wrote mine. If you can enumerate specifically what you want to see, please submit it to our issue tracker: https://github.com/caddyserver/website https://github.com/caddyserver/website Generally we encourage examples in our community wiki though: https://caddy.community/c/wiki/13 https://caddy.community/c/wiki/13 -- much easier to maintain that way.