Or you could ship a relatively large fully installed VM image of the OS+all the application parts and dependencies (this may be problematic if your target is a licensed OS).

Docker gives you something in between.

Think of a chroot'd environment (not that that's what it is, but it shares some concepts) with all the application code, libs and dependencies pre-packaged that should run theoretically out of the box.

That way you can have a 'war' like file that contains everything required to run your app and you're 100% sure that it will just work, rather than to have to field a million questions about how to make your app run on 'obscure distro x' or 'obsolete version y'.

Another use-case would be that if you're deploying something distributed across a large cluster that you can build your docker container on your desktop box, test it until you're happy and then deploy to your cluster without having to re-test everything. Since the container wasn't changed it should work.

It's a way of isolating dependencies between various pieces of software using one single container to hold them all.

Of course this approach has its own unique set of problems, but it solves certain things quite elegantly.

I hope that explains it and that if it is wrong in some aspect that someone will correct me.

Option 3: use a package manager.

Now, I realize this doesn't solve the existing software conflict problem you mention. Nor is it mutually exclusive with shipping an image: you could always construct an image by installing packages into it.

I've always been a little wary of the "ship a golden image" idea. How do Docker images get updated? What if there's a security issue with software in the Docker image -- can my package manager automatically apply security updates? How do I push other upgrades to the client once they have a Docker instance -- do they need a whole new image from me? Package managers have solved these problems, and I hope we're not reinventing those solutions in the Docker world.

If you're familiar with Docker, please enlighten me on these points.

http://crosbymichael.com/dockerfile-best-practices-take-2.ht...

This does seem to get a bit cumbersome. I'm at DockerCon today and Fabio Kung mentioned in his talk that this is one difference from Heroku's container platform---they provide the base image and can update it without requiring you to rebuild your application slug. He said there's been some discussion of a possible "docker rebase" command that would produce new images by replacing lower-level layers while keeping higher-level layers the same.

If you just have the application running in the container then you just replace it with an updated container.

I rebuild the image. At the moment with the giant stupid image that we use for rhell land it takes about 5 minutes (builds a vmware, virtualbox, aws, qemu, and docker image (packer.io is kinda cool))

Then redeploy

By the way, I do have a basic idea of what Docker is, as well as some inclination with OS-level virtualization (FreeBSD jails and LXC), but OP's example wasn't particularly inspiring.

I'm an enormous fan of docker for solving linux sysad woes (stacking up magic numbers in /etc/passwd, etc), and it's also great as an asylum for badly designed or badly packaged applications, but let's not forget the utter magic of paths beginning in "./".