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.

Comments

Apple already uses that name..

[jcr]

"CoreOS" is the kernel and UNIX services layer of iOS and Mac OS X.

-jcr

Where Docker failed

[d3xt3r]

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.

Re:Where Docker failed

[steveha]

Disclaimer: I'm not super experienced in this stuff. I am open to correction if I have any of these points wrong.

Do we really need a full OS image running in a container?

I think we probably do.

One of the key selling points of Docker is that the container is load-and-go. Do you have some wacky old software that has a hard dependency on particular versions of some libraries? You can build a container with just the right libraries and get your software to work... and, after you do that work, the container is just another container. It may have been a pain for you to get it working, but then anyone can run it on any Docker host as easily as any other container. This seems kind of powerful to me.

Do you need to see how your software runs on CentOS and Debian? You can set up a container for each, and run the tests on a single host system.

And if you want maximum security, it's kind of neat that each docker container can use just its own private file system and containers can't affect each others' running state.

So, if you are content with running an up-to-date system, and always running the latest versions of everything, and upgrading everything together, you could make a security isolation system lighter weight than Docker, but trading off some of the simplicity and flexibility of Docker. You might think it's a good choice, but I don't think you can reasonably claim that it's better in all ways.

Containers should run a single process. We shouldn't look at containers as a more efficient VM.

As I understand it, it is considered best practice in Docker to run a single process per container. Some people do use Docker as a sort of lightweight VM but not everyone likes it.

Are you arguing that Docker is flawed because it doesn't enforce one process per container? Because I'm not seeing it. I would rather have the flexibility; if I want to use Docker as a lightweight VM, the option is there, and I don't see that as a bad thing.

Do you really want to have to run apt-get or yum inside every container?

Please correct me if I'm wrong, but my understanding is that you don't have to run a package manager inside every container. You would have a "base system" image, and you would update that image from time to time; then you build your specific containers as layers on top of the base image.

I believe a container could simply be a script that starts up a service, and config files that configure the service, with the actual packages for the service in the "base system" image. I'm not sure if that is standard practice or what.

I'm hoping that with Docker I could make micro-servers, like a Docker container with just a web server in it, not even a Bash shell. If someone cracks my server I want him in a desert, with no tools to help him escalate his privileges. I'm not sure how feasible that is now, but I think Docker is at least headed in that direction.

I'm not opposed to this new Rocket thing, but I'm still not clear on its actual advantages over Docker.

Re:Where Docker failed

[vux984]

Do you have some wacky old software that has a hard dependency on particular versions of some libraries? You can build a container with just the right libraries and get your software to work... and, after you do that work, the container is just another container.

On the flipside, the security of that container has to be managed separately. The operating system and libraries have to be managed separately. Yes, you get the advantages you state... but if the software isn't "wacky old software with wierd dependencies" then its a lot of overhead to setup and maintain.

A more lightweight approach to the common case makes sense, and you can always fall back to a full VM for the wacky ones.

Re:You are not Dockers business case

[DUdsen]

Dockers problem along with most of the web2.0 stuff is that it might look easy now but how are you going to ensure that everything is kept patched. When the installation/development team have fled the building and handed the task of running it over to some "outsourced operations center".

This is the question that never gets asked and why a lot of this new fancy smart stuff isn't that widely deployed by largish shops whose core business is something other then it and where a 5 year life cycle is considered short and agile.

Forking a filesystem is smart but remember your also forking and freezing yourself into all of the undiscovered bugs so you need a way to resync and retest every docker container ever deployed for every update in the platform you based it on. and this is something i haven't really seen anyone cover in dept yet.

Re:You are not Dockers business case

[Anonymous Coward]

He said vserver for over 10 yrs, NOT lxc.

Believe it or not, linux has had OOT container technology for ages, in the form of vserver and openVZ. We also have used vserver for at least the last decade at my work.

I was most surprised about the "using lxc in production" bit. We keep looking at it, but lxc still does not offer the isolation or stability to use in production (we had unpriv lxc containers working, then they were not). Semi-priv haven't been broken in quite a while though. Still not convinced lxc is really safe yet, even with uidmaps, since the main backers of lxc, Cannonical, always run app armor on top of it.

We also haven't found a use-case here where the Docker layer provides benefit. And anything with an ugly xml config file needs to be _very useful_ to be bothered with.