Upgrading Executable on the Fly
nginx.org
Upgrading Executable on the Fly
1–10 of 72 posts
Re: Upgrading Executable on the Fly
#2We did this for Caddy 1 too [1]. It was really cool. I am not sure how many people used this feature, so I haven't implemented it for Caddy 2 yet, and in the ~two years that Caddy 2 has been released, I've only had the request once. It's a bit tricky/tedious to do properly, but I'm willing to bring it over to Caddy 2 with a sufficient sponsorship.
[1]: https://github.com/caddyserver/caddy/blob/v1/upgrade.go
Re: Upgrading Executable on the Fly
#3I've implemented this a few times in a few languages based on exactly what nginx does. It works well, and it is pretty straight forward if you are comfortable with posix style signals, sockets, and daemons.
I'm not sure it is super critical in the age of containerized workloads with rolling deploys but at the very least the connection draining is a good pattern to implement to prevent deploy/scaling related error spikes.
Re: Upgrading Executable on the Fly
#4I've implemented this a few times in a few languages based on exactly what nginx does. It works well, and it is pretty straight forward if you are comfortable with posix style signals, sockets, and daemons. I'm not sure it is super critical in the age of containerized workloads with rolling deploys but at the very least the connection draining is a good pattern to implement to prevent deploy/scaling related error spi…
Even with containerized workloads, you still have an ingress, or SPOF (or multiple, when using multicast), and the seamless restart is meant for exactly those processes. Nginx is often used (https://kubernetes.github.io/ingress-nginx/), or when you use AWS, GCS etc they provide such a service for you.
Not sure how the cloud providers do it though, maybe combination of low DNS TTL and rolling restart since they often have huge fleets of servers which handle ingress?
Re: Upgrading Executable on the Fly
#5How do the two processes listen to the same port?
Re: Upgrading Executable on the Fly
#6The systemv init script for nginx had an upgrade operation (in addition to start/stop/reload etc) which would send the signal. Worked like a charm.
Re: Upgrading Executable on the Fly
#7See Envoy Proxy's Hot Restart [0]
0. https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overv...
Re: Upgrading Executable on the Fly
#8I've always found the multi-process approach taken by both nginx and apache to be nothing but a hindrance when you have to write a custom module. It means that you may have to use shared memory, which is a PITA.
I don't know why they haven't moved on from it; it only really made sense when uni-core processors were the norm.
Re: Upgrading Executable on the Fly
#9Just a shout out: it's super hard to do it for UDP / QUIC / H3. Beware.
(but I don't think nginx supports h3 out of the box yet)
Re: Upgrading Executable on the Fly
#10How do the two processes listen to the same port?
There’s an ioctl for this on FreeBSD and Linux — SO_REUSEPORT. You could also just leave the listening socket open when exec’ing the new httpd, or send it with a unix domain socket.