Slashdot Mirror
CoreOS Announces Competitor To Docker
New submitter fourbadgers writes: CoreOS, the start-up making the CoreOS Linux distribution, has announced Rocket, a container management system that's an alternative to Docker. CoreOS is derived from Chrome OS and has a focus on lightweight virtualization based on Linux containers. The project has been a long-time supporter of Docker, but saw the need for a simpler container system after what was seen as scope-creep in what Docker provides.
And IOS is the operating system powering Cisco routers.
http://en.wikipedia.org/wiki/C...
There is significant confusion about Linux containers. The Linux container project (LXC) has been baking since 2009, is perfectly usable and the extensive Linux toolset to support servers and clustered environments work with LXC perfectly.
There is little need to reinvent unless some value is being added but in many cases its just adding complexity to extract value by funded companies who muddy the waters relentlessly.
LXC is supported by Ubuntu since 2012 and mainly developed by Stephane Graber and Serge Hallyn of Ubuntu. LXC gives you Linux containers with a complete Linux environment, a wide choice of container OS templaes and advanced features like unprivilged containers that let's non root users run containers. Tools like Docker took this base LXC container, introduced a restrictive container OS environment to give you an app delivery platform with added complexity suitable for PAAS type scenarios, but promote themsevles as 'easier to use'. And in their marketing are vague on their genesis and their value add on top of LXC which would need them to be open about the extact nature of LXC, referring instead to the project as 'low level kernel capabilities' and allowing the misconception to spread that Docker is linux containers.
Because of the LXC project's low profile and marketing resources of funded companies a lot of folks first introduction to Linux containers is via tools like Docker, who do not know much about LXC beyond the misconceptions. And even stranger a lot of other funded projects spring up around tools like Docker that try to break though the self imposed restrictions of Docker containers to make them more like LXC!
The end result is unbecoming confusion even on better informed discussion forums like Slashdot, Soylent news, Hackner news and phoronix. So imagine the level of confusion with normal users? All Docker has to do now is lose the needless restrictions on their containers and LXC is basically dead. This looks like embrace, extend and extinguish.
Here is a timeline of LXC
2007 - Cgroups patches to the Linux kernel by a couple of Google coders
2009 - The LXC project by Daniel lezcano, Serge Hallyn supported by IBM with a kernel patch and userland tools to create and manage containers. The LXC code was merged into the kernel in 2.6.32 with userland tools available.
2012 - The project is now supported by Ubuntu with Stephane Graber and Serge Hallyn on Ubuntu working on it. It was a pretty low profile project.
2013 - LXC 1.0 stable is released with a lot of new and exciting features.
2013 - Dotcloud was using LXC containers for their internal PAAS platfrom, and experimented with LXC's support for overlay filesystems like aufs and overlayfs.
2013 - Based on this they released a tool called Docker. They manage to get a lot of funding and market themsevles aggressively to the devops community.
2014 - Docker sees huge adotpion and with the 0.9 release drop their dependence on the LXC project and annnounce a new tool called libcontainer that will use cgroup and namaspaces in the kernel directly.
2014 - Ubuntu finally wakes to the potential of their own supported LXC project and announces LXD which will use uinprivilreged containers by default and manage containers across LXC hosts
2014 - CoreOS, a linux distribution based around systemd and deploying apps in Docker containers with multi host orchestration tools like etcd and fleet decides to make a competing container format to Docker. Apprently because Docker was going to step in to the multi host orchestration business itself. Of course containers being like VMs don't need any specific container oriented orchestration, and tools that work with bare-metal and VMs work with LXC containers, but if you intentionally make restricted container formats then you will need to create an ecosystem of tools that support your restricted format. So you can't use normal orchestration tools as you would with LXC but need to find a Docker way or CoreOS way of doing things. That sounds fun.