News for hackers. Stuff that matters.
Re:The Simplicity of Single-File Golang Deployments by klodolph on Wednesday March 22, 2023 @10:26AM (#35261521)
Some of this is solved by using e.g. systemd, depending on your needs.

> I couldn't have the old and the new version of my service running on the same port...

You can, actually! You just can’t open the port twice by default. So one or both of the processes needs to inherit the port from a parent process, get passed the port over a socket (Unix sockets can transmit file descriptors), or use SO_REUSEADDR.

There are some libraries that abstract this, and some of this is provided by tools like systemd.

Some of this is probably going to have to be done in your application—like, once your new version starts, the old version should stop accepting new connections and finish the requests it has already started.

Re:The Simplicity of Single-File Golang Deployments by mattbillenstein on Wednesday March 22, 2023 @10:35AM (#35261685)
So can I just start another process with SO_REUSEADDR and gracefully shutdown the old process?

The master/worker thing that nginx / gunicorn et al do is pretty neat, but relies on signals; so seems pretty messy and error prone to write yourself.

Re:The Simplicity of Single-File Golang Deployments by klodolph on Wednesday March 22, 2023 @10:53AM (#35261979)
You may have to start both processes with SO_REUSEADDR, I don’t remember the exact semantics.

People have a healthy skepticism of signals from the C days, but if we’re talking about Go, you’d just call signal.Notify. Any way of signaling your app to shut down works, though.

https://pkg.go.dev/os/[email protected]#Notify

Re:The Simplicity of Single-File Golang Deployments by joncfoo on Wednesday March 22, 2023 @10:48AM (#35261868)
> Some of this is probably going to have to be done in your application...

FWICT tableflip does exactly this: https://github.com/cloudflare/tableflip