Docker joins the Linux Foundation

Just a guess:

Vendors certainly seemed more focussed on getting people to use complicated virtualization schemes with proprietary hypervisors. I wonder if it was more a matter of man-power at that point.

In comparison, Sun was already selling systems so the value of selling virtualization separately so zones may have ended up being an elegant integrated solution. I'm not sure of the FreeBSD jail history but there may be a similar story to tell if you look at the source of the contributions.

There is OpenVZ, LXC and Linux-VServer which are the same as FreeBSD jails but for the Linux kernel.

Here is a 2006 article about it - there is no doubt more stuff on LWN if you dig around https://lwn.net/Articles/179361/

The gist is that there were a lot of out of tree solutions (openvz is still used eg by Travis CI) but they had conflicting requirements and a lot of the suggestions were just "we need BSD jails" which is a very monolithic single purpose solution, like having a web server in the kernel (yes there was one) rather than having the kernel APIs in place so that was not needed.

What we have ended up with (mainly cgroups and namespacing basically) is much more flexible in that each piece is for a separate thing, eg you can just namespace networks without full isolation (which is really useful for eg testing network code without messing with the real config).

It did take a very very long time though.

Here is my conjecture from a few days ago: https://news.ycombinator.com/item?id=5901649

In summary, I think it's because containers, although open source, are a relatively commercial technology. Interested in any comments from people were there in the 90's when lots of hosting providers started using Linux.

I've been running OpenVZ for years - It works very well.

LXC is built into the kernel directly, rather than a patch, which is very nice.

So far as I can see, Docker is just some nice wrapper scripts around LXC, nothing particularly revolutionary in and of itself.

Linux has had containers for ages. Docker has simply made them easier to use as a service.

You should be asking why Solaris/BSD never had something as useful as docker despite having zones/jails. And linux supports overlay filesystems (to clone containers cheaply) without the need for ZFS.

The facilities in the kernel for doing this have gotten better progressively over the years. Support for separate namespaces, and adding more and more of those types of namespaces have only been added in the last few years.

Basically. One thing to consider is the fact that decoupling applications and services they interact with is generally considered a good practice. What services does a web application need? Generally speaking, a web process to handle requests, a database, and maybe some in-memory storage such as memcache. What docker can do is script the creation of these services as containers that can be deployed "anywhere." So say you have your web app now, and your 3 services are on a single server and the load is getting heavy because of database queries. Docker makes it extremely easy to reliably move the services between servers to handle the load better.

Albeit this is a very simplified vision, I don't think the complete use cases for docker have been hashed out quite yet. tl;dr dev ops is about to get magnitudes easier.

Yes, that's exactly the goal of docker: "build once, actually run anywhere".

Docker is a portable container engine. It gives you, the developer, a way to package your app and all its dependencies into a portable container which can be deployed on any modern Linux server: local VM, bare metal server, EC2 instance, doesn't matter. Containers are completely sandboxed and do not interfere with each other (think "iPhone apps for the server").

The specificities of each machine (location, distro, storage, networking) are abstracted away so you can focus on what your application requires (a known filesystem state, tcp ports to receive connections...) without having to worry about how those requirements will be met on each individual machine. This abstraction is based on common unix concepts - files, processes, tcp connections - and is therefore not language-specific, so it doesn't matter what programming language your application is written in.

To do this, Docker relies on a recent feature of the linux kernel called lxc. That's the part which allows sandboxing of applications from one another. The concept itself is not new - what is new is that it is now part of the mainstream kernel, which means almost every server in the world will soon be capable of running docker containers - hence the exciting possibility of "run anywhere".

That would be fantastic. Unfortunately I don't have the answer right now.