Power of love containers - by acknowledging and respecting their boundaries

So - It’s about guarantees. In this post at least. Containers are so useful - in some cases - because of a few reasons. One reason tho is that containers are pretty much “independent” of the host and the host operating system. And making them indepent of the host - or - abstracting away to host solves a class of problems.

{width=”640” height=”426”}

The author of an application does not need to take care that the OS and it’s devices come up correctly. Containers allow us to just assume that they will. An author does not even need to care about the real devices. An application needs a network? In containers you can work with that assumption. In the past time and code lines was spent on just checking that networking was availableDocker guarantees this. And even the NIC name.

An obviously docker goes beyond NICs. They found a great set of primitives and guarantees which they provide on any host to the container. Well - It only works because the distributions moved a little to provide all Kernel features which docker requires - but in the end it effectively means that the docker runtime (and OCI) guarantee you the same environment regardless of the host. And this simplifies things. Things? Yes. It simplifies code, because you can work with assumptions, it also simplifies updates, because you are isolated. And there are probably many more benefits.

Thus to me the best way to benefit from containers is to respect them and their boundaries. Boundaries in two ways actually: On the one hand that the container can expect that the boundary is always the same, and on the other hand that the container is not crossing the boundary (and thus avoids touching anything outside of it’s bnoundaries, like i.e. the host).

For sure there are exceptions where containers need to cross the boundary, i.e. in KubeVirt, where access to /dev/kvm is needed. But each of those escapes can lead to potential other problems. Search path and tool availability differences between container and the outer world, authentication issues because of different UIDs/GIDs in an outside of the container, security issues if stuff is copied outside of the container into external places, and so on and so forth.

Why am I iterating over this? Well, even if there are ways in the container world which allow us to break out, then we should still be very careful with using them. We loose the benefits of portability and isolation the more we open up the boundaries.

For KubeVirt - for example - we know that we need to cross the boundaries in some cases, i.e. to access /dev/kvm - but OTOH we try to not cross them, by not relying on software (i.e. libvirtd) or other devices (like disks) on the host. We rather aim at meeting these requirements in container or Kuebrnetes native ways (containerized libvirtd and persistent volumes in this example).

::: {#footer} [ February 27th, 2017 11:13am ]{#timestamp} [containers]{.tag} [kubevirt]{.tag} [kubernetes]{.tag} [docker]{.tag} [oci]{.tag} [libvirtd]{.tag} [fedora]{.tag} :::