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:
def install(self): if not password_already_set: set_password()
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:
[slap-parameter] # Default value if no second disk is specified. Will be ignored by the kvm recipe second-disk-location = # Default value for RAM amount, in MB ram-size = 1024
Then, if the user specify ram-size, it will just overwrite the value here.