[Annatar]

> from a quick look at SmartOS, it looks like yet another implementation of containerization

It is the first ever implementation of true containers (zones were released in 2005), and it is modeled on BSD jails.

What is or is not familiar to most developers is irrelevant to me when I am engineering a solution, because my focus is on encapsulation, stability and lifecycle management. What others are familiar with is irrelevant in that case, especially since correctness of operation and data integrity are priority, with everything else taking a back seat to those.

> WRT your specific gripes about subsystem rollback - the usual Docker best practice is to have each container run only a single subsystem

But it doesn't have to be: http://phusion.github.io/baseimage-docker/

besides, if there is an issue, and one were to follow running only one service inside of a Docker image, one could not ssh in to troubleshoot the image. With Solaris zones on SmartOS, it is completely unnecessary to run a single service or process inside of a zone, because zones offer full isolation. I see no sense in opting for a harder approach with Docker, especially when that approach does not offer full isolation nor security.

> If you need to upgrade or downgrade, you spin up a new container running a different image, fail over to it, and kill the old one

Which I imagine means that I have to build a whole new image, presumably based on the old image, then deploy an entire image (what if it is an Oracle database software, which is anywhere from 800 MB to 2.5 GB, not counting the database?) It is much cheaper and faster to just rebuild the affected package, and upgrade it in place inside of a zone, than having to respin an entire image, especially if that image is several gigabytes.

[tra3]

I want to discuss your last point. With Docker, you are free to either modify the image or the running container. An image is a "template" for a container and in the scenario you describe, the ideal solution is to create a new image because it can be potentially running on multiple nodes. However, nothing prevents you from accessing the container (no SSH required) and modifying the container in place. Although I do believe it is discouraged.

Thanks for the SmartOS reference, it looks very interesting.

[jacques_chester]

It's worth noting that Docker is not the only containerising system for Linux.

Just as assuming that the limits of MySQL are the limits of relational databases, assuming that the limits of Docker are the limits of Linux containers is mistaken.