4 ms·

All of these arguments are well-aired, and the tone of the article doesn't make this particular presentation of them more useful than any of the others. I would

All of these arguments are well-aired, and the tone of the article doesn't make this particular presentation of them more useful than any of the others. I would guess a large portion of the developers actively using containers are well aware that they are built from existing system capabilities that can be utilized without docker or any container runtime. I mean this is from 2015: https://chimeracoder.github.io/docker-without-docker/#1 https://chimeracoder.github.io/docker-without-docker/#1. You can argue that the new way of bundling these things together is not better, simpler, more reproducible or less error prone, but whatever... the market has voted. I personally think it is all those things, but we can disagree about that. One thing in particular I wanted to respond to and that is the idea of your container filling up with orphan zombie processes because init is not pid 1. If I understand the issue correctly this can only happen if pid 1 creates child processes and then itself dies/exits. I've never personally seen this issue in four years of working with containers, and since all of our containers now run on k8s they would be restarted if pid 1 exited abnormally or otherwise. I'll be interested to see if any other HN commenters have actually had this problem. Also re: the supposed absurdity of one process per container... it's just simpler and works more robustly with orchestration. Containers are lightweight, so there's no reason to try to pack a whole system into an image. It's simpler to reason about a composition of containers than a mess of processes running inside a single container, imo.

adrianmonk 8y ago
Yeah, their zombie process argument is weak. In theory, you are vulnerable because you've eliminated the zombie reaping mechanism. In practice, the fact that you're running only one application allows you to make lots of simplifying assumptions so you can avoid getting into this situation quite easily. Just stick with a model where parents never exit before children (and always reap children). You don't need an adoptive parent if you never create orphans. And even if it did happen, the resource consumption is tiny. Zombie processes free all their memory, close all their files, etc. The only remainder is a small data structure necessary to support stuff like the wait() call returning the process's exit status.

adrianmonk 8y ago

Yeah, their zombie process argument is weak. In theory, you are vulnerable because you've eliminated the zombie reaping mechanism. In practice, the fact that you're running only one application allows you to make lots of simplifying assumptions so you can avoid getting into this situation quite easily. Just stick with a model where parents never exit before children (and always reap children). You don't need an adoptive parent if you never create orphans. And even if it did happen, the resource consumption is tiny. Zombie processes free all their memory, close all their files, etc. The only remainder is a small data structure necessary to support stuff like the wait() call returning the process's exit status.