[HN Gopher] Sozu - HTTP reverse proxy in Rust for immutable infr...
___________________________________________________________________
Sozu - HTTP reverse proxy in Rust for immutable infrastructures
Author : lwhsiao
Score : 58 points
Date : 2023-03-29 18:00 UTC (5 hours ago)
(HTM) web link (www.sozu.io)
(TXT) w3m dump (www.sozu.io)
| jaxxstorm wrote:
| > Upgrades without restarting: Sozu is always-up, meaning it
| upgrades itself while still processing requests.
|
| How?
| elitepleb wrote:
| looks like it does the same thing as caddy, taking config
| changes from a socket
|
| probably the same way as nginx
| http://nginx.org/en/docs/control.html#upgrade
| PPACI wrote:
| For all wondering sozu against other reverse proxy, sozu is
| capable of shifting traffic to a new backend without killing a
| single tcp connection. That's extremely useful for real time
| video application. I met the dev team (mostly French) a couple of
| times, they are super nice people!
| citrin_ru wrote:
| Any decent reverse proxy should be able to shift traffic to new
| backend keeping old connections open. Nginx can, though
| combination of long tcp connections and frequent reloads would
| cause it to keep a lot of processes waiting for old connections
| to finish.
| dgl wrote:
| It's AGPL licensed which for a proxy is a strange choice. They
| have an unanswered question for months on what it might mean:
| https://github.com/sozu-proxy/sozu/issues/764
|
| Without an answer to that if you use this and you need to make
| any change to it (even a tiny bug fix), you're basically opening
| yourself up a pile of legal issues.
| rowls66 wrote:
| Product description says:
|
| a HTTP reverse proxy built in Rust, that can handle fine grained
| configuration changes at runtime without reloads, and designed to
| never ever stop.
|
| How is that immutable? Sounds like it is highly mutable by
| design.
| wmf wrote:
| Because the backend servers/containers/pods are immutable,
| every deployment creates new backends (that have new IPs) and
| then kills the old backends. This requires changing the proxy
| config at runtime. In the old days the backends would be
| mutable and would be updated in-place, keeping their IPs, so
| you could leave the proxy config alone.
| motoboi wrote:
| I'm sure the OP understood. But there is fine irony in the
| fact that a product that sells itself as immutable
| infrastructure is highly mutable.
| wmf wrote:
| I hate to be that guy but this sounds no different from linkerd.
| seized wrote:
| Or HAProxy.
| ofchnofc wrote:
| [dead]
| jedberg wrote:
| I'd love to see this go head to head with Haproxy.
| Aldipower wrote:
| Flash in my mind: Use `systemctl reload nginx` instead of
| `systemctl restart nginx` for gracefully hot reloading nginx
| configs.
| anotherhue wrote:
| nginx config parsing can be slow for large deployments. Or at
| least it could 5 years ago when we had this issue.
| dig1 wrote:
| With IP Tableflipping [1], you can have live reloads & upgrades
| without losing a single packet and it is not web/proxy server
| dependent. Also, HAProxy has live reloads and upgrades from 1.8
| by transferring socket connection from the old to the new
| instance. [2]
|
| [1] https://inside.unbounce.com/product-dev/haproxy-reloads/
|
| [2] https://www.haproxy.com/blog/hitless-reloads-with-haproxy-
| ho...
___________________________________________________________________
(page generated 2023-03-29 23:01 UTC)