Docker already includes a registry :)

"docker pull borplk/tres.io"?

You can search at http://index.docker.io

And web UIs for docker:

https://github.com/crosbymichael/dockerui

https://github.com/ehazlett/shipyard

I have created a script to run tree.io in docker with a lightweight (25MB) postgresql instance. Simply install Docker then run this script https://gist.github.com/funkotron/6025664

What you're proposing are virtual appliances, a virtual machine image "intended to eliminate the installation, configuration and maintenance costs associated with running complex stacks of software" (to quote https://en.wikipedia.org/wiki/Virtual_appliance). It's not uncommon to see commercial software distributed this way, and I've seen some open source projects do it as well. There are multiple existing attempts to build a "registry", such as https://www.vmware.com/latam/appliances/ and http://www.turnkeylinux.org/

The problem with VMs is that they're not a practical vehicle for shipping software, because they're not portable. Developers will always have to deal with multiple incompatible VM formats, in addition to deployment targets which simply don't support VM deployment at all. What's missing is a "common ancestor" to all these different formats, which can be exported to a VM when necessary, but also run natively in places where VMs are not available. That's what docker containers are.

There's a standard format, OVF, that the relevant players seem to support. The number of deployment targets that support some kind of virtualization software will always be higher than the number that support docker.

Docker: A linux distribution with kernel 3.8 (released in 2013) or newer.

OVF: A linux distribution with kernel 2.6.20 (released in 2007) or newer, or Virtualbox, or Citrix XenServer, or the VMware products, or Microsoft's Hyper-V, etc...

For a "common ancestor", despite docker's awesomeness I don't see anything special it has to offer in this regard. What's appropriate is properly packaged software that lends itself to automated configuration. That can be used for installs on bare metal, generating docker images, and generating images for other platforms via tools like http://www.packer.io and http://en.opensuse.org/Portal:KIWI

> There's a standard format, OVF, that the relevant players seem to support

I'll just point to the elephant in the room: EC2 doesn't support it. Neither do the majority of IAAS players. Even those that are OVF-based under the hood often don't have a facility for loading your own OVFs, let alone sharing them, etc. And when they do, the first thing they implement is some proprietary extension.

> The number of deployment targets that support some kind of virtualization software will always be higher than the number that support docker.

I don't believe that is correct. But of course the burden is on me to prove you wrong :)

Keep in mind that:

1) Docker is 3 months old and artificially narrows its support window to keep moving fast. For example it doesn't yet support 32-bit architectures, or arm, or install on red hat - but it will.

2) When it does expand its support window, docker will run on 2.6 kernels. Dotcloud has been deploying lxc containers at large scale since 2010, all on 2.6.

3) In the future docker will support non-lxc backends such as openvz, bsd jails, solaris zones and plain old chroot. At the end of the day a docker container is just a tarball with metadata describing what the developer expects to happen when it's run.

4) Also keep in mind that on many systems, virtualization is supported but not available to the relevant party. A typical example is an IT shop with a shiny new openstack deployment which still requires developers to fill triplicate forms to provision machines.

Again, this is in addition to machines which are not configured to support virtualization - often because the overhead is too high.

So I stand by my statement. In the future docker containers will be deployable on more machines than any given VM. And VMs will be used primarily for flexible hardware and kernel allocation, which is what they are good at.

> What's appropriate is properly packaged software that lends itself to automated configuration.

That's just it: for a large and growing number of developers, there is no tool available to "properly package" their software, because they combine multiple languages and frameworks, and don't wish to be stuck with a single OS distribution. I won't list the alternatives here, but will gladly do so if you request it. Docker has the ambition to be that tool, and I believe it is qualified for the job:

   * Automated build with 'docker build'
   * Built-in versioning
   * Facilities for sharing, discovery and distribution
   * Incremental transfer for efficient distribution of upgrades
   * Dependency management which puts the developer in control
   * No out-of-band dependencies except for docker (a 5MB static binary) and the kernel
   * Distro-agnostic: the developer and sysadmin are both free to choose their distro and system packager (if any).
   * Config management-agnostic: the developer and sysadmin are both free to choose their config management (if any)

As you suggest, a docker container can be used for installs on bare metal, generating images for other platforms via tools like packer, etc.

I talked to Solomon during DotScale 2013 and submitted that the index could be transformed into an app-store. He didn't seemed opposed to the idea but said they want to focus on making the base stable. Just saying the idea is out there.

Apart from the app-store what's missing is more container metadata with an embedded security model and maybe signed binaries. The server-side also need a UI that is higher-level than the existing Docker UI [1] project. There's also some work missing on state handling.

[1]: https://github.com/crosbymichael/dockerui