|
|
|
|
|
by azernik
3809 days ago
|
|
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. |
|
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.