Resource Plugins

Working Example

For a full working code example covering all the concepts described below, see https://github.com/signadot/hotrod/tree/main/resource-plugins/mariadb.

Resource Plugins are responsible for provisioning and deprovisioning Resources. Resource Plugins are installed directly into the Kubernetes cluster using a Kubernetes CustomResource and are invoked during the creation and deletion of sandboxes that reference them.

Example Plugin

Below is an example of a SignadotResourcePlugin that creates new maria-db resources when requested by a Sandbox. As stated in the description, it takes an input of dbname and emits 3 output parameters, host, port and root_password which can then be bound to workloads within the sandbox as explained in resources.

apiVersion: signadot.com/v1
kind: SignadotResourcePlugin
metadata:
  name: hotrod-mariadb
spec:
  description: |
    Provision a MariaDB instance for one of HotROD's services.
    Sandbox should provide input 'dbname' for the name of the database.
    Plugin provisioner provides outputs 'host', 'port', 'root_password' for 
    an empty database instance tied to the lifetime of the sandbox.
  type: ExecPod
  execPod:
    template:
      metadata:
        namespace: signadot
      spec:
        serviceAccountName: hotrod-mariadb-plugin
        containers:
        - image: signadot/hotrod-mariadb-plugin:latest
          name: plugin

Note that some RBAC definitions that are necessary have been omitted above for brevity that you can find in the full example. In the above YAML, we have a pod specification under execPod that indicates that every time this resource plugin is invoked, the pod specified should be created.

When a sandbox requests the creation of a resource as shown in resource usage, the corresponding plugin responds by creating a pod from the above template. The provision command (as specified in the below section) is run in the pod which in turn creates a new maria-db resource. Seeding or other steps can be performed as well as part of this provisioning workflow optionally. When the sandbox is deleted eventually, a new pod is created and runs the corresponding deprovision command to tear down the maria-db resource. The section below explains the contract that a resource plugin needs to adhere to in order to work with sandboxes.

Provisioning Workflow

Initially, when a new resource is requested, the provision binary under /signadot/provision/bin/provision is called with arguments sandbox-id and resource-name as arguments. In the deprovisioning case, /signadot/provision/bin/deprovision is invoked with arguments sandbox-id and resource-name. The deprovisioning flow upon completion should destroy the resource created.

Executable	Argument 1	Argument 2
/signadot/provision/bin/provision	Sandbox ID	Resource Name
/signadot/provision/bin/deprovision	Sandbox ID	Resource Name

Any resource plugin input parameters that are passed in are mounted as files. i.e. if an input parameter called dbname is passed in, it will be available at runtime under /signadot/provision/input/dbname. After the provisioning is completed, output parameters should be written files. For example, if there is one output parameter named DB_HOST with value foo.svc, the provisioner will need to write one corresponding file, /signadot/provision/output/DB_HOST with its contents being foo.svc.

Directory	Key	Value
/signadot/provision/input	File Name	File Contents
/signadot/provision/output	File Name	File Contents

Custom Plugins

For a custom resource plugin, a custom docker image is required that adheres to the contract specified above. Once that image is built, it can then be wrapped up in a SignadotResourcePlugin object and deployed into the Kubernetes cluster for usage with sandboxes.