Clearly those two commands can't by themselves know how to set up a database; I'm assuming it's in the JSON file, but then not showing it is somewhat misleading. It would certainly not look as clean if you were to include a big "echo ... > vm.json".
Also, the database setup is only the first part, it then goes on to show container linking and etc.
With SmartOS, the database image can be preconfigured and published into the catalog, so when the image is pulled down with imgadm(1M), the database is already ready to take data and serve.
The complex startup he then continues to hack on is superfluous on SmartOS, as SmartOS has the service management facility for that. For brand new services, one XML file and svcadm import later, the thing is ready to be turned into an image, never to have to be revisited again.
I do not understand why people take the harder way to do the same thing (if there is no clear advantage to doing it the harder way). He picked MySQL, a database which is infamous for data corruption and bugs where basic SQL functionality does not work; the substrate, Ubuntu, provides no fault management architecture, no end-to-end data integrity, no post mortem kernel debugging and dynamic tracing facilities, which will eventually result in incidents in the dead of the night. Then there is the choice of Docker, which is really not designed to run a fully functional virtual server, but a single process in a single image (although it can run something akin to a virtual server, with lots and lots of extra system engineering put in). Why choose Docker, when with zones on SmartOS one can have a fully isolated, fully functional UNIX virtual server, but running at the speed of bare metal, and all of that in a single invocation of vmadm -f vm_definition.json (or use the SDC software, which puts a GUI on top of it all)?
If something more reliable and easier is available, why insist on doing it the harder way with an unreliable substrate? There appears to be no logic here, and if there is any, it escapes me. Is it lack of awareness of SmartOS, FMA, SMF, ZFS, and zones, or something else?
With SmartOS, the database image can be preconfigured and published into the catalog, so when the image is pulled down with imgadm(1M), the database is already ready to take data and serve.
So can with Docker. The author simply chose to use a pre-built image instead.
The complex startup he then continues to hack on is superfluous on SmartOS, as SmartOS has the service management facility for that. For brand new services, one XML file and svcadm import later, the thing is ready to be turned into an image, never to have to be revisited again.
In Docker that's called a Dockerfile. It does exactly what you describe. Again, the author simply didn't do that.
He picked MySQL [and] Ubuntu
It's an example, does it really matter? Maybe the author is simply more familiar with it.
Why choose Docker, when with zones on SmartOS one can have a fully isolated, fully functional UNIX virtual server, but running at the speed of bare metal
The fully functional containers you've described have been available for Linux for years before SmartOS was first released, first as OpenVZ and then as LXC. Docker's approach is not a technical limitation, it's a deployment philosophy. They don't want fully functional UNIX servers, they want disposable stateless containers that can killed off and cloned.
If something more reliable and easier is available, why insist on doing it the harder way with an unreliable substrate? There appears to be no logic here, and if there is any, it escapes me. Is it lack of awareness of SmartOS, FMA, SMF, ZFS, and zones, or something else?
I suggest you then read up on Docker and the motivations behind its creation and popularity before suggesting that everyone in the thread is illogical and ignorant, because - and I say this as someone who doesn't really like Docker - your advocacy for SmartOS has a vibe of the infomercial from Family Guy: https://www.youtube.com/watch?v=5ysMt_9JnyI
> In Docker that's called a Dockerfile. It does exactly what you describe.
Actually it does not, as SMF is part of the fault management architecture, which is part of the Solaris self-healing technology: unlike the Docker file, SMF will watch over services and restart them if necessary, if configuration files are specified as dependencies and they change, SMF will call the service's refresh method. Docker is just a delivery mechanism, whereas SMF is part of something bigger and far more powerful. SMF ties into FMA, which actually watches over not just software, but hardware down to the individual chips in the memory slots (when not running on virtual hardware). Even on zones, SMF provides the benefit of uniform diagnostics. Docker isn't designed for any of that, which is why he had to hack on the microservice setup.
> fmadm
Usage: fmadm [-P prog] [-q] [cmd [args ... ]]
fmadm config - display fault manager configuration
fmadm faulty [-afgiprsv] [-u <uuid>] [-n <max_fault>] - display list of faulty resources
fmadm flush <fmri> ... - flush cached state for resource
fmadm load <path> - load specified fault manager module
fmadm repaired <fmri>|label> - notify fault manager that resource has been repaired
fmadm acquit <fmri> [<uuid>] | label [<uuid>] | <uuid> - acquit resource or acquit case
fmadm replaced <fmri>|label - notify fault manager that resource has been replaced
fmadm reset [-s serd] <module> - reset module or sub-component
fmadm rotate <logname> - rotate log file
fmadm unload <module> - unload specified fault manager module
That up there is science fiction in Docker. As is something like this:
> svcs -xv bacula
svc:/site/bacula:sd (Bacula storage daemon)
State: online since Sat Apr 23 06:54:00 2016
See: man -M /opt/abcd/share/man -s 1M bacula-sd
See: /var/svc/log/site-bacula:sd.log
Impact: None.
svc:/site/bacula:fd (Bacula file daemon configuration)
State: online since Sat Apr 23 06:54:00 2016
See: man -M /opt/abcd/share/man -s 1M bacula-fd
See: /var/svc/log/site-bacula:fd.log
Impact: None.
svc:/site/bacula:dir (Bacula host specific configuration)
State: online since Sat Apr 23 06:54:00 2016
See: man -M /opt/abcd/share/man -s 1M bacula-dir
See: /var/svc/log/site-bacula:dir.log
Impact: None.
> The fully functional containers you've described have been available for Linux for years before SmartOS was first released, first as OpenVZ and then as LXC.
Actually no, since the "containers" are zones in SmartOS, and I've been using zones since 2006, when they first came out in Solaris 10 update 2. This was before OpenVZ and LXC.
Zones gave me virtual UNIX servers. Solaris containers gave me caps on those servers. Both came in one package back in 2006. SmartOS, being a freeware open source Solaris derivative leverages all that technology, plus a whole bunch more which neither Solaris nor GNU/Linux nor Docker have. Designed for exactly what the author of the original article was trying to hack up together, minus all the hacking.
