It points out, in the typical form of humor, that we're going to take a N wheels (the container spec in this case), try and shove them together, to get N+1 wheels. And this is relevant in a space with at least 4 competing standards (and one dominant one).
In the short term, what Docker uses with will matter more than the output of any such committee. In the long term, well, it depends on Docker-the-company's fate.
Many container services currently support starting Docker images, and with all of the money spent on marketing, Docker also owns the container ecosystem mindshare. It's their game to lose.
Aside from Docker containers (which are broadly consumed by competing container engines), rkt containers, the systemd "Container Interface" specification, and the LXC containers, you're right. There's no standard.
A per-container configuration file, stored in the container directory. Similar to the "tarball with metadata" of Docker, but you'll have to roll your own layers (or do it the old fashioned way & hardlink common files between containers).
Systemd:
You're right on the container interface front, my apologies. However:
specifies an image format (basically a bootable ISO or some such). It's not as self-contained as a docker image (still need to specify a bunch of parameters), but it's available.
systemd itself has its own system container tool called nspawn, though again like LXC it doesn't have any image format, serialization or anything of the sort. rkt originally used nspawn as its backend (still has it in, I think).
That's just wrong. Please have a look at the LXC or Systemd nspawn websites [1] or our guide to container technology [2]
LXC is not 'low level' capabilities as Docker erroneously refers to it on its website or a 'low level api'. [3]
The LXC project in development since 2009 on which Docker was based, and now Systemd-nspawn give you pretty advanced OS containers with mature management tools, full stack linux networking, multiple storage options including support for btrfs, zfs, LVM, Overlayfs, cloning, snapshotting and a wide choice of container OS templates.
It also offers unprivileged containers that let's non root users run containers, which is a big step forward for container security, and is currently working on live migration of containers.
Docker takes that as a base, limits the container OS template to a single app, builds the containers with layers of aufs and enforces storage separation. [4] It's not rocket science, you can do this yourself with overlayfs and LXC in minutes. [5]
Docker is an opinionated way to use containers. You don't need to adopt Docker to get the benefits of containers. You adopt Docker to get the benefits of Docker. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion.
Nspawn is a systemd container project, which is similar to LXC in that it gives you OS containers, not layered single app containers. Rkt is based on Nspawn if I am not mistaken.
It's curious that LXC project largely responsible for the development of most of the container technology available today is not part of this. I feel most folks who can move beyond the wild misconceptions floating around to try LXC will find it's significantly simpler to use.
We provide a lightweight VM image with a complete LXC environment based on Alpine Linux for those who are interested. It's 80 MB and available for Virtualbox, VMWare and KVM at https://www.flockport.com/flockbox
Disclosure I run flockport.com which provides an app store for servers based on LXC.
It seems you're referring to LXD+LXC as just LXC. That's fine, but I was referring specifically to LXC itself, which is considered low-level (even by their creators).
As for nspawnd, it's certainly a good tool, but as far as I know it doesn't define a container format, which is what we were discussing.
No, I was referring to LXC. Did you have look at the links to the LXC website and the container overview? There are plenty of 2 minute screencasts there that show LXC in action.
The LXC project does not refer to itself as low level, but ironically Docker which knows exactly what LXC is, does. And the results are these needless misconceptions, which is a tad unfair to the developers of the LXC project. Why would anyone try LXC if they think its 'low level'?
LXD extends LXC to add a REST api, multi-host container management and soon live migration.
LXC is a full fledged userland project and has been since 2009 when it began development. It is also responsible for driving the development of a lot of the kernel capabilities mainly 'cgroups' and 'namespaces' needed to support containers.
That's the 'low level' capabilities that LXC, Docker. Nspawn use to give you containers, but it would be as inaccurate to refer to Docker as 'low level' because it uses these, as it would LXC.
A container is simply a file system in a folder that gets booted and works on any underlying Linux filesystem so I am not sure about how conceptually a 'container format' fits there? That's one of the great things about containers. You do not need to think about storage. Simply zip the container folder and move across servers. Containers are completely portable across any Linux system today. But if you are going to use aufs or overlayfs layers to build single apps containers with constrained container OS templates then perhaps there is a need for a format.
When I said they referred to it as low-level, I wasn't just making shit up. From Stéphane Graber's (LXC lead) blog:
"Instead, LXD is our opportunity to start fresh. We’re keeping LXC as the great low level container manager that it is. And build LXD on top of it, using LXC’s API to do all the low level work. That achieves the best of both worlds, we keep our low level container manager with its API and bindings but skip using its tools and templates, instead replacing those by the new experience that LXD provides."
> A container is simply a file system in a folder that gets booted and works on any underlying Linux filesystem so I am not sure about how conceptually a 'container format' fits there?
Well, then maybe you should read TFA? It's all about the creation of a standard 'container format'.
Hi, I think we are playing with words and context here so I will leave it here.
The quote is in a context and says LXD uses LXCs low level api. It does not say 'LXC is a low level api'.
How does one conclude that from the quote and take it out of context without misleading readers? Any one with a remote awareness of LXC will know that's erroneous. Do you still think your comment was accurate?
Have you used LXC, are you familiar with LXC beyond the quote, are you interested in having an informed discussion on LXC and containers? There has be a basis for informed discussion.
I don't know how else I can read "We’re keeping LXC as the great low level container manager that it is" as anything other than LXC being a low-level tool.
No, from what I can tell, it's actually to launch systemd itself inside a container. For example, from the document:
To allow systemd (and other code) to identify that it is executed within a container, please set the $container= environment variable for PID 1 in the container to a short lowercase string identifying your implementation. With this in place the ConditionVirtualization= setting in unit files will work properly. Example: "container=lxc-libvirt"
