Comparison
ContainervsContainer image
Container
the process thinks it has its own machine, and on the host it is one ordinary PID among hundreds.
A normal process on a shared kernel, given a private view of the filesystem, the network and the process table, and capped in what it may consume. There is no virtual machine and no boundary you could point at — the isolation is a set of kernel features applied to something that would otherwise be an ordinary program. That is why containers start in milliseconds and why a kernel bug is a much more serious event here than it is between two virtual machines.
Full entry →Container image
you ship a tarball of a whole filesystem plus a line saying what to run, and the same bytes go to every environment.
The build output a container is started from: a stack of filesystem layers plus a small configuration document naming the entrypoint, environment and working directory. It is the unit that makes 'works on my machine' testable, because the machine travels with the code. The thing people underestimate is that it is a filesystem, not a package — everything the process opens at runtime either has to be in there or has to be mounted in.
Full entry →