I disagree with this:
> Now, when you have a decent understanding of containers - from both the implementation and usage standpoints - it's time to tell you the truth. Containers aren't Linux processes!
This is a bit of wordplay, I'm assuming, in absence of a word that defines the operating system features that power the concept of containers. To Linux, there is no (to my knowledge) concept of a "container". The container runtime runs your process(es) as the parent and uses the operating systems features to isolate it and restrict it/them. A virtual machine would just be a full emulated version of this, rather than using the operating system to virtualize the network stack. The author is right in that there is no such thing as a container, but only as much as containing is a thing you do, imo. What users think of containers are still just processes though, and I don't think that's an entirely useless abstraction to be cognizant of.
Under the hood, that's all containers are!
If running the same properly designed software exhibits material differences in behavior between a bare metal process and a containerized process, then they aren’t the same as a matter of practical semantics. Ironically, virtualized processes have much closer equivalence to a bare metal process than containerized processes in practice.
Saying a container is “just a process” is like saying a virtual machine is “just a process”, both are true in some sense depending on how you define “process”. But as a matter of practical engineering, they are different kinds of things.
Fantastic distillation. Thank you!
Fortunately the container architecture is flexible so that you can use as much or as little of it as you like.
I also tend to think that if you want stronger isolation for security purposes then you will want a lightweight VM rather than a container (and if you are worried about side channels, probably hardware partitioning - good luck.)
Incorrect. The images are mere files(/subtrees), and you can write one however you wish.
