16:39 <Majiir> Is there a way (on Linux) to bring up a new process listening on a TCP port and have that seamlessly take over any new connections?

16:39 <Majiir> without already having a whole load balancer in place

16:49 <r4m0n> you mean with a process already listening on it?

16:50 <r4m0n> if so, nothing pretty... but you could write an iptables rule to "load balance" that. start the new process on another port, redirect half the connections that way randomly with iptables

16:53 <Majiir> Hum

16:54 <Majiir> Yeah, that would work quite well actually.

16:55 <r4m0n> you're probably looking for a REDIRECT rule, probably on PREROUTING, with --random

16:55 <Majiir> Is that more or less just DNAT?

16:55 <Majiir> Routing 100% of the traffic to the new process would be fine too, and then once I bring the old one down, I can have the new one bind on the original ports

16:56 <Majiir> (or repeat the dance again)

16:56 <r4m0n> then just a straight redirect will do. might be on the INPUT table

16:57 <r4m0n> the random one would lose some packets as the other process go down

16:57 <r4m0n> it's quite blind, it'll just rewrite the packets

16:57 <SilverFox> so all that's negative about it is some packet loss during switching?

16:58 <Majiir> If you redirect everything, there shouldn't be any packet loss

16:58 <r4m0n> yep

16:58 <Majiir> The downside is iptables is a bit clumsy compared to a proper balancer. It'll be a bit of digging up commands to find out when all the open connections are drained.

16:59 <Majiir> The process in question is nginx, so that's actually easy; it can just stop and wait for connections to close on its own.

16:59 <r4m0n> just netstat will do to track the currently open ones

17:00 <r4m0n> I'm assuming this is all very mission-critical, 99% of admins just restart the thing and let connections bounce for as bit XD

17:00 <Majiir> Oh I know very well how poorly this is done in real production systems

17:01 <Majiir> I like to practice with paranoia on my personal crap where it doesn't matter so I have the experience to yell at the ops guys who just took down production for half our users when I'm at work

17:02 <r4m0n> this is pretty good thinking overall, haven't actually never thought of doing it this way

17:02 <r4m0n> though you have to setup a secondary webserver to handle the traffic while the main one updates/gets replaced

17:03 <Majiir> The use case here is I'm moving nginx into a Docker container, and then later migrating that over to a different host. For my sites to work properly, nginx needs to bind on the host network directly, which means I need to bring up the container on ports other than 80/443 at first.

17:05 <Majiir> It's easy to say I have zero people using my services so downtime doesn't matter. It's fun to practice zero DT though.

17:05 <SilverFox> zero downtime is nice

17:05 <r4m0n> so something like bring the docker one on port 888, redirect 80 to it, kill old process, add port 80 to the docker one, reload config, kill iptables rule, remove port 888, reload rules

17:06 <Majiir> Yep. Since the nginx container needs to be directly on the host network, I should be able to have it bind to 80 after reload without restarting the container.

17:07 <r4m0n> just check that ports under 1024 need root permission to bind

17:07 <Majiir> Shouldn't be an issue since Docker is privileged anyway

17:08 <r4m0n> as long it isn't on paranoid permissions, everything should be fine :-)