[HN Gopher] Pingora: build fast, reliable and programmable netwo...
___________________________________________________________________
Pingora: build fast, reliable and programmable networked systems
Author : KajMagnus
Score : 204 points
Date : 2024-02-28 09:56 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Sytten wrote:
| I had been waiting on that for a couple years since they first
| talked about it in their blog. Congrats!
| KajMagnus wrote:
| Me too! Nginx (written in C) sometimes have can't-happen-in-
| Rust major severity vulnerabilities, one just recently:
| https://nginx.org/en/security_advisories.html (related to
| HTTP3)
| ttrrooppeerr wrote:
| Their, at the time, blog post announcement about Pingora:
| https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
| mcpherrinm wrote:
| And a current blog post announcing the Open-sourcing:
| https://blog.cloudflare.com/pingora-open-source
| eptcyka wrote:
| Would be cool of it was possible to use this with rustls. But I
| assume they didn't use it since i rustls o ly focuses on TLS 1.3
| and does not support anything lower.
| phicoh wrote:
| Rustls claims to support TLS 1.2 as well
| (https://github.com/rustls/rustls)
| mcpherrinm wrote:
| Being able to use rustls as a drop-in replacement for openssl
| is on their roadmap:
| https://github.com/rustls/rustls/blob/main/ROADMAP.md#future...
|
| So that'll certainly one option in the future.
| diarrhea wrote:
| Very cool. Would play around with this in a heartbeat in the home
| lab, but Caddy's automatic HTTPS (ACME HTTP-01 and DNS-01
| challenges) would be sorely missed.
|
| I suppose one can supplement certbot in this setup? Or use the
| "highly programmable" APIs Pingora provides directly?
| hermanradtke wrote:
| cert it via cron that uses the graceful upgrade functionality
| should work
|
| https://github.com/cloudflare/pingora/blob/main/docs/quick_s...
| sanxiyn wrote:
| I heard that when Cloudbleed happened, Cloudflare CTO declared
| that there will be no more new projects in C or C++, and that's
| how it happened. Needless to say, lots of time and money were
| wasted.
| pas wrote:
| > Needless to say, lots of time and money were wasted.
|
| it might be needless, but for those of us not in the know,
| could you elaborate on that please? what ended up as waste?
| why? altogether was it worth it?
| diarrhea wrote:
| This person seems to be a Rust contributor, so if this isn't
| a jab against Rust, I'm not sure what their point is.
| sanxiyn wrote:
| These kinds of top down directives are almost always
| wasteful, because they ignore local situations. It could have
| been case by case decisions, considering cost and benefit.
|
| Now I understand why this is politically difficult, but it
| still resulted in suboptimal technical decisions, and ill
| will against Rust, which is unfortunate.
| rapsey wrote:
| I would imagine cloudbleed shook the company severely. I
| doubt the decision to abandon C/C++ caused a lot of ill
| will within the company. Considering the level of exposure
| Cloudflare software has, it is I think a very level headed
| decision.
| sanxiyn wrote:
| Decision to abandon C/C++ is okay I would say. Decision
| to abandon C/C++ immediately is less so.
| phicoh wrote:
| It is my impression (as an outsider watching CF) that
| they have a bit of a not-invented-here problem. So if CF
| already has a culture of rewriting things, then rewriting
| it in Rust is not such a bad idea.
|
| The problem is more that rewriting code that has a long
| history and is in wide-spread use tends to lose that
| history and any real world experience embedded in the
| code.
|
| But if otherwise they would have written something in C++
| then that point is moot.
| pas wrote:
| sorry, but for me this is still heavily [citation needed]
|
| sure CTO says something, but what exactly happened? do we
| know? you wrote that no new C/C++ projects were started.
| that to me sounds perfectly reasonable phase-out.
| _joel wrote:
| No.
| sophacles wrote:
| Do you have any evidence for any of the parts of your
| statement? Those are some big claims and some evidence is
| warranted - rumors can say just about anything and usually are
| far from the full truth (and often completely false).
| sanxiyn wrote:
| https://lobste.rs/s/0akqy7#c_ihruks
| uo21tp5hoyg wrote:
| > I was right: it was a risk, and it did slow us down.
| However, by being forced to use Rust, we ended up with a
| better design that was safer and easier to debug, and it
| was just as fast as the C++ equivalent. In the long run, it
| was a massive win. We're all in love with Rust now, and 5
| years later we've replaced nearly all of our non-Rust code
| (mostly Go) with faster, safer, and better-architected Rust
| equivalents.
|
| Seems like a win?
| pornel wrote:
| Before Rust, most features had to be built on top of nginx, and
| had to carefully balance performance overhead of Lua
| (openresty) vs risks and maintenance costs of C modules or
| patching nginx itself.
|
| The switch to Rust has been very positive overall, because it
| allowed Cloudflare to tackle much more ambitious projects, and
| own its entire stack.
| inapis wrote:
| so in a quick glance, this does not look like nginx/caddy. It is
| not a binary you download, install and just configure to talk to
| your upstream servers. Rather a set of packages which you
| assemble to fulfill a particular use case. You basically end up
| writing a "new" reverse proxy just for your use case.
|
| Not sure how useful this would be for anyone except very large
| businesses or someone like cloudflare itself.
| wongarsu wrote:
| From their quickstart and user guide it doesn't look too
| verbose. For anyone whose config has reached the point where
| you are wondering whether it would be easier to express in
| code, this might be a good product to try.
|
| Or if you run shared hosting or some other scenario where you
| are effectively maintaining your server configuration twice:
| once for the actual server and once in the database for your
| dashboard and other services. This would allow you to just read
| the config from the canonical source, instead of risking bugs
| when the two configs diverge.
| egnehots wrote:
| from their doc, Reasons to use Pingora:
|
| - Security is your top priority: Pingora is a more memory safe
| alternative for services that are written in C/C++.
|
| - Your service is performance-sensitive: Pingora is fast and
| efficient.
|
| - Your service requires extensive customization: The APIs
| Pingora proxy framework provides are highly programmable.
| paulgb wrote:
| One reason I'm excited about this is that it appears to let you
| write arbitrary routing logic into a layer 7 proxy. This is
| something we had to build for https://plane.dev and it would
| have been nicer to use something like this, but we couldn't
| find anything like it at the time.
| mcpherrinm wrote:
| River is going to be a fully-featured reverse proxy product
| built on top of Pingora:
|
| https://www.memorysafety.org/blog/introducing-river/
|
| It's mentioned briefly in the Cloudflare blog post. I'd expect
| that if you're a current nginx or other proxy, River is what
| you'd want as an alternative.
|
| One of the big things I'm excited about in the River plan is
| the ability to use wasm for scripting, which should make it
| relatively easy to extend.
| derekperkins wrote:
| I'm surprised Envoy isn't mentioned anywhere
| dang wrote:
| Related:
|
| _Cloudflare has replaced Nginx with in-house, Rust-written
| Pingora_ - https://news.ycombinator.com/item?id=32864119 - Sept
| 2022 (141 comments)
|
| _Pingora, the proxy that connects Cloudflare to the Internet_ -
| https://news.ycombinator.com/item?id=32836661 - Sept 2022 (123
| comments)
| jamesear wrote:
| Cloudflare work on some cool stuff! It's a shame they don't hire
| for software engineer positions in Australia.
| adamch wrote:
| There are some CF SWEs in Australia. But few teams are willing
| to work across 3 timezones. The SRE teams might be more open to
| hiring, as there's a big SRE presence in Singapore.
| bogwog wrote:
| https://www.spanishdict.com/translate/pinga
| throwaway63467 wrote:
| Nice! It seems HTTP/3 isn't mentioned or supported, which is
| weird as they offer HTTP/3 support in their cloud service and
| have their own QUIC implementation. Haven't looked in detail so
| maybe it's just missing from the readme or they didn't open-
| source it (yet).
| pornel wrote:
| Cloudflare uses QUIC on the browser<->cdn side, but Pingora
| sits on the cdn<->server side.
|
| That side of the connection usually isn't going over slow and
| lossy mobile networks, so QUIC isn't that useful there.
| gideontong wrote:
| HTTP/3 is on the roadmap!
___________________________________________________________________
(page generated 2024-02-28 23:02 UTC)