[drdaeman]

My personal opinion is, Docker's good when you need to be sure you deploy exactly the same stuff on multiple hosts. This includes ensuring that the code you try on local machine would be the same on the production hosts. Docker is completely worthless for deploying singleton services that you already have packaging and deployment recipes for - it just doesn't add any value for such use cases.

That is, Docker is just a packaging system + a tool to spawn the deployed stuff in an isolated environment. Now, 3 years after, they've improved dependencies (previously done by docker-compose + hacks for using it in production).

That is, I use Docker only because its images are somewhat easier to build and deploy, compared to .deb packages or plain tarballs (and it's more OS-agnostic, since Docker Machine's available on Windows and OS X, so I can just build an image with dev. environment and don't care what OS is used). Doubt it's something more than this.

[Annatar]

> My personal opinion is, Docker's good when you need to be sure you deploy exactly the same stuff on multiple hosts.

There is a technology for that already: it's called OS packaging. Docker does not maintain enough metadata to allow for in-place upgrades of individual components in an image (software and configuration lifecycle management). The best you can do with Docker is install lumps, you can forget upgrades. Docker is not a replacement for configuration management, and specifically, Docker is not a replacement for the operating system's software management subsystem.

[drdaeman]

Yes, you're right. I've mentioned that technology in the comment above. ;)

Docker is just a quick-and-dirty way to have a full system image. It's somewhat simpler than building a proper .deb (.rpm, .tar.xz, whatever one distro eats) package, especially when there's a ton of dependencies from other packaging systems (PyPI, Ruby gems, npm packages, etc.)

Oh, and unlike with many popular OS packaging systems, with Docker can actually have multiple versions of the same "package" "installed" at the same time (that's my biggest issue with dpkg), but IIRC there are no built-in provision for the migration scripts (prerm, postinst - this sort of stuff).

[orf]

> Docker does not maintain enough metadata to allow for in-place upgrades of individual components in an image

Your missing the point of a container, you don't upgrade them in place

[Annatar]

Containers are actually resource constraints, and were first introduced in Solaris 10, along with zones, which is what you appear to understand under containers. Even on GNU/Linux, containers are implemented via cgroups, which are resource controls and not a virtualization solution.

On SmartOS, when you provision a zone, you get a fully virtualized UNIX server, and you can apply a container to it by defining resource constraints, but that is both pointless and unnecessary there. Once you have a fully virtualized server provisioned from an image with the imgadm(1M) and vmadm(1M), it is only logical that you will want to service individual components via pkg_rm and pkg_add, rather than baking an entire image all over again, and redeploying it, all over again. It's the rule of modularity: "write simple parts connected by clean interfaces" [Kernighan-Plaguer], and it applies particularly well to lightweight virtualization.