I don't agree with your gripes about Docker though, it does actually solve problems and allows developers to define what the requirements are for their software to run (it also makes build systems much less horrible). More importantly, all software is "random files copied from the developers laptop", so I don't see why that's a negative.
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?
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.
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.
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.
Thanks for the SmartOS reference, it looks very interesting.
SmartOS and other Solaris derivatives have the only container implementations that actually work well. They are where Linux will be in a decade.
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.
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.
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.
The point is that to get around Docker's security issues, you have to run it in a VM to get secure multitenancy.