Skip to main content

Resource Plugins

Working Example

For a full working code example covering all the concepts described below, see

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.

kind: SignadotResourcePlugin
name: hotrod-mariadb
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
namespace: signadot
serviceAccountName: hotrod-mariadb-plugin
- 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.

ExecutableArgument 1Argument 2
/signadot/provision/bin/provisionSandbox IDResource Name
/signadot/provision/bin/deprovisionSandbox IDResource 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.

/signadot/provision/inputFile NameFile Contents
/signadot/provision/outputFile NameFile 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.