5 ms·
Can you live fork containers like you can VMs? VM clone time is surprisingly quick once you stop copying memory, after that it's mostly ejecting the NIC and br
by bobmcnamara 1y ago
Can you live fork containers like you can VMs?
VM clone time is surprisingly quick once you stop copying memory, after that it's mostly ejecting the NIC and bringing up the new one.
- mort96 1y agoI can't say I've ever cared about live forking a container (or VM, for that matter)
- hinkley 1y agoYour cloud provider may be doing it for you. Ops informed me one day that AWS was pushing out a critical security update to their host OS. So of course I asked if that meant I needed to redeploy our cluster, and they responded no, and in fact they had already pushed it. Our cluster keeps stats on when processes start. So we can alert on crashes, and because new processes (cold JIT) can skew the response numbers, and are inflection points to analyze performance improvements or regressions. There were no restarts that morning. So they pulled the tablecloth out from under us. TIL.
- mort96 1y agoNone of this is making live forking a container desirable to me, I'm not a cloud hosting company (and if I was, I'd be happy to provide a VPS as a VM rather than a container)
- hinkley 1y agoThere’s using a feature, having a vendor use it for you, or denying its worth. Anything else is dissonant.
- mort96 1y agoFor the VM case, I'm sure I might have benefited from it, if Digital Ocean have been able to patch something live without restarting my VPS. Great. Nothing I need to care about, so I have never cared about live forking a VM. It hasn't come up in my use of VMs. It's not a feature I miss in containers, is what I'm saying.
- marcosdumay 1y agoYou mean creating a different container that is exactly equal to the previous one? It's absolutely possible, but I'm not sure there's any tool out there with that command... because why would you? You'll get about the same result as forking a process inside the container.
- bobmcnamara 1y agoIt's useful if you want to bring up a containerized service, optionally update OS, run tests, and if everything is good, copy that instance a bunch of times rather than starting fresh. It gets you scale out a batch of VMs remarkably quickly, while leaving the original available for os/patch updates. If I'm willing to pay the cost of keeping an idle VM around, subsequent launches are probably an order of magnitude faster than docker hello-world.
- 9dev 1y agoWhy would you, if you can simply start replacement containers in another location and reroute traffic there, then dispose of the old ones?