[HN Gopher] Nginx Modern Reference Architectures
___________________________________________________________________
Nginx Modern Reference Architectures
Author : mooreds
Score : 61 points
Date : 2022-05-19 16:27 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nikivi wrote:
| I am curious why I should consider using nginx when Caddy
| (https://caddyserver.com) exists. It seems to have more activity
| behind it.
| eddieroger wrote:
| I used to use Caddy in the v1 days, but after some really
| unfortunately licensing decisions (which I think were reverted
| ultimately), I felt burned and stopped using it. It was my go-
| to for static site serving containers for a while, but because
| some of the time I need to make what they considered
| "commercial" ones (work related), I couldn't any longer. And it
| was handled really poorly in my recollection, with some random
| sponsor header injection. I decided that nginx on a slim distro
| container is more than fine most of the time.
| maxloh wrote:
| Candy is written in Go (a garbage-collected language), which in
| theory slower than C (the language Nginx is written in).
| megous wrote:
| Because there are some benefits to using established software:
| Reading package lists... Done Building dependency
| tree... Done Reading state information... Done
| E: Unable to locate package caddy
| francislavoie wrote:
| For various reasons, we provide our own apt repo:
| https://caddyserver.com/docs/install#debian-ubuntu-raspbian
|
| Biggest reason is that debian's packaging requirements are
| way too much of a burden for us to conform to, especially for
| Go apps. And they update way too slow for us to be
| comfortable with.
| formerly_proven wrote:
| I recall some licensing fuss with Caddy but it looks like it's
| actually open source now. But stuff like this does tarnish a
| brand for a long time, see e.g. people still being uncertain
| about Qt licensing, not because of the more recent
| developments, but because of licensing issues that were settled
| _in the 90s_.
| mholt wrote:
| Caddy has always been open source. The source code has always
| been Apache licensed.
| qbasic_forever wrote:
| In the context of kubernetes ingress caddy isn't really there
| yet, at least compared to nginx (which has two major k8s
| ingress implementations, one maintained by the core k8s devs
| themselves).
| francislavoie wrote:
| That is true, unfortunately. We, the core maintainers, don't
| use k8s ourselves, so we need to defer to the community for
| help. See https://github.com/caddyserver/ingress
| qbasic_forever wrote:
| Yeah the whole k8s ingress world is a moving target that
| has changed substantially even in the last year or two. I
| don't blame you for not spending a ton of time on it. Caddy
| is still an awesome option to run inside a pod that needs
| to have a simple static file server, do some reverse
| proxying to services in the pod, etc.
| heurisko wrote:
| When I evaluated Caddy it was missing some features, such as
| rate limiting.
|
| But I think Caddy is a fine server as well.
| francislavoie wrote:
| Rate limiting plugin: https://github.com/mholt/caddy-
| ratelimit
| heurisko wrote:
| Yes, I came across that. Didn't really compare to rate
| limiting in nginx, in terms of maturity or support.
|
| > WORK IN PROGRESS: Please note that this module is still
| unfinished and may have bugs. Please try it out and file
| bug reports - thanks!
| francislavoie wrote:
| Sure, but it'll never reach maturity if you don't try it!
| We're always looking for more people to test things out,
| give their thoughts, and contribute ideas or fixes.
| loganmarchione wrote:
| I don't think any large corporations are using Caddy.
| Everywhere I've worked has used Nginx for any high-traffic
| applications.
|
| As a side note, I'm looking at Traefik in my homelab and it's
| honestly difficult because I'm so comfortable with Nginx.
| number6 wrote:
| It's difficult because of the boilerplate. Compare traefik
| with caddy-docker-proxy. Same feature set but only 30% of the
| code
| mholt wrote:
| There are several large corporations using Caddy. Several
| companies you've heard of and probably used the products of!
| I have a call with one of them every few weeks.
|
| I also know a huge hospital chain in the US is using Caddy.
| tfigment wrote:
| Caddy has problems with streaming gRPC (not simple
| request/response). So does Traefik to my understanding but
| Traefik might work better if reports are to be believed.
| Nginx has support i think but ive not verified it. I like
| caddy simple config when it works.
|
| None of the proxies seem to do well with bidirectional gRPC
| streams as they just treat gRPC as a h2 proxy but I'd love
| to see that proven wrong.
| m_sahaf wrote:
| Caddy _is_ capable of handling bidirectional gRPC
| streams! I have just tested it, and it works just fine.
| Caddy will immediately flush writes when upstream is `h2`
| or `h2c`[0] instead of having to wait until reading from
| socket is complete
|
| I used this Caddyfile to proxy to the route_guide example
| (https://github.com/grpc/grpc-
| go/tree/master/examples/route_g...):
|
| ```
|
| localhost { reverse_proxy
| h2c://localhost:50051
|
| }
|
| ```
|
| It works like a charm.
|
| [0] https://github.com/caddyserver/caddy/blob/e4ce40f8ff0
| 4240540...
| chamakits wrote:
| From my limited and possibly outdated experience (about a year
| since I last looked), caddy's documentation was lacking a bit
| when compared to nginx.
|
| Even worse than that, any time I tried to google to better
| understand how to do something with caddy, every result
| returned how to achieve exactly that with nginx; and would
| rarely find the way to do it with caddy.
|
| But it's been about a year since that, unsure if things have
| changed.
| francislavoie wrote:
| > caddy's documentation was lacking a bit when compared to
| nginx
|
| Could you be more specific? We keep hearing vague comments
| like this about our docs, but without feedback pointing to
| specific issues, we can't improve them.
|
| I suggest that next time you have trouble finding the
| information you're looking for, reach out to us and let us
| know. Open a topic on the forums, we'll be glad to help you
| find what you're looking for. And if you do so and point out
| a lack in our docs, we'll know where to focus our efforts.
| zmxz wrote:
| Seeing you're someone capable of using a web server, it implies
| you're beyond capable of finding why Caddy over nginx and vice
| versa, which brings up the question: why didn't you?
| alskdjflaskjdhf wrote:
| This kind of response is rude and unhelpful. This _is_ how
| they are finding it out. Just googling "X vs Y" invariably
| gives you worthless SEO spam these days. A forum like HN,
| where you can hear about the experiences of other people in
| the field, is a great way of getting more useful information.
| corrral wrote:
| It's much more widely used and has been around a whole lot
| longer, both of which confer many benefits.
|
| Personally, if nginx made letsencrypt as easy as caddy does,
| I'd never even think about caddy. That's its One Thing that
| kinda tempts me.
| mholt wrote:
| Caddy provides higher memory safety guarantees than C
| servers.
| maxloh wrote:
| Garbage-collected language seems to be slower.
|
| Discord have switched away from Go for some performance-
| critical services because of it. [0]
| https://discord.com/blog/why-discord-is-switching-from-go-
| to...
| francislavoie wrote:
| The webserver will rarely be your bottleneck. Your
| application or database will be long before the webserver
| is.
| zmxz wrote:
| Source? Any content on memory safety concerns in "C"
| servers or problems that lead to catastrophic results in
| production? I'm interested in reading about it.
| xyzzyz wrote:
| Uh, google "heartbleed bug", that's just one example of a
| massive and catastrophic result of lack of memory safety
| in C. It probably costed something on the order of $1B
| for remediation efforts globally.
| zmxz wrote:
| Heartbleed was in openssl. I didn't ask about memory
| safety in C. Caddy author was pretty accurate with his
| statement, I asked for proof. Heartbleed is not the only
| memory leak, there's plenty, C's been around like
| software written in it. I'm aware of shortcomings.
| mholt wrote:
| Guess which web servers use(d) openssl...
| xyzzyz wrote:
| Sorry, I don't get understand your response. Most Caddy's
| competitors use OpenSSL, and so are vulnerable to bugs in
| it. A lot of those bugs, like for example heartbleed, are
| only possible due to the nature of the C language. Those
| kinds of bugs, the memory safety bugs, are prevented when
| using memory safe languages like Go. These bugs are real
| and serious, and collectively cost billions of dollars in
| damages.
| francislavoie wrote:
| https://www.abetterinternet.org/docs/memory-safety/
| ancientsofmumu wrote:
| > _if nginx made letsencrypt as easy as caddy does_
|
| The EFF cerbot plugin has it covered; assuming your generic
| Debian server with nginx already configured to host
| www.domain.com (trivial hello, world setup - nothing fancy)
| then it's: apt-get install cerbot
| python3-certbot-nginx certbot --nginx -d
| www.domain.com -d domain.com \ --agree-tos -m
| "email@domain.com" --no-eff-email \ --deploy-hook
| "systemctl reload nginx" systemctl restart
| nginx
|
| All done. Certbot is already running as a systemd service to
| handle ongoing renewals and it'll now restart nginx if your
| cert is updated. This example uses the trivial http-01 ACME
| method, if you need the more complex DNS based setup for
| wildcards that'll take a bit more elbow grease.
| francislavoie wrote:
| FWIW, having the ACME client separate from the server has a
| bunch of downsides. It's less robust, can't provide OCSP
| stapling and automatic renewal on revocation, doesn't have
| issuer fallback, can't offer you On-Demand TLS, etc.
| pilif wrote:
| I agree with most points, but OCSP stapling is
| independent of ACME and thus is perfectly doable with
| nginx and an externally obtained let's encrypt
| certificate.
|
| That aside, for me the trade-off was different and I was
| willing to give up the benefits of included acme support
| for the benefits of running a very well-supported and
| well-known web server that at this point hosts most of
| the internet and which can run on port 80/443 without
| iptables hacks (not sure whether this still applies to
| caddy)
| francislavoie wrote:
| What I meant was using OCSP status (from stapling) to
| trigger reissuance on revocation. I don't think this can
| be done with nginx and certbot unless nginx makes its
| OCSP status available for the certbot client to read
| from, or having an event trigger in nginx somehow to get
| certbot to run. Either way, it's extra faff that you
| don't need to worry about with Caddy.
|
| > which can run on port 80/443 without iptables hacks
|
| Not sure what you mean. Do you mean that you need root to
| bind to those ports? In which case, you can give the
| process CAP_NET_BIND_SERVICE which lets it. Caddy's
| systemd service does this, and runs as a non-root user: h
| ttps://github.com/caddyserver/dist/blob/2ceb535e076ed9b30
| 83...
| dekobon wrote:
| Disclaimer: I am one of the authors of the project.
|
| I do wish that NGINX made LetsEncrypt as easy as to use as
| Caddy does. We are all big fans of LetsEncrypt and are quite
| happy to see NGINX donating to the project.
|
| In this project (MARA), LetsEncrypt support is integrated via
| [Cert Manager](https://cert-manager.io/) for Kubernetes. This
| is nice because it supports certs from a variety of issuers
| like AWS, Google, Vault, Cloudflare, etc in addition to Let's
| Encrypt.
| hn_version_0023 wrote:
| /me mumbles incoherently about Apache httpd
| attentive wrote:
| funny enough, apache does have mod_md that will deal with
| LetsEncrypt
| aaaaaaaaata wrote:
| Just when I think "It's gotta be secure by now, they must
| have figured it out" there's a new and disturbing Apache
| CVE -- change my view.
| Spivak wrote:
| httpd has the advantage that it has literally every feature
| you could imagine and a million more you couldn't but it's
| a slog to actually use.
| corrral wrote:
| Hahaha, I'm a dinosaur, too. I only started considering
| nginx something other than "that new-fangled crap" a few
| years ago. Caddy may get there in about a decade.
| boardwaalk wrote:
| For concrete comparison, nginx backs something like 40% of
| the top 10k websites. Caddy is a fraction of a percent.
| mooreds wrote:
| Here's the numbers I commonly cite: https://news.netcraft.c
| om/archives/2022/04/27/april-2022-web...
|
| 31% nginx 23% apache 8% Openresty (which I've never heard
| of, looks like it is an augmented nginx) 5% cloudflare
| favorited wrote:
| Openresty is basically Nginx + Lua. I did some POCs on it
| back in the day, honestly surprised it's still around. It
| wasn't bad, just seemed like a product with a very small
| niche.
| mwcampbell wrote:
| If I'm not mistaken, the biggest user of openresty is the
| Kubernetes community-maintained nginx ingress controller
| [1].
|
| [1]: https://github.com/kubernetes/ingress-nginx I took
| pains to say "community-maintained" because there's also
| an official nginx ingress controller from F5 (current
| corporate owner of nginx).
| the_third_wave wrote:
| I never experienced _nginx_ ' way of handling certificates as
| difficult and I prefer to keep my web server independent from
| the certificate management system since I use those
| certificates for more purposes than just web servers so I
| have not looked into the supposedly superior way _caddy_
| handles this workflow. I handle certificate requests and
| updates on a separate system which then distributes
| certificates and handles daemon restarts to where and when
| these are needed by using _certbot_ hooks. All it takes to
| request and distribute a new certificate is a single command
| on that certificate management system, the rest follows
| automagically. Am I missing something by doing things this
| way?
| [deleted]
| turtlebits wrote:
| Maybe it's just me, but the Caddy config file (either the docs
| or the format) isn't great. It took me way too long to turn on
| a simple feature (didn't work, no errors). That plus having to
| relearn the config going from v1 -> v2 turned me off to it.
| AceJohnny2 wrote:
| Tangential: the readme mentions Pulumi [1], an Infratructure-as-
| Code tool I hadn't heard of before.
|
| As an IaC tool, can anyone speak of how it fits in the landscape
| compared to Chef, Puppet, Ansible, SaltStack and, oh, Terraform?
|
| [1] https://www.pulumi.com
| xfalcox wrote:
| Pulumi is Terraform for people who hate HCL shortcomings.
| threeseed wrote:
| Pulumi is Terraform for people who hate Terraform
| shortcomings.
|
| Not to nitpick but there is so much more that is wrong with
| Terraform than HCL e.g. lack of dynamic providers.
| Spivak wrote:
| The Terraform CDK is Terraform for people who hate HCL. I
| really can't fathom why people lock themselves into HCL when
| you could be using Python.
| markbnj wrote:
| It's a polyglot world for IAC, and even standing before
| both tools in their current state I can imagine other axes
| of consideration that might rank as highly as the specific
| characteristics of the language. In our case we adopted TF
| several years back and being able to use a different
| language probably isn't going to be enough benefit to
| justify migrating all our things. I think in many cases
| people will adopt the tool that gives them the most
| confidence that it will do what they need, and deal with
| whatever language it uses.
___________________________________________________________________
(page generated 2022-05-19 23:02 UTC)