Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Open Container Project and What It Means

Posted by samzenpus on from the breaking-it-down dept.

An anonymous reader writes: Monday saw the announcement of the Open Container Project in San Francisco. It is a Linux Foundation project that will hold the specification and basic run-time software for using software containers. The list of folks signing up to support the effort contains the usual suspects, and this too is a good thing: Amazon Web Services, Apcera, Cisco, CoreOS, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, the Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware. In this article Stephen R. Walli takes a look at what the project means for open source.

14 of 54 comments (clear)

  1. Apparently it mean you can get arrested by Chris+Mattern · · Score: 4, Funny

    At least in a lot of places: https://en.wikipedia.org/wiki/...

    1. Re:Apparently it mean you can get arrested by PopeRatzo · · Score: 2

      Better wait until you get home to open that beer here in Alabama!

      This 1979 conversion van IS my home, you insensitive bastard!

      --
      You are welcome on my lawn.
    2. Re:Apparently it mean you can get arrested by mrchaotica · · Score: 3, Funny

      They had a perfect opportunity to use a bottle inside a paper bag as their project logo, but no, they had to use a stupid yellow square instead!

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

  2. Re:It means... by Anonymous Coward · · Score: 5, Insightful

    Sadly, in this case, you're pretty much right on. Docker, et al., really prove the old canard that "any problem in software can be solved with another layer of abstraction."

    The chroot jails have been around forever and IBM's been doing more robust forms of containers/virtualization for decades. The current crop of containers chose to ignore all the past work and no one called them on it (well, actually, a lot of people did, but in true hipster fashion, the feedback was ignored because this time, you know, it's different).

    But, that ignores the problem that modern containers really exist to solve dependency hell (remember that thing we used to always mock Windows for? Yeah, Karma's a bitch). It's difficult to manage many applications that all rely on slightly different versions of libraries. So, let's just containerize/virtualize everything and pretend there's not a more fundamental underlying problem.

    And, there's the annoying tendency of container users (and VM users) to treat everything as root within the context of the container/VM, reintroducing a bad practice that was almost eliminated after the initial outbreak when Linux first became popular. (are container users the anti-vaxxers of software?)

    *sigh*

  3. For people who don't speak buzzwords by Anonymous Coward · · Score: 5, Informative

    A container is what used to be called a virtual machine running a single application.

    1. Re:For people who don't speak buzzwords by TeknoHog · · Score: 5, Insightful

      A container is what used to be called a virtual machine running a single application.

      Remember when men were men and such containment was the job of an "operating system"?

      --
      Escher was the first MC and Giger invented the HR department.
    2. Re:For people who don't speak buzzwords by Rutulian · · Score: 4, Insightful

      Jeez, slashdot really is a shell of its former self. None of my containers run "a single application." The benefits of a container over a VM when you are running on the same core OS on the same architecture should be obvious to anyone who manages servers. What Docker containers bring over "ordinary" containers is superior portability. So, yeah, it is good for software deployment, but nobody is going to use it to bundle libreoffice.

    3. Re:For people who don't speak buzzwords by Rutulian · · Score: 2

      Portability of the container, not portability of the program. Most container variants have the ability to migrate to another node or clone additional instances, but it's usually a bit rough and doesn't always go completely smoothly. Docker is really making an effort to polish this so that you can, say, configure an instance of your data analysis container, start it up on a single node, quickly expand it to 20 nodes under load, and then bring it back down to 1 node, or have it failover to different nodes if one crashes, etc.... That's the ideal that VMs have been able to do for some time, but hasn't quite worked out with containers yet.

    4. Re:For people who don't speak buzzwords by Rutulian · · Score: 2

      Well, containers (some variants, at least) do offer the ability to constrain resources. You should be able to prevent your Apache container from using up all of the memory on your system, for example. But the real strength of a container is the ability to just pick it up and move it to another machine, even while it is running. So it helps your situation quite a bit. Instead of needing to reprovision everything every time you move to a newer bigger box, you just configure the base system and drop the container into it, done. Ideally, your users don't even notice and their running jobs don't get interrupted. There are still a few rough spots to work out, but it's getting there.

      Another use of containers is isolation. For example, a shell for users to log in to vs. the webserver. Everything can run on a single box, but you can have different security policies for each.

    5. Re:For people who don't speak buzzwords by mrchaotica · · Score: 2

      Screw the computer stuff; I'm excited to hear about this new technology that lets gigantic cargo ships sail to Wyoming!

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    6. Re:For people who don't speak buzzwords by ancientt · · Score: 2

      I remember and it was terrible! The OS was never designed to keep applications from talking to other applications on the system. (As an AS/400 novitiate and SE adherent, I should say "practically never.")

      OS application management is something that is not as secure as a virtual machine or a jail or a container, so if you miss the days when the OS was doing it, you didn't have the problems these things are designed to solve.

      Containers aren't just virtual machines running a single application either. VMs are a full OS with all the overhead that comes with it, including hardware abstraction layers, boot times and a bunch of stuff you don't need for your application but you get anyway because you need it to run a full OS.

      Ideally you should be able to have a virtual machine that only needs a sliver of resources because you only need it running one thing but that's not what VMs provide. (Though Xen came closer than most and I miss it.) An ideal VM should be fast to spin up, but with VMs you were typically booting a whole OS.

      Jails on the other hand... Well jails are what you wish a VM running a single application would be. A jail gives you an application and only what it actually needs in order to run in an isolated package. You don't get the benefits of having an image you can snapshot or move around like you do with virtual machines, but it dramatically cuts down on resource requirements.

      Containers are basically what people want from jails and what they want from virtual machines with desirable features of each and without the drawbacks of either. They're not the solution to every problem and they're not a replacement for chroot jails or virtual machine servers, but they do have their place.

      --
      B) Eliminate all the stupid users. This is frowned upon by society.
  4. Re:It means... by Anonymous Coward · · Score: 4, Insightful

    If you're going to containerize every little application, you might as well go back to statically linking application dependencies, save perhaps libc. Save a bit of overhead there.

  5. I've seen this before... by fahrbot-bot · · Score: 2

    The list of folks signing up to support the effort contains the usual suspects, and this too is a good thing: Amazon Web Services, Apcera, Cisco, CoreOS, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, the Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware.

    And the band of new brothers and sisters set off on their Quest, little realizing that buried deep in the core code was this:

    One Container to rule them all, One Container to find them,
    One Container to bring them all and in the darkness bind them.

    Many would die along the way.

    --
    It must have been something you assimilated. . . .
  6. Re:It means... by Rutulian · · Score: 3, Insightful

    But, that ignores the problem that modern containers really exist to solve dependency hell

    Uh, no, that is not why containers exist at all. Containers are the linux equivalent of BSD jails and Solaris zones, which have many use cases. While you CAN use containers to manage dependencies, there are many other (better) ways to do that.

    And, there's the annoying tendency of container users (and VM users) to treat everything as root within the context of the container/VM,

    I don't know anybody who does this. Who do you work with?