6. Influencing Workflow Behavior¶

During an application’s lifecycle several house keeping tasks may need to be completed to ensure the seamless deployment and maintenance of the application. Depending on the application, tasks may need to be completed before or the life cycle operation to be performed. Moreover the aforementioned tasks may need to be executed in different contexts since it might need to performed at an application level or with a finer grain of control at the container level.

In order to achieve seamless application deployment and maintenance Robin supports several application lifecycle operations and provides a framework to execute application/Vnode level hooks before or after the respective operations. In addition, Robin also provides the capability to run custom entrypoint scripts for Docker based applications.

Moreover in certain scenarios, Kubernetes objects that are not currently supported in the Robin framework but can be spawned natively are needed for a successful application deployment. To resolve this, Robin allows one to specify a set of YAMLs for Kubernetes object creation before and after the instantiation of the main pods/containers.

6.1. Vnode Hook Scripts¶

Vnode hook scripts are run for each individual container. For each Vnode lifecycle operation, there is an accompanying script that can be run either before or after the operation is executed.

The following interpreters are supported for Vnode hooks:

bash
sh
Python

Note

It is highly recommended that Vnode hook scripts are idempotent i.e. the consquences of their execution should remain constant regardless of how many times they run.

The list of Vnode hooks that can be run are as follows:

Hook Name	Description
precreate	Script that is executed before an Vnode is created during an ApplicationCreate job
postcreate	Script that is executed after creating a Vnode during an ApplicationCreate job
prestart	Script that is executed before starting a Vnode during ApplicationStart job
poststart	Script that is executed after starting a Vnode during ApplicationStart job
prestop	Script that is executed before stopping a Vnode during ApplicationStop job
poststop	Script that is executed after stopping a Vnode during ApplicationStop job
pregrow	Script that is executed before scaling out during ApplicationScale job. Will be run on the new Vnode.
postgrow	Script that is executed after scaling out during ApplicationScale job. Will be run on the new Vnode.
preclone	Script that is executed before cloning a Vnode during ApplicationClone job.
postclone	Script that is executed after cloning a Vnode during ApplicationClone job.
presnapshot	Script that is executed before taking a snapshot of a Vnode during ApplicationSnapshot job.
postsnapshot	Script that is executed after taking a snapshot of a Vnode during ApplicationSnapshot job.
prerollback	Script that is executed before rolling back a Vnode during ApplicationRollback job.
postrollback	Script that is executed after rolling back a Vnode during ApplicationRollback job.
predestroy	Script that is executed before deleting a Vnode during ApplicationDelete job.
postdestroy	Script that is executed after deleting a Vnode during ApplicationDelete job.

Note

Vnode hook scripts have access to all ENV variables defined in the manifest for the Vnode in the form of key value pairs alongside two additional keys, hostname and ROBINHOST, whose values are the container hostname and physical hostname of the node on which it is placed respectively. As a result, any custom arguments that need to be passed to the scripts should be done so as key-value pairs and parsed appropriately in the script.

6.2. Application Hook Scripts¶

As the name implies, application hook scripts are run at the application level and thus can impact any containers that are part of the application. Application hooks are executed once all application containers are successfully spawned. For each application lifecycle operation, there is an accompanying script that can be run either before or after the operation is executed. In addition, there are two additional scripts which can be run to extract information and derive the health status of an application. These scripts are detailed in the table below.

The following interpreters are supported for application hooks:

bash
sh
perl
Python
Ruby
ansible-playbook

Note

It is highly recommended that Vnode hook scripts are idempotent i.e. the consquences of their execution should remain constant regardless of how many times they run.

The list of application hooks that can be run are as follows:

