Slashdot Mirror

← Back to Stories (view on slashdot.org)

CoreOS Announces Competitor To Docker

Posted by Soulskill on from the if-you-want-something-done-right dept.

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.

5 of 71 comments (clear)

  1. Fuck me. by Anonymous Coward · · Score: 5, Funny

    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.

  2. Where Docker failed by d3xt3r · · Score: 5, Interesting

    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.

    1. Re:Where Docker failed by steveha · · Score: 5, Interesting

      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.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  3. Re: It is not about scope... by Anonymous Coward · · Score: 5, Insightful

    As someone that has used Linux vserver for over 10 years and is currently running lxc containers for our business, I would say that Docker is a very confusing project to put into practice. We decided that we could do a better job and have more control over the deployment and operations of our applications.

    We evaluated coreos and decided against it because it used Docker.

    I think this is a good moved from coreos and makes complete sense if you had to use this stuff for anything in the real world.

  4. Re:You are not Dockers business case by DUdsen · · Score: 5, Interesting

    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.