Fabian Deutsch: Power of <stroke>love</stroke> 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.

Warkworth Castle<script async=”async” charset=”utf-8″ src=”https://embedr.flickr.com/assets/client-code.js”></script>

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).

Source From: fedoraplanet.org.
Original article title: Fabian Deutsch: Power of <stroke>love</stroke> containers – by acknowledging and respecting their boundaries.
This full article can be read at: Fabian Deutsch: Power of <stroke>love</stroke> containers – by acknowledging and respecting their boundaries.


Random Article You May Like

Leave a Reply

Your email address will not be published. Required fields are marked *