In this tutorial, we will see how to write an Instance Profile
SlapOS defines several conventions about Software Instances.
As a reminder, the instance profile, "instance.cfg", is run by buildout
when slapgrid asks for deployment of an instance. This is a simple
Buildout profile describing how to deploy the instance:
As we saw earlier, SlapOS Node processes (i.e run Buildout) each instance at least once per day.
It means that Instance profiles and recipes have to be "promise based" and shouldn't blindly
initialize the instance and should take into consideration that it will be run very often.
One practical way to handle this problem is to check for any existing data before overwriting anything
that can possibly break instance.
Example of pseudocode taking care of existing data:
if not password_already_set:
Here, it is safe to run often buildout for the instance because it won't overwrite your password.
Generally speaking, a service (== a Software Instance) is composed of one or several
executables (Apache, Mariadb, Varnish, ...) that are run by the operating system.
In SlapOS, you can define such executables that will be run when starting the
instance, then terminated when stopping the instance.
There are two types of executables:
Those executables can be anything: shell scripts, Python scripts, symbolic
links to executable located into the Software Release directory (/opt/slapgrid/0123456789abcdef), ...
Usually, it is a simple shell script that runs (exec) an executable located into
the Software Release directory, with all the needed arguments: location of
configuration file, option to stay in foreground, ...
SlapOS Node, after having run buildout for a Software Instance, will add all
executables present in those two directories to the Supervisor (a.k.a
process manager) configuration then
ask start or stop of them. Supervisor is then responsible of reporting to
SlapOS Node any suspect "service" process exit.
You will usually need your users to specify a few parameters for their instance. It can be anything; in the case of KVM (virtual machine), we allow the user to define amount of RAM, CPU, disk, etc.
Of course, by default, we want the instance to just work. So we provide default parameters. They are useful for two things:
A generic rule is that an empty parameter is equivalent to no parameter at all.
In the KVM instance profile, we can add, in the slap-parameter section representing all the parameters given by the user:
# Default value if no second disk is specified. Will be ignored by the kvm recipe
# Default value for RAM amount, in MB
ram-size = 1024
Then, if the user specify ram-size, it will just overwrite the value here.