News for hackers. Stuff that matters.
Re:Why I Built Litestream by lancehasson on Thursday February 11, 2021 @01:25PM (#26105246)
> Solutions such as Kubernetes tout the benefits of zero-downtime deployments

To be fair, these features of k8s are nice to have. Is there a similar tool for running single node (i.e. ec2) instances that offers zero-downtime deploys? One way you could do it is run a EKS cluster with a single ec2 node running your single-node setup. You could get the benefits of k8s while still running the simple single-node arch

Re:Why I Built Litestream by benbjohnson on Thursday February 11, 2021 @01:35PM (#26105370)
You can do zero-downtime deploys on a single node with tools like seamless[1]. That works for Go but I'm sure there are other options for other languages. I'm not sure if/how you can do it with a containerized workload on a single node though. I haven't tried that.

[1] https://github.com/rs/seamless

Re:Why I Built Litestream by lancehasson on Thursday February 11, 2021 @03:08PM (#26106433)
Cool, hadn't heard of seamless. Something similar to this for other langs wrapped in a CLI with an integration with Digital Ocean/AWS/etc. could be valuable
Re:Why I Built Litestream by knowhy on Thursday February 11, 2021 @03:13PM (#26106495)
> From the kernel point of view, there is a only one socket with a unique listen queue. This socket is associated to several file descriptors: one in systemd and one in the current process. The socket stays alive as long as there is at least one file descriptor. An incoming connection is put by the kernel in the listen queue and can be dequeued from any file descriptor with the accept() syscall. Therefore, this approach actually achieves zero-downtime deployment: no incoming connection is rejected. [0]

systemd can be sufficient for a zero-downtime deployment.

[0] https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket...