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.

31 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 reboot246 · · Score: 1

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

    2. 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.
    3. 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. It means... by Anonymous Coward · · Score: 1

    It means that we'll get to hear hipsters drone on about how "great" it is, until its serious flaws and limitations (which all software systems have) become very obvious and problematic, at which point they'll jump onto the bandwagon of the next fad technology, and the rest of us will be left cleaning up the messes they've left behind.

    1. 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*

    2. Re:It means... by Anonymous Coward · · Score: 1

      It's difficult to manage many applications that all rely on slightly different versions of libraries.

      True, but if the damn library writers coded the things properly in the first place (read "no stupid buffer overflows or similar vulnerabilities") we wouldn't have so fricking many versions of the libraries in the first place. Ditto if the software developers didn't insist on using the latest patch-du-jour just in case, rather than actually analyze their code (heresy!) for what it needs.

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

    4. Re:It means... by Anonymous Coward · · Score: 1

      Vulnerabilities and their ilk should not effect the use of their application programming interface. You should be able to change how something is implemented behind the scenes to close off those avenues of attack without breaking applications using your components. If an interface changes significantly to break compatibility, it should be renamed---continue to have the old interface supported even if that is routed to the new interface "safely" behind the scenes.

    5. 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?

  3. Oracle? by Anonymous Coward · · Score: 1

    No Oracle? Shocking.

    1. Re:Oracle? by Lennie · · Score: 1

      Why would they, they are not doing anything with Linux containers right now.

      And most of the Sun developers of Solaris had left after when Oracle bought Sun.

      --
      New things are always on the horizon
    2. Re:Oracle? by dbIII · · Score: 1

      No Oracle? Shocking.

      They have zones.

  4. Too Many Cooks... by Electrawn · · Score: 1

    When you get a project with a bazillion vendors and no "benevolent" dictators... It will end up as politicware.

    See Openstack or SDMI.

    1. Re:Too Many Cooks... by Anonymous Coward · · Score: 1

      When you get a project with a bazillion vendors and no "benevolent" dictators... It will end up as politicware.

      See Openstack or SDMI.

      "Open" idea comes about where entrenched vendors view it as a threat to existing revenue streams, and choose to band together to ensure the overall "open" project is anything but.

      I'm sorry...what seems to be the problem here again, other than failure is in fact the intended design and goal?

    2. Re:Too Many Cooks... by Anonymous Coward · · Score: 1

      Java is a mess, but beats the competition

      I don't think I'd be wholly comfortable with this statement, but anyway...

      if the markets are going to go forward.

      I think that's a very big if actually. Massively distributed deployment is really the environment of a very small set of very vocal folks, each having had to care enough to establish an existing solution for their environment. Interoperability may be a nice theory, but in practice there isn't as *hard* of a need for the way that market operates. The amount of spend in this particular area is about 0.25 percent of IT spend in general, which is a huge increase compared to 0% not that long ago, but too many folks have extrapolated a 0% to 0.25% rise to an eventual conclusion that it will be the dominant paradigm in short order and therefore needs to be even more standard than rpm v deb v msi (noting of course that even with those packaging standards, many applications don't really feel that compelled to *use* them even in a traditional install, I think the pressure is even more reduced in this container space).

  5. 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 bill_mcgonigle · · Score: 1

      A container is what used to be called a virtual machine running a single application which is fucking amazing, like a standardized cargo container on a boat from Hanoi to Wyoming.

      TFTFY

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. 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.
    3. 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.

    4. Re:For people who don't speak buzzwords by nbritton · · Score: 1

      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"?

      Yeah, but then we decide to adopt shared libraries and that messed everything up.

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

      I've had a bit of time to play with Docker, and for the most part, it's gone pretty well and I quite like it (it feels like it has some rough edges, but I guess those'll get sorted out over time).

      In a (possible) future, $work wants to replace VMs with containers. Some of those VMs are imaginary at the moment, as we'll tend to run multiple instances (of say Tomcat, Apache, Postgres, whatever) on a single box, and then 'migrate' some of them to another box when things get a bit short on resource.

      At present, we find capacity planning pretty hard - we mostly just keep piling things onto a box until either the RAM is full, or the CPU looks like it's getting used up. How could containers help us here? I can see how to do it with VMs, but containers just throw processes all over the 'hypervisor' and so you're basically no better off than running without containers (in terms of capacity planning, at least).

      For me at least, I can completely understand a 'private cloudy' future where everything is a VM. Unless I can get the same understanding with Docker (or any other container), I can't see how I could support/recommend using containers except for some (relatively) limited use cases.

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

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

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

    9. 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.
    10. Re:For people who don't speak buzzwords by pnutjam · · Score: 1

      I've been toying with a container for a bit-torrent, so I can run a vpn without losing my external inbound ssh.

      --
      Cheap storage VM.
    11. Re:For people who don't speak buzzwords by allfieldsrequired · · Score: 1

      > which is fucking amazing, like a standardized cargo container on a boat from Hanoi to Wyoming.

      Which is the dumbest fucking analogy I have heard in a long time. Shipping containers come in a standard width and size, with standard size doors, standardised locks, and standardised locations for documents, cranes to attach to etc. It was revolutionary.

      A docker container, or any kind of similar thing, is no such thing, and is not comparable in any way, other than saying "you can execute whatever frankensteinian monster you have built with this semi standardised command" - a shipping container will interact with the wider world through its designated door, which always works the same way. A docker container will interact with the wider world in the ways the application would interact if it wasn't wrapped up in a container - file system, named pipes, sockets, ip's/ports and so forth. It has neither the same impact on "revolutionising" IT that shipping containers had on the freight business, nor is it any kind of standardised.

      Docker is interesting, and has a few interesting use cases, and solves a few interesting problems. It is not "fucking amazing" and it is not "changing the world the way shipping containers did". That is juvenile bullshit.

    12. Re:For people who don't speak buzzwords by runep · · Score: 1

      If on Linux, you should look into what you can do with network namespaces. (I.e. exactly what you want, without the need for a container).

    13. Re:For people who don't speak buzzwords by pnutjam · · Score: 1

      Thanks, i will check that out.

      --
      Cheap storage VM.
  6. 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. . . .