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.
It is not about scope, or features, or development. It is all about who has the most things to install. Unless it runs Docker apps, (Which will be hard if it does not keep up with the feature creep) it is already starting way behind.
"CoreOS" is the kernel and UNIX services layer of iOS and Mac OS X.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Oh, fuck. I'm going to in to work tomorrow, and our resident Ruby on Rails weeny will have a fat, stiff boner over this technology. He'll be ranting and raving about how amazing it is, even if he's never used it. The old FreeBSD and Solaris admins will scowl at this rube and how he's getting excited over technology they had available to them 15 to 20 years ago. The even older guys who worked on mainframes will chuckle, thinking back fondly to the days when they first encountered this type of technology, so many decades ago. Six months from now, after the Ruby on Rails dickweed has convinced our manager to use this technology in production, I'll get a call in the middle of the night because it's all fucked up and broken. I'll have to waste my night fixing it, while our resident Ruby on Rails pecker is reading all about the next fad he'll use to fuck over the rest of us with.
So, Rocket for Android would be called Pocket Rocket?
Containers are an interesting beast. Solaris has had Zones (aka containers) since 2005. In Solaris, these Zones are more akin to virtual machines, except much more efficient. All zones shared a single kernel, they just had virtual network interfaces, storage, and could be managed independently. Now, in 2014, Docker brings the same simplicity of Solaris Zones to Linux.
Sure, we've had CGroups in Linux since 2004/2006 but Docker finally brought Linux up to speed with a simple to use capability for creating isolated containers on Linux. Only, the implementation brings with it the same flawed approach as Solaris Zones. Do we really need a full OS image running in a container? I don't think so. Docker images are based on a Linux distro (Ubuntu or CentOS, etc). So we look at this and say, "cool, virtualization without the overhead of interrupts for everything from writing to disk to sending packets over the wire." But is that really the best we can do?
I think what Rocket really represents is a way to do containers right. Containers should run a single process. We shouldn't look at containers as a more efficient VM. We should see containers as a way to increase security and reduce overhead. Do you really want to have to run apt-get or yum inside every container? No. Containers should provide process isolation and application management capabilities. They shouldn't include the OS and the kitchen sink of user land utilities.
This is where Docker has failed. Instead of simplifying administration and deployment, it's introduced its own nuanced approach to system management. The reason we need a Docker competitor (replacement?) is because Docker has failed to live up to its hype.
won't someone pretty please do the same with firefox... i want my bare no frills, speedy, addon friendly browser back. not a bloated chrome lookalike.
Just like Docker. Epic fail. Next!
Why is there an open box and a CD for the subject icon? Why not a 5 1/4" floppy?
It proposes an open standard for containers (among other things) and Docker containers can be imported/ported over with what appears to be minimal fuss. Source: I was at the CoreOS presentation in San Francisco this evening.
The Docker folks have been pushing the microservices model for containers for some time. I don't believe it to be particularly viable given the ecosystem tooling and level of experience with non-fat containers/VMs among Ops folks currently outside of those who have worked at a handful of companies like Google, Facebook, Twitter, etc. If Kubernetes matures and the Mesos folks continue to work with them that may go a long way except that Mesos has a repuation for being a real bear to stand-up. I've been finding CoreOS to be a nice compromise for someone coming from a background which does *not* involve vast experience with a cluster manager.
We need yet another incompatible re-implementation of a major subsystem to fragment and distract the user base because were such masochists and need 7+ different package managing systems, 10+ desktop window managers, 4 different audio stacks some piled onto the other, 2 different replacements for Xorg, and etc. Someone tries to fix that problem, but were too successful, so now we gotta have two different implementations of it because some competing corporation wants some street cred. But hey, at least we only have one dominate SSH server because borrowed that from OpenBSD and writing another SSH server is too boring for Mark Shuttleworth.
Just in case anybody wanted to pick political sides, CoreOS sponsored the development of networkd for systemd. So, the systemd perspective is the perspective that they're using when they criticize Docker for not being a tool that does one thing well.
They dumped Docker over feature creep when systemd is feature creep at every update? Talk about hypocrisy...
If you have been using LXC for over 10 years and have a custom application already tuned to it, you are not Docker's case, and that is fine. What Docker is about is being able to rapidly download and deploy entire enterprise stacks, with each piece of the stack being totally isolated and thus easily maintainable and upgradeable, making the whole thing easily automated. Want to swap from Postgresql 8 to Postgresql 9? Swap out the container that someone else has already made and tested... done. It is a very useful project.
They are expecting people to change the happy whale for just an ugly rocket. That's not the way the Go community rolls. Everybody knows that cute mascots are the most important part of a good software.
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.
I don't understand the need to inject all the platform bloat into Docker. Why not just fold docker functionality into an existing platform such as OpenStack to handle all those "extras" that are being contemplated? The work to integrate the two is already in progress:
https://wiki.openstack.org/wik...
Best,
I can't shake the feeling that I've seen this movie before, I think it was called "statically linked executables" where all the code needed to run the application resided in one place. Then as the executables got more complex they got much larger, consumed more resources, and large parts of each executable was redundant with each other. Hence static executables were superceded by "dynamically linked executables" which pulled out the redundancies into general purpose libraries that existed in only one place which led to dll version hell. So now we have containers which allows an application to be bundled up with just the code it needs to execute.
And yes, containers have more capabilities than simply isolating the code. However I would argue that code isolation is the primary use of containers.
I have a prediction, that by the end of 2015 we will see one of the container vendors offer a version that allows for "code sharing" between a master image and the individual containers in order to cut down on redundancy. Full Circle++.
Average Intelligence is a Scary Thing