Okay, conceptually I understand that they are virtualized machines running discreet applications to fulfill a specific function. The idea is that you’re consuming fewer resources. But that’s about as far as I’ve gotten.
How are they “completely isolated” when they’re sharing the OS? At some point they must be sharing resources and I don’t understand how this is possible when the whole goal is to keep system failures isolated to a specific blast radius.
I’m sure I’ll come up with more questions when I get an answer but that’s where I am atm. Thanks
In: 1
Containers are a special type of virtual machine that allows you to run multiple copies of a parent OS in private, well, containers. Just like multiple virtual machines can run on a hypervisor, sharing resources, but still be private. Containers are also known as OS-Level Virtualization, where a single kernel can provide multiple unique user-spaces. Special considerations must exist in the kernel allow for that isolation into unique spaces.
The OS provides various features which make it possible. [Namespaces][1] are used to isolate a group of processes from each other. [cgroups][3] are used to limit the resources (CPU time, memory) used by those processes. A function called [chroot][2] allows a process to only see a subset of the file system. And so on.
However, the OS provides these features in kind of a haphazard and disorganized way. They evolved over time, added by different developers at different times and for various reasons. The point of a high-level tool like docker is to create an abstraction – a so-called *container* – which is easier to reason about. We simply think of it as an “isolated” Linux machine, even though this is very much an illusion cobbled together out of half a dozen different OS features.
[2]: https://www.geeksforgeeks.org/linux-virtualization-using-chroot-jail/
[1]: https://en.wikipedia.org/wiki/Linux_namespaces
[3]: https://en.wikipedia.org/wiki/Cgroups
There are certain things on a computer that are normally considered global and always exist. 127.0.0.1 as a network target refers to the “local host” and that is the same thing as long as you’re at the same computer (or at least, virtual machine). Drive C is always the same disk. The computer has a name and that name doesn’t change, at least not without every program on the computer noticing it was changed. The running program with PID number 55 is this specific program and as long as it’s running that can’t change.
However, on Linux (and different concepts on different operating systems) we said, why not? Why can’t I isolate some programs by having their PID numbers start over from 1 from their standpoint? Then they can’t attack other running programs because they can’t identify them because they run on a different PID numbering system where the rest of the system just doesn’t even exist. They can have their own private TCP/IP stack and 127.0.0.1 is now confined to their own little group. This confinement group could also be given its own computer name and it can be changed without affecting the real system. Oh, and we’ll re-label drive D and make it drive C within this group, meaning none of these programs can access the real drive C at all.
This is what a container does. The individual features of Linux that make these things possible (private networking, private system name, private process listing, etc) are intentionally leveraged to make a sort of “virtual machine” but it isn’t really. A “virtual machine” fakes hardware, up to and including the clock on the system, the hard drives, network cards and it usually has a `Press DEL to enter Setup` option like a real computer/server does. A “container” runs apps on the real machine in what is a completely normal way, but lies to them about what the world looks like as a means of isolating them instead.
They’re isolated in that they can’t interact outside the container, but the effect only works in one direction. The host can stick its nose in and affect the container. Furthermore any bugs in the operating system serious enough to crash the system would still allow the container to kill the entire system. Finally, for security reasons the container simply isn’t allowed to do certain things involving the hardware which would be allowed in a virtual machine. You can’t install device drivers, for example, and likely can’t access USB hardware without special dispensation from the administrator.
For me the big win is in memory usage for very small systems. With a virtual machine you assign a machine so much RAM – say, 1 gigabyte. It has that memory and it’s effectively taken away from the host. If you could manage with less, you’re wasting the difference. If you need more, it might require rebooting the virtual machine to increase the limit. Containers just laugh at that problem – change limits on the fly, and unused memory remains free for all.
Latest Answers