Live data from Hacker News

Ask HN: How to do rolling deployments without Kubernetes?

news.ycombinator.com

11–19 of 19 posts

Re: Ask HN: How to do rolling deployments without Kubernetes?

#11

Instead of talking about specific technologies/software/services, I'll give a quick rundown how you can achieve this in theory, and hopefully it can apply to whatever you're currently using. The requirements: - Your application should be able to run on arbitrary ports, preferably controlled with env vars or similar - You need to have something in front of your application, like nginx or apache - Whatever webserver yo…

While this is right, I'm not sure why you mentioned pausing requests. If you can run v1 and v2 at the same time, you could switch where the new requests are going without affecting the old ones. There's many ways to do that, but what I do is point nginx upstream at a path which is a symlink to a Unix socket of a specific version. So it's more like: start the new version, check, update symlink, wait until old connecti…

Yeah, nginx and apache have ways of reloading the configuration without dropping requests (by waiting for existing ones to finish with old workers, and spinning up new workers with the new config in the case of nginx) but doesn't apply in every situation (like when you're not using nginx) so figure I'd write about the general principle instead of specifically for nginx.

Re: Ask HN: How to do rolling deployments without Kubernetes?

#12
post #9

Instead of talking about specific technologies/software/services, I'll give a quick rundown how you can achieve this in theory, and hopefully it can apply to whatever you're currently using. The requirements: - Your application should be able to run on arbitrary ports, preferably controlled with env vars or similar - You need to have something in front of your application, like nginx or apache - Whatever webserver yo…

> Instead of talking about specific technologies/software/services, I'll give a quick rundown how you can achieve this in theory, and hopefully it can apply to whatever you're currently using. I wish more people approached their software engineering teaching in this way. Thank you for the great comment.

> I wish more people approached their software engineering teaching in this way.

Me too, so why not do it myself? :) Thanks for the feedback

Re: Ask HN: How to do rolling deployments without Kubernetes?

#13
Dokku does this.

You either deploy from command line or something like a GitHub action (or CI).

Container 1 and 2 are briefly running concurrently, and networking is updated to point to the new container once it finishes its build phase, and passes any pre-defined tests (or after 10 seconds of running without crashing).

Re: Ask HN: How to do rolling deployments without Kubernetes?

#15
If you want no downtime server updates, you have choices:

a) remove server(s) from load balancing, finish requests/connections in progress, restart with new software, add to load balancing

b) hot loading

c) start a new server instance and pass it the listen socket (or if your OS isn't great, drop syns for a bit while you close the listen socket on the old server and open a new listen socket for the new server)

I like hotloading, but it's not appropriate for all updates, so you need to have a way to handle restart based updates as well.

Re: Ask HN: How to do rolling deployments without Kubernetes?

#16
Zero-downtime deployments have existed years (perhaps decades?) before k8s was released to the public.

Controlling the upstream traffic via haproxy/nginx allowed Ops to roll out blue-green, canary and waterfall/rolling deployment methods albeit with more human interaction.

Digital Ocean have this [0] article from 2014 on load balancing.

[0] https://www.digitalocean.com/community/tutorials/an-introduc...

Re: Ask HN: How to do rolling deployments without Kubernetes?

#17

Earlier quoted context omitted.

While this is right, I'm not sure why you mentioned pausing requests. If you can run v1 and v2 at the same time, you could switch where the new requests are going without affecting the old ones. There's many ways to do that, but what I do is point nginx upstream at a path which is a symlink to a Unix socket of a specific version. So it's more like: start the new version, check, update symlink, wait until old connecti…

Yeah, nginx and apache have ways of reloading the configuration without dropping requests (by waiting for existing ones to finish with old workers, and spinning up new workers with the new config in the case of nginx) but doesn't apply in every situation (like when you're not using nginx) so figure I'd write about the general principle instead of specifically for nginx.

You can do this with (or without) any proxy too. Iptables (due to conntrack) can make decisions about the first packet in a connection, then save the result. That means you can match incoming traffic on --state NEW and route to a specific local port. Changing one iptables entry is atomic, so you can swap the version seamlessly this way.

I think the idea is worth mentioning because people often think it's hard to achieve / something special. But there's a hundred ways to do seamless version swap on a host.

Re: Ask HN: How to do rolling deployments without Kubernetes?

#18

Earlier quoted context omitted.

Yeah, nginx and apache have ways of reloading the configuration without dropping requests (by waiting for existing ones to finish with old workers, and spinning up new workers with the new config in the case of nginx) but doesn't apply in every situation (like when you're not using nginx) so figure I'd write about the general principle instead of specifically for nginx.

You can do this with (or without) any proxy too. Iptables (due to conntrack) can make decisions about the first packet in a connection, then save the result. That means you can match incoming traffic on --state NEW and route to a specific local port. Changing one iptables entry is atomic, so you can swap the version seamlessly this way. I think the idea is worth mentioning because people often think it's hard to achi…

Wow, that's a good point. Obvious in hindsight, but personally I never considered iptables for that job. Thanks for sharing this!
Post reply on HN