Slashdot Mirror

← Back to Stories (view on slashdot.org)

Docker and CoreOS Join Together For Open Container Project At Linux Foundation

Posted by samzenpus on from the working-together dept.

darthcamaro writes: The great schism in the container world is now at an end. Today, Docker and CoreOS, announced along with Amazon Web Services, Apcera, Cisco, EMC, Fujitsu, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, the Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat and VMware the Open Container Project, as a Linux Foundation Collaborative Project. The new effort will focus specifically on libcontainer — providing a baseline for a container runtime. "By participating with Docker and all the other folks in the OCP, we're getting the best of all worlds," Alex Polvi, CEO of CoreOS told eWEEK. "We're getting the contributions from Docker with the format and runtime that underpin container usage, and then we're also getting the shared standard and vendor neutrality aspects that we've designed with app container."

25 of 48 comments (clear)

  1. I have 20 years of experience with containers by Anonymous Coward · · Score: 4, Funny

    and let me tell you that an open container is a bad idea. No one will want them because they'll collect rain which will ruin the merchandise inside.

    1. Re:I have 20 years of experience with containers by sconeu · · Score: 2

      The cops don't like it if you have an Open Container either... at least in CA.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  2. I feel like Rip van Winkle by museumpeace · · Score: 1, Informative

    I went to sleep when STDLIB and Posix would have done most of what I imagine containers will do. I wake up and Containers are here. Really, now; what is new here? VMness?

    --
    SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
    1. Re:I feel like Rip van Winkle by hummassa · · Score: 4, Informative

      I will assume your question is serious. Posix never isolated processes. One process can see other processes' files, ports, and even the processes themselves. That is what containers are about: your web browser cannot see your email client's files and vice-versa (so a vulnerability in one process cannot give you access to the content of the other).

      --
      It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
    2. Re:I feel like Rip van Winkle by firewrought · · Score: 2

      I'll extend your answer with the "big picture" view: Docker (and it's Google-backed competitor, Rocket) provide isolation that's stronger than the traditional process model but weaker (and less resource-intensive) than the VM model.

      It also introduces yet another packaging system (called "images") that has its own public repository of contributions that you (and any other malware author) can contribute to. For developers, the appeal is being able to bundle up an OS (sans kernel, operationally speaking) with their app and all of its dependencies into one file they push back up to this public repository (or a private one like Quay.io) without having to document an installation procedure for sys-admins. For sys-admins, the pipe dream is to push workloads around to whatever machines have the capacity without delving into the mess of individual apps. Of course, this requires a whole extra layer of additional tooling that doesn't come for free. :O

      All that said... don't use it for security. It's not the same as a dedicated VM.

      --
      -1, Too Many Layers Of Abstraction
    3. Re:I feel like Rip van Winkle by kosmosik · · Score: 2

      > so a vulnerability in one process cannot give you access to the content of the other

      Unless it is a kernel vulnerability in LXC that allows you to escape the container.

      But you are right about POSIX.

      IMO containers are not about security - if you wanted security you would go with designs that were built with it in mind from hardware to software.

      Containers and microservice architecture allow faster and better managed deployments of services in large distributed scale (aka the cloud) and this is the main selling point.

  3. It's a trap. (Not ackbar!) by Anonymous Coward · · Score: 1

    They're only doing this to pin down the trademark for OCP so they can build military robots. Ronny Cox is displeased with you. Now you die.

    You'll know because this is the logo: OCP

    (Let's see if this is anywhere near the first post to make references to RoboCop. My money is on "no".)

  4. Re:Nothing says open source like stylish pants by lhowaf · · Score: 3, Funny

    Dockers (the pants) must be designed and made by women. Angry women. Maybe nuns. The zippers are way too short to be useful to anybody who owns a penis.

  5. Containers can be VMs *or* apps, Docker. by allquixotic · · Score: 5, Interesting

    Unless this unified "Open Container Project" supports both the unprivileged, isolated "machine" concept of a container AND the trusted, shared "app" concept of a container, it's going nowhere fast for me.

    Solaris Zones. linux-vserver containers. Now Canonical's lxd. Few of the participants in the container effort, except these three, seem to understand the value of having containers as *machines*. Give each machine its own static IP, isolate all its resources (memory, processes, users and groups, files, networking, etc.) from the other containers on the system, and you have what's basically a traditional VM (in the early 2000s sense of the word), but with a lot less overhead, because no hypervisor and only one centralized kernel.

    Docker seems to pretend like VM-style containers don't (or shouldn't) exist. I disagree fundamentally with that. I dislike that Docker pushes containers so hard while ignoring this very important use case. I hope the rest of the Linux Foundation is smart enough to recognize the value of this use case and support it.

    If not, I'll just have to hope that Canonical's lxd continues to mature and improve.

    1. Re:Containers can be VMs *or* apps, Docker. by EmeraldBot · · Score: 1

      Unless this unified "Open Container Project" supports both the unprivileged, isolated "machine" concept of a container AND the trusted, shared "app" concept of a container, it's going nowhere fast for me.

      Solaris Zones. linux-vserver containers. Now Canonical's lxd. Few of the participants in the container effort, except these three, seem to understand the value of having containers as *machines*. Give each machine its own static IP, isolate all its resources (memory, processes, users and groups, files, networking, etc.) from the other containers on the system, and you have what's basically a traditional VM (in the early 2000s sense of the word), but with a lot less overhead, because no hypervisor and only one centralized kernel.

      Docker seems to pretend like VM-style containers don't (or shouldn't) exist. I disagree fundamentally with that. I dislike that Docker pushes containers so hard while ignoring this very important use case. I hope the rest of the Linux Foundation is smart enough to recognize the value of this use case and support it.

      If not, I'll just have to hope that Canonical's lxd continues to mature and improve.

      I think FreeBSD's Jails would appeal to you.

      --
      "Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
    2. Re:Containers can be VMs *or* apps, Docker. by allquixotic · · Score: 1

      They seem viable enough; all the prerequisite container isolation concepts seem to be implemented, though I'm not sure if there are any hidden "gotchas" where certain resources would not be isolated. I'd have to investigate more.

      Then I'd have to learn all the different system administration concepts and commands for using an entirely new OS that I've never used before. I've used Solaris (and variants), about 9 Linux distros, Windows, and Mac, so maybe I'm more qualified as a "new platform learner" than others, but it's still not really something I wanna do.

      Especially considering there are about a dozen different, extremely complicated software products that I want to run on this system, in the containers (not in hypervised VMs), which are either binary-only Linux/ELF executables, or source code that's so resistant to running on non-Linux that it's ridiculous (spent the better part of a week trying to compile one of these programs for SmartOS).

      So yeah, not really going down that rabbit hole, sorry.

    3. Re:Containers can be VMs *or* apps, Docker. by allquixotic · · Score: 1

      I'm well-aware of the advantages of SmartOS, actually. I am in the process, however, of migrating my dedicated server from one system to another (I'm upgrading the hardware, while staying with the same hosting provider). In doing so, I've made the difficult decision to move *away* from SmartOS, and back to GNU/Linux, for the following reasons:

      (1) Despite promises to the contrary, compiling most C/C++ FOSS is *not* easy on SmartOS. Also despite promises to the contrary, a vast amount of FOSS that I need is *not* available in SmartOS's repositories, nor in any SmartOS equivalent of Ubuntu PPAs. 99% of projects need extensive source-level patching, awful environment variable hacks, symlinked binaries, edited configure scripts, or some nasty combination of the above. Some extremely complicated projects like PhantomJS are nearly impossible to compile on a system that is not the Linux kernel, with glibc as the C library, libstdc++ as the C++ library, and gcc 4.x as the compiler. I cannot use any alternative programs for some of these use cases, though, and PhantomJS isn't the only one -- I simply don't have the time or willpower to spend weeks fighting horrendous build environments that are opaque to diagnosis to do something that I could accomplish with "aptitude install phantomjs" on Debian or Ubuntu or Devuan or Mint or... you get the point.

      (2) Although the kernel and core system was sound, I experienced inexplicable random crashes of a 4 GiB kvm guest running Windows Server 2012 on SmartOS. I tried fixing this numerous ways by updating the host OS, updating kvm, looking at logs, reducing the amount of RAM assigned to it, etc. -- but after about 24 hours of uptime, the VM just crashes (on the host side). I don't experience this with KVM on the Linux kernel. And for various reasons I can't *not* have a Windows VM for certain limited use cases on my server. It's a multipurpose box and it needs to be able to do a lot of different things. I don't have the money to buy a dozen different boxes each filling its own little niche.

      (3) To run the aforementioned programs that are infinitely resistant to compiling cleanly on SmartOS, I ended up firing up a paravirtualized Linux kernel (CentOS 7) on top of SmartOS. This ran well enough, but it just felt *unclean* to need to run a UNIX on top of a UNIX, when all I'm doing is running FOSS programs. Although there is that one program that's binary-only which absolutely *does* require Linux...

      (4) I tried messing with lx branded zones, but could never get it to actually do anything useful except print error messages. I of course googled those error messages, asked about them in IRC, and the like; but the most I could get was someone saying "Huh... that's strange." No offered solution. lx branded zones have a lot of promise if they can emulate an actually modern GNU/Linux distro such as CentOS 7 or Ubuntu 14.04.2 or Debian Jessie, but until/unless they can do that, with few or no gotchas, I really can't be bothered to mess with them in an alpha/experimental state.

      (5) lxd to the rescue! Canonical (officially the "Linux Containers project") is working on a daemon called lxd ("lex-dee") which brings sanity and proper isolation (through use of already-existing kernel resources) to the lxc project. The `lxc` command that comes with `lxd` operates very similarly to `vmadm` in SmartOS, and the guarantees that you expect for isolation in SmartOS are pretty much true in lxd guests as well. At their core they just use mainline Linux kernel features; the difference is that lxd actually uses these facilities *in a smart way* to isolate guests. Docker on the other hand, encourages the guests to be friends with one another. Yuck.

      So:

      - I had problems with SmartOS in actually using it, despite a promising and rock-solid stable base system. It needs a lot (and I mean a LOT) of work for compatibility with existing FOSS and/or better support for lx zones based on modern (recently-released) Linux distros.

      - I still have ZFS on Linux and it works gre

  6. Different from Jails? by 0100010001010011 · · Score: 3, Interesting

    Can someone break it down how this is different from Jails? I have almost a dozen different jails on my FreeNAS machine serving everything from nginx to iPython.

    1. Re:Different from Jails? by kosmosik · · Score: 1

      It runs on Linux.

    2. Re:Different from Jails? by 0100010001010011 · · Score: 1

      Eh. Any other actual reason it's better/newer?

      I think I'm just going to stick with FreeBSD until they move to systemd and then checkout Hurd.

    3. Re:Different from Jails? by lgw · · Score: 2

      It's designed to solve a deployment problem, not a security problem. People really like VMs for managing deployments - everything together in one image, no conflicts to resolve, very easy. Images can be shared internally or in an open-source way. Docker gives you that with far less overhead, so if you have a lot of very small "servers", you can cram them together in a VM (just like with jails), but without the security of VMs or jails.

      For a single server, jails just seem better, but for managing a fleet, especially in the cloud, Docker has the infrastructure built.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re:Different from Jails? by rycamor · · Score: 1, Interesting

      So what we have is an insanely more complicated way to manage your "VM-ish" things, a really, really odd way of approaching your containerized system where it doesn't actually get to have a full userland (no SSHd, etc...) unless you do all sorts of insane tweaks (believe me, I know because I spent the better part of last year doing this), and in the end the only real advantage of Docker over jails has nothing to do with the intrinsic design of the system, but the build infrastructure surrounding it?

      That sound about right. All FreeBSD needs to compete with Linux containers is an image repository and a Git-like method for managing and building images. There are already tons of jail management tools for snapshotting, migrating, moving, templating, etc... And given that jails have a much longer history and are likely to be much more stable and easy to manage, it seems like a natural next step, BSD guys. Hint, hint...

    5. Re:Different from Jails? by 0100010001010011 · · Score: 1

      Git-like method for managing and building images.

      No reason to make it 'like'. Just use Git and commit hooks.

      Some sort of yaml file to describe the Jail with mountpoints. A 'filesystem' folder with any config file changes.

      Add something like gitolite to the base file system and you have everything you need to manage a 'fleet' of jails from the command line and git.

    6. Re:Different from Jails? by rycamor · · Score: 1

      Sounds like a thing that needs doing. Where do we start?

    7. Re:Different from Jails? by 0100010001010011 · · Score: 1

      Talk about high level requirements?

      Lets use an already existing jail manager:

      Then it's just a matter of figuring out a setup config that is both extensible but KISS.


      $ cat repo/config.yml
      jail: myawesomejail
      packages:
          - nginx
          - nmap
          - mysql-server
          - python3.4

      Then maybe a 'faux filesystem' of stuff to copy.

      $ cat repo/usr/local/etc/nginx.conf
      # My super special nginx config

      Then some sort git hooks/scripts and config parser for git. I prefer python but just because I'm learning it. But if it was done it tcsh or sh it would work 'out of the box' on a bare bones FreeBSD.

      Then figure out a way build a nanobsd build that you could install to a flash drive that would contain a bare bones FreeBSD install to act as 'dom0' and some way to point it to some ZFS pools.

      All managed through Git/Gitolite.

      Then all of your config files are versioned and you have to commit and push them to be active. Need a way to start/stop.

      Anything I'm leaving out? I don't do this for a living, I just want something stupid easy to make new jails.

    8. Re:Different from Jails? by rycamor · · Score: 1

      Yes, that's a good start, but remember that Docker also has a... social landscape I guess we could call it. There's a central website and blog, and then there's the all-important Docker Registry where you can search for existing images, and build your own images on top of base images you download. And Docker has a built-in feature to fetch images right from the registry. Makes it very easy to experiment and toy around with images.

      Docker made these seemingly superficial things priorities from day one, sometimes at the expense of good architecture and security. For example, earlier versions (as of 1.2 AFAIR) did not have an easy way to delete built-up cruft from images you had imported.

      So the challenge would be to accomplish these benefits without some of the huge gaping security/stability/malware holes that Docker has had to deal with.

    9. Re:Different from Jails? by lgw · · Score: 1

      So what we have is an insanely more complicated way to manage your "VM-ish" things

      Complicated how? It's the simplest way to manage lightweight containers at scale. It's not about what happens on any one machine (that's a well-solved problem), it's about fleet management in a way that decouples the hardware from the needs or the software, without the overhead of a full OS per container. I don't think it adds much value at the scale of a few machines, maybe not even at a few dozen machines.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    10. Re:Different from Jails? by rycamor · · Score: 2

      I mean insanely more complicated than jails, not insanely more complicated than other standard VMs. Have you used jails? I was on a project to deploy Docker instances on a large scale, and it took me 6 months to create an infrastructure that could have been done in 1 month with jails. I will agree that Docker has some nice abstractions, but the details and special cases and workarounds were endless. And I still don't see the actual advantages over FreeBSD. There's simply nothing stopping one from creating a few shell scripts to spin up thousands of BSD jails, mapping drive storage and networking however you want. A lot of this stuff the Linux guys are thumping their chests over now was in mass deployment over a decade ago in certain BSD hosting companies.

  7. Re:Nothing says open source like stylish pants by rahvin112 · · Score: 1

    That would only be true if you wear your pants around your nipples. Either that your have such a small penis that you can't get it out without your pants around your ankles.

  8. Re:With that lot, let call it... by the_B0fh · · Score: 1

    Are you not aware that he actually called for something similar?