[tobbyb]

OpenVZ or LXC give you OS containers like KVM or VMWare gives your Virtual machines. Unlike OpenVZ, LXC does not need a custom kernel, and is supported in the mainline Linux kernel paving the way for widespread adoption.

Docker took the LXC OS container template as a base, modified the container OS init to run a single app, builds the OS file system with layers of aufs, overlayfs, and disables storage persistence. And this is the app container.

This is an opinionated use case of containers that adds significant complexity, more a way to deploy app instances in a PAAS centric scenario.

A lot of confusion around containers is because of the absence of informed discussion on the merits or demerits of this approach and the understanding that you have easy to use OS containers like LXC that are perfectly usable by end users like VMs are, and then app containers that are doing a few more things on top of this.

You don't need to adopt Docker to get the benefits of containers, you adopt Docker to get the benefits of docker and often this distinction is not made.

A lot of users whose first introduction to containers is Docker tend to conflate Docker to containers, and thanks to some 'inaccurate' messaging from the Docker ecosystem think LXC is 'low level' or 'difficult' to use, Why would anyone try LXC if they think it's low level or difficult to use? But those who do will be pleasantly surprised how simple and straightforward it is.

For those who want to understand containers, without too much fuss, we have tried to provide a short overview in a single page in the link below.

https://www.flockport.com/containers-minus-the-hype

Disclosure - I run flockport.com that provides an app store based on LXC containers and tons of tutorials and guides on containers, that can hopefully promote more informed discussion.

[GeertJohan]

Docker does not use LXC as default execution environment anymore. They created their own, called libcontainer¹. But with the new opencontainers movement, the package has been moved to runc².

[1] https://github.com/docker/libcontainer

[2] https://github.com/opencontainers/runc

[tobbyb]

That's why I used the word took, Docker used LXC as a base till version 0.9, untill it got enough traction, at which point it basically recreated LXC with libcontainer.

But that was not the point. The point is you have always had perfectly usable end user containers from the LXC project even before Docker. Then a VC funded company Docker bases itself on LXC and markets itself aggressively and suddenly a lot of users think LXC is 'low level' or 'difficult to use'? This messaging is coming from the Docker ecosystem and the result is the user confusion we see on most container threads here.

Informed discussion means people know what OS containers are, what value they deliver, and what Docker adds on top of OS containers so there is less confusion and FUD, and users can make informed decisions without a monoculture being pushed by aggressive marketing.

But that discussion cannot happen if you are in a hurry to 'own' the container story and cannot acknowledge clearly alternatives exists and what value you are adding exactly on top. I see people struggling with single app containers, layers and lack of storage persistence when they are simply looking to run a container as a lightweight VM.

The 'open container movement' is yet one more attempt to 'own' the container technology and perpetuate the conflation of Docker to containers. How can a 'open container movement' exclude the LXC project that is responsible for the development of much of the container technology available today. It should ideally be called 'Open App Container' because there is a huge difference between app containers and OS containers. OS containers provide capabilities and deployment flexibility that app containers simply cannot give because they are a restrictive use case of OS containers. Containers technology as a whole cannot be reduced to a single PAAS centric use case.