An introduction to Clear Containers

Posted Jun 3, 2015 0:09 UTC (Wed) by ras (subscriber, #33059)
In reply to: An introduction to Clear Containers by Cyberax
Parent article: An introduction to Clear Containers

Once the container is running I have no doubt very little of the installed stuff is used. But that isn't because it isn't needed. It's for the same reason my employer hires me instead of just my hands - my hands need a support system.

The 140Mb [0] that debootstrap installs maintains the debian distribution that lives inside of the container. The way things are done now it's a necessary part of the container. Docker files generally start with "take one minimal debian installation; apt-get install these packages ...". That can't happen without that 140Mb. If you get your containers to install their own security patches, that 140Mb is going to be needed for the life of the container. Even if you don't Debian's policy of not having explicit dependencies on "required" packages means it's very difficult to figure out what you can remove without writing your own software to follow the reverse dependencies (which I have done).

Part of the reason I say the distro's have to change is I agree this stuff shouldn't be in the container. If the distro's become container aware, the host can use it's copy of dpkg and so on to build and later maintain containers. If that happens you get the added benefit of security patches being applied automagically by the host as happens now in the non-container world, rather than having to do this manual rebuilding rubbish.

This is where my statement above, that the next step in move to containers is the distro's change, comes from. At the moment what we have is 1/2 baked.

[0] It's only recently realised that Debian minimal install is 140Mb. That's huge - and it's after I've pruned the cache's debootstrap creates. Damn Small Linux for example crams an entire distribution (kernel, GUI environment, 2(!) x Browser, a plethora of editors) into 120Mb.

An introduction to Clear Containers

Posted Jun 3, 2015 0:34 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

If you are taking the approach that containers should be replaced instead of upgraded, you don't need all that infrastructure in the container because you aren't going to use it.

I think we differ mostly in that as far as you are concerned, fixing this is "the distros becoming container aware" while for me fixing it is "the container system becoming update/distro aware". The difference being which side is responsible for making the changes.

An introduction to Clear Containers

Posted Jun 3, 2015 2:56 UTC (Wed) by ras (subscriber, #33059) [Link]

> for me fixing it is "the container system becoming update/distro aware".

That gets hard, because your container now has know a lot about the packaging system the distro uses. In Debian this means it would have run dpkg itself, which is possible because dpkg does take a --root parameter. But that means the container would have to handle dependency resolution. All of which is possible of course, and if we were only talking about Debian probably even easy for some definition of easy. [0] But we are talking about tracking every packaging system out there - including things like pypi.

They are not going to do that. Their success so far has been built on them avoiding doing it. Instead the user writes a script, the script uses some magic to build an image. The container's role starts in earnest after the image is built - they can deploy them across server farms, start them, stop them and even provide tools like etcd so they can configure themselves. It all works because the icky details of how to build and extend an image are all held inside the image itself. In that 140MB. That's why it's never going away without something changing.

If you are going to get rid of that 140MB there is one place I am pretty sure it isn't going to migrate to - and that is into the container software - eg docker. Debian providing tools that manipulate packages inside of a container, and the user running those tools from the existing docker script sounds like a much saner route to me. Of course this means the docker script would only work when run in a Debian host. Which is how we get to containers being tied to a particular distribution - while the container software (eg Docker) remains distribution agnostic. In principle the built containers could be distribution agnostic, but since Debian built it, it's not difficult for the Debian host to figure out what containers are effected by a security patch and notify the container software to do something about it. And thus you get to the containers being distribution specific too.

So we get back to my original point. All the changes that must happen to make this work are in Debian, or whatever distro is being used. The container software just continues to do what it does now. Thus my conclusion that the next step in the evolution in containerisation must come from the distro's - not the container software.

[0] The recent discussion on the debian development lists over how poorly aptitude does dependency resolution compared to apt provides a hint. "Easy" here means it could be done by someone - but even software written by Debian itself has trouble getting it right.