Hook Name	Description
info	Information hooks are executed to provide additional details about an application.
validate	Validate hooks are executed to ensure the deployment inputs are appropriate before creating an application.
health	Health hooks are executed to assess the health of an application. The hook runs every 90 seconds and is expected to return 0 or 1.
precreate	Script that is executed before creating an application. Typically, any validation and/or prechecks that are needed for the deployment are included in this script.
postcreate	Script that is executed after an application is successfully created. Typically, any initial setup tasks can be included in this hook.
prestart	Script that is executed before an application is started.
poststart	Script that is executed after an application is started.
prestop	Script that is executed before an application is stopped. Typcially, any commands needed gracefully stop the application are included in this hook.
poststop	Script that is executed after an application is stopped.
pregrow	Script that is executed before an application is scaled out.
postgrow	Script that is executed after an application is scaled out. Typically, any commands to update the application configuration to account for the new instance are included in this hook.
preclone	Script that is executed before an application is cloned.
postclone	Script that is executed after an application is cloned. It will be invoked on the cloned application.
presnapshot	Script that is executed before a snapshot of an application is taken. Typically, any commands to Quiesce the application are included in this hook.
postsnapshot	Script that is executed after a snapshot of an application has been taken. Typically, any commands to un-Quiesce the application are included in this hook.
prerollback	Script that is executed before an application is rolled back to a snapshot. Typically, any commands to gracefully stop an application (if required) are included in this hook.
postrollback	Script that is executed after an application has been rolled back to a snapshot.
predestroy	Script that is executed before deleting an application.
postdestroy	Script that is executed after deleting an application.

Note

The only argument application hooks can process is a path to a JSON file containing the application defintion and details. As a result, the script will have to parse this information in order to utilize it. In addition hooks that run for operations such as cloning and scaling require both the current and original application configurations. Thus the path to both JSON files are passed to the respective scripts.

6.3. Order of execution¶

All specified application level hooks will be run once per lifecycle operation regardless of it was triggered via an event or manually by a user. In addition all specified Vnode level hooks will also be run once for each container associated with an application everytime a lifecycle operation occurs. For manifests in which there is a combination of application and vnode level hooks specified for a particular operation, the following order will be adhered to if the respective scripts exist: the application pre-operation hook will run, followed by the pre and post-operation Vnode level hooks and finally the application post-operation hook will run.

Note

For every lifecycle operation only the pre/post hook scripts for that particular operation will run regardless of its a Vnode or application level hook script.

6.4. Creating additional Kubernetes objects¶

Robin bundles allow users to deploy Kubernetes native objects such as daemonsets, cronjobs, configmaps, secrets etc. as pre/post actions while executing bundle application hooks. Users can configure Kubernetes object YAML files to their liking and include them within the scripts folder. In addition, depending on the directory they are placed in these objects will be spawned before and and/or after the application create stage. Since these objects are considered to be part of the Robin application, when the associated application is deleted the aforementioned objects will be cleaned up automatically.

In order indicate that additional Kubenetes objects need to be created a directory named k8s should be present within``scripts`` folder of the bundle. For Kubenetes objects that need to be created pre-application deployment, the respective YAML definitions need to be placed within another sub-directory called pre within the k8s folder. Similarly, for Kubenetes objects that need to be created post-application deployment, their respective YAML definitions should be under the post directory within the k8s folder.

An example of the bundle directory structure with Kubernetes configuration YAMLs is shown below:

- manifest.yaml
- scripts
  |--k8s
     |-- pre
         |-- test-daemonset-preapp.yaml
         |-- test-configmap-preapp.yaml
         |-- .jinjaignore


     |-- post
         |-- test-daemonset-postapp.yaml
         |-- test-configmap-postapp.yaml

Note

Kubenetes objects created as part of the application deployment will be spawned in the same namespace as the associated application.

In addition users are able to use Robin defined macros as a part of specified YAML definitions in order to access run time information. An example of their usage is shown below:

kind: ConfigMap
metadata:
  name: "{{APP_NAME}}"
  namespace: "{{APP_NS}}"
data:
  port_config: 2222

kind: Secret
metadata:
  name: "{{APP_NAME}}-post-secret"
  namespace: "{{APP_NS}}"
type: Opaque
data:
  username: YWRtaW4=

Users will also have the option to skip Robin Jinja macro evaluation for YAMLs under the pre and post directories within the k8s folder by including a .jinjaignore file as showcased in the directory structure above. In this file, users can list the YAMLs for which macro evaluation should be skipped. An example of a .jinjaignore file is shown below:

### cat .jinjaignore
test-daemonset-preapp.yaml
test-configmap-preapp.yaml

In order to skip Jinja macro evaluation for all YAML files under the pre and post directories, a single wildcard character can be specified within the .jinjaignore file as shown below:

### cat .jinjaignore
*