libcontainer

Has libcontainer[1] been considered as a minimal Docker alternative? [1] https://github.com/docker/libcontainer

> Docker is built on LXC, Linux containers Nope, it currently defaults to libcontainer[1], not LXC, but through the use of execution drivers[2] you can still use LXC if you want to. [1]: https://github.com/docker/libcontainer [2]: http://blog.docker.com/2014/03/docker-0-9-introducing-execut...

Well, LXD doesn't actually exist yet, so Docker couldn't possibly be built on it. You are likely confusing LXD with the present day LXC, which is understandable. You thinking that Docker is built on LXC is also understandable - but also not quite right. Docker used LXC as the default container implementation for much of it's lifespan. However, it has since dropped LXC as the default and uses libcontainer instead. The linux kernel does not actually specifically have a container implementation. Userland tools such as LXC ( https://linuxcontainers.org/ ) and libcontainer ( https://github.com/docker/libcontainer ) utilize things like kernel namespaces, cgroups, and a variety of other features to deliver the container experience.

I agree that Docker is easier to deploy than Openstack :) However... It always astounds me how some people massively over-estimate the size and influence of Docker's marketing... Why yes, of course! The way we got Google, Microsoft, Amazon and IBM to integrate it in their products is by ghost-writing PR fluff. That's also how we got 600 people to contribute 9,000+ pull requests over 18 months [1] [2] [3]. Not bad for marketing monkeys! Seriously - after seeing so many hackers work so hard to improve the project every day, the "it's all marketing fluff" crap always gets to me. It's just plain disrespectful. How much legitimate engineering work do you need to see before you start respecting other people's work? [1] https://github.com/docker/docker/pulse/monthly [2] https://github.com/docker/libcontainer/pulse/monthly [3] https://github.com/

Docker doesn't use lxc by default anymore (although you can still run the docker daemon with it if you want). It uses libcontainer, which they wrote: https://github.com/docker/libcontainer

> Docker is really just an extra layer over LXC This is not correct. The Docker engine has an ability to use LXC userland tools as an execution environment, but it is not the primary choice. libcontainer (github.com/docker/libcontainer) is. libcontainer has adoption outside of the Docker world (Parallels, CloudFoundry, as examples) which we find to be a fundamentally good thing. We can also spend time talking about the non-technical values of Docker, if you'd like to jump in to that.

Sounds like a perfect use case for libcontainer https://github.com/docker/libcontainer Platforms like Sandstorm are exactly the reason why we opened up libcontainer: so that others can benefit from the firehose of engineering that goes into Docker, without having to buy into the entire platform. Once the C implementation is complete it should be even easier to use libcontainer in other languages. That said, I think some of the new Docker APIs we are working on would be a good match for Sandstorm as well. But thanks to the beauty of small, loosely coupled components, we can have that conversation some other time :)

This is coming to Docker. libcontainer is getting support for user namespaces[1] and the Docker engine will have a static configurable root map once the changes land. [1] https://github.com/docker/libcontainer/pull/23