
Containers as Kernel Objects – Again - Tomte
https://lwn.net/SubscriberLink/780364/51230bfb2f59ce05/
======
marios
Two sentences from the article struck me:

> Linus Torvalds once famously said that there is no design behind the Linux
> kernel.

Reminds of a talk/interview where Bryan Cantrill (of Solaris/Illumos/Joyent
fame) said: "You can't evolve your way to containers". Sure evolution is nice
and can lead to nice results, but I refuse to think that not designing things
is a good idea. From my (limited) experience, a properly designed system helps
you. When dealing with poor design, you have to fight whatever abstraction the
idea evolved to.

> One could perhaps make an argument that the lack of a proper container
> object was necessary in the early days, when the community was still trying
> to figure out how containers should work in general.

I don't think that's an argument, really. The phrasing suggests Linux
pioneered containers, which is simply untrue. Containers existed before, in
the form of FreeBSD jails and Solaris Zones. Linux suffers from sever NIH in
this case IMHO. Was the design of these other systems even considered ? Were
there limitations that made them impractical ?

~~~
jacques_chester
> _Containers existed before, in the form of FreeBSD jails and Solaris Zones._

Even earlier, depending on what variant of mainframe virtualisation you are
prepared to count.

> _Were there limitations that made them impractical ?_

Not being up close with LKML workings, I can only speculate that it's due to
Conway's Law. Having a kernel-level concept of "a container" requires changes
cutting across a number of subsystems worked on by very distinct groups of
people.

Cathedral-style development can achieve that kind of a change. The
organisation responsible for Solaris saw the vision, worked out what had to be
changed to create a uniform mechanism, then changed it. They achieved broadly
the same with ZFS.

That said, there is container-as-a-runtime, in which I think having a
consistent concept a la Zones has enormous value for consistency, security and
performance optimisation opportunities. But there's also container-as-
ecosystem. More accurately, _images_ are containers, worthy of that name,
because they created such a simple way to take advantage of complex low-level
APIs.

------
jopsen
The fact that containers are built from so many different technologies..
always make me uneasy about the security aspects...

------
InTheArena
This approach has been very successful to date. People forget but there was
actually quite a number of different rival container implementations. LXc and
let me contain that for you, for example. The lack of a single abstraction
made it possible for there to be rival implementations that each evolved
rapidly. Now that Docker has “won” it’s time to simplify by collapsing all of
the abstractions down to a single set of interfaces.

~~~
ithkuil
How different is the actual underlying container abstraction between all those
competing container "end-user experiences"?

~~~
RantyDave
For the most part, completely identical. They all work by squirting numbers
into cgroups.

The exception that proves the rule are the container runtimes that launch the
container in a VM.

------
denart2203
While I'm not excited by the idea of having a kernel-wide concept of
"container", I _do_ love the idea of being able to create a new detached
filesystem namespace, mount things into that namespace, and openat and fooat
in that namespace.

~~~
hacknat
It already exists in the form of user namespaces.

------
awilddocker
kinda sick of all this container nonsense tbh - they are so insecure, un-
engineered and propped up only by vc marketing dollars

kernel community is wise to reject this, seriously

~~~
cfcosta
Why? Containers are not insecure, some implementation of them have some
vulnerabilities. That doesn’t mean that namespaces are insecure, it doesn’t
mean that cgroups are insecure, and there is more than one container
implementation (such as podman and cri-o).

That sounds like a reductionist argument, unless you have some more concrete
issues than just “they are so insecure”. And having VC money is not a problem
per se.

------
tyingq
Isn't OpenVZ/Virtuozzo basically the same idea?

~~~
TheRealPomax
A lot of things are basically the same idea, but none of them are backed by
"this is the linux way".

~~~
tyingq
Well, both are containers shoehorned into the Linux kernel via a patchset. Are
there other examples of that?

Neither OpenVZ, or the idea posted is currently the Linux way.

------
gigatexal
Seems like a great way to get rootkits into the Linux kernel ...

~~~
dastx
How so?

~~~
gigatexal
How would you be able to root out these containers doing seemingly anything
sitting in kernelspace?

~~~
cpuguy83
The code wouldn't be running in kernel space, just the setup/configuration of
the environment, which really isn't any different than it is today, tbh. This
seems to be more about attaching a kernel auditable id to a container.

~~~
metabagel
It sounds like what you are talking about is already existing functionality,
not the proposed design.

~~~
simcop2387
The proposed design uses all the existing functionality and gives it a single
object in the kernel to control it rather than a dozen different ones. It's
not a fundamental change in design to how the containers themselves work.

~~~
gigatexal
Ahh, well I stand corrected.

