Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Cloud Open Source Programming Linux

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

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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward on Monday June 22, 2015 @02:03PM (#49963595)

    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.

  • 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?
    • by hummassa ( 157160 ) on Monday June 22, 2015 @03:34PM (#49964405) Homepage Journal
      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).
      • 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) wi

      • > 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 se

  • by Anonymous Coward

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

    You'll know because this is the logo: OCP [photobucket.com]

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

  • I miss the Dockers with the almost hidden zipper on the leg to hide your phone in.

    I really don't see what this has to do with Open Source though.

    • Re: (Score:3, Funny)

      by lhowaf ( 3348065 )
      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.
      • 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.

  • by allquixotic ( 1659805 ) on Monday June 22, 2015 @03:39PM (#49964451)

    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.

    • 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 [freebsd.org] would appeal to you.

      • 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 othe

  • by 0100010001010011 ( 652467 ) on Monday June 22, 2015 @05:12PM (#49965097)

    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.

    • It runs on Linux.

      • 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.

        • by lgw ( 121541 )

          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,

          • Re: (Score:2, Interesting)

            by rycamor ( 194164 )

            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 sou

            • 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.

              • by rycamor ( 194164 )

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

                • 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 pref

                  • by rycamor ( 194164 )

                    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, someti

            • by lgw ( 121541 )

              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.

              • by rycamor ( 194164 )

                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

The optimum committee has no members. -- Norman Augustine

Working...