The Open Container Project and What It Means 54
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.
Apparently it mean you can get arrested (Score:5, Funny)
At least in a lot of places: https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:3)
This 1979 conversion van IS my home, you insensitive bastard!
Re:Apparently it mean you can get arrested (Score:4, 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!
It means... (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.
Re:It means... (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*
Re: (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.
Re: (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.
Re:It means... (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.
Re:It means... (Score:4, 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?
Oracle? (Score:1)
No Oracle? Shocking.
Re: (Score:2)
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.
Re: (Score:2)
No Oracle? Shocking.
They have zones.
Too Many Cooks... (Score:2)
When you get a project with a bazillion vendors and no "benevolent" dictators... It will end up as politicware.
See Openstack or SDMI.
Re: (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?
Re: (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 gener
For people who don't speak buzzwords (Score:5, Informative)
A container is what used to be called a virtual machine running a single application.
Re: (Score:2)
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 [github.com]
Re: (Score:3)
Screw the computer stuff; I'm excited to hear about this new technology that lets gigantic cargo ships sail to Wyoming!
Re: (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 frankenstein
Re:For people who don't speak buzzwords (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"?
Re: (Score:2)
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.
Re: (Score:3)
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
Re:For people who don't speak buzzwords (Score:5, 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.
Re: (Score:3)
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
Re: (Score:2)
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, w
Re: (Score:3)
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 contai
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
I've seen this before... (Score:3)
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.