[Annatar]

I'm saying that a lot of people end up running Docker in a VM... why?

I'm also saying that dumping a bunch of files from a developer's laptop into a Docker image is going to be a nightmare in terms of lifecycle management (how about a subsystem rollback or upgrade inside of that image?)

And finally, I'm saying I see no point to Docker, if I can just make OS packages and run them inside of zones. With zones, I have a fully functional UNIX server in complete isolation and security; with Docker, I have a re-invented init which isn't really init, and if I want SSH and all the other things one normally expects of a system, I have to engineer them myself. Why would I use Docker if I can use zones in SmartOS? What does Docker buy me?

[azernik]

a) from a quick look at SmartOS, it looks like yet another implementation of containerization, with an option to run a full KVM if you want. And it has to run as a full OpenSolaris-based system image, instead of just being a binary installable on a Linux system (much more familiar to most developers)

b) "dumping a bunch of files from a developer's laptop into a Docker image"... I'm sorry, what? I have no idea what workflow you're referring to here.

WRT your specific gripes about subsystem rollback - the usual Docker best practice is to have each container run only a single subsystem, and to have images be generated by checked-in Dockerfiles based only on checked-in resources. 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.

Once a container starts running it is immutable. Any of the features of a running container can be inferred just from looking at the Dockerfile(s) that built it and the connections it has to storage volumes, other containers, and the external network.

[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.

[dmpk2k]

Unrelatedly, but calling SmartOS "yet another implementation of containerization" is a bit like calling a Bugatti Veyron "yet another implementation of a car". Technically true, but implicitly missing the point.

SmartOS and other Solaris derivatives have the only container implementations that actually work well. They are where Linux will be in a decade.

[dschiptsov]

>SmartOS and other Solaris derivatives have the only container implementations that actually work well.

What kind of fucking bullshit is this?

What are the principal differences over FreeBSD's jails it has, or why its KVMs runs better than under Linux kernel?

The "smart" meme and arogant public rethoric is good for marketing forex to idiots, but for CS it must maintain a connection to reality.

Solaris derivatives without Oracle backing are already lagging behind in terms driver support for modern hardware, new chipsets, etc. Node hype and stupid arrogance does not make the laws of big numbers and big money to stop working.

[Annatar]

> What are the principal differences over FreeBSD's jails it has, or why its KVMs runs better than under Linux kernel?

Each zone spawns her own init. The only difference between zones and UNIX running on bare metal is that the hardware is abstracted away, especially storage. Zones use the underlying ZFS pool in the global zone, but have no privileged access to the zpool. However, if necessary, devices can be explicitly exported to individual zones, for those rare, rare cases where a zone would need access to them (like for instance running an NTP server and needing access to the hardware clock). This however is not recommended.

The reason why KVM runs as fast or faster on SmartOS than it does on GNU/Linux is the fact that in order to port it to the SunOS / illumos kernel, the kernel engineers at Joyent used DTrace, and systematically improved performance.

> Solaris derivatives without Oracle backing are already lagging behind in terms driver support for modern hardware, new chipsets, etc.

Actually illumos / SmartOS contains OpenZFS and numerous bug fixes Oracle Solaris may not import, since Oracle would then have to open source Solaris again. Indeed, illumos is now the repository of record for (Open)ZFS, DTrace, and numerous other bug fixes and enhancements, because most of the core kernel engineers who worked on those technologies quit Oracle and are now working in their new companies on illumos / SmartOS.

UltraSPARC T1 and T2 are still supported, but newer SPARC hardware from Oracle has a death sentence, since it is a closed platform; illumos runs on AMD, and it runs best on intel; intel based servers have the best support. Nobody really cares about what "Snoracle" does any more, and the engineers who quit "Snoracle" shun SPARC.

[dschiptsov]

Thank you for a technical reply.

Nevertheless I cannot see that fundamental advantage over FreeBSD, which has ZFS but still no DTrace. Moreover, as far as I remember zones and jails were modeled after the same IBM's technology.

[icebraining]

I'm not saying you're wrong, but nothing in the previous post warrants the vitriol.