Hacker News Reader

So you have 20 containers each running their own version of the OS? Don't you have to spend a lot of time keeping all of those up to date with OS/library/app updates?

It seems like the kind of thing that makes sense if you have a big deployment anyway, so you might as well hive stuff off, but makes much less sense if you're a "small" shop.

View on HN

What happens is you'd rearchitect (if needed) your stack so that it scales across N-nodes (for each tier). Then docker build files & snapshotting features allow you to 'recompose' the image from a base OS, one step of which is to apply all patches.

So when you are performing patching, you'd bring a container into service with the updated patches, send some traffic to it (possibly tightly controlled to minimise disruption), verify and then put into production. Iterate through your N-nodes per tier and you've patched. Every container after the first is rapidly started up (just the cost of a supervisor/init & the application process).

No. The containers share the same OS.

Can you make changes in the underlying OS image, and those changes are directly visible in the application images, without restarting said applications?

Reply on news.ycombinator.com