Virtual Drivers

Virtual Drivers are wrappers for existing Drivers. Then can define their own input schema, transform or pre-populate inputs, and then pass them on to a target Driver for the actual execution.

Virtual Drivers can be registered using the Register a new Resource Driver endpoint . They can then be used normally as the driver_type in Resource Definitions.

Any Resources provisioned with the Virtual Driver will display the target Driver as the Driver type being used.

A Virtual Driver needs to meet these requirements:

  • the target property must refer to an existing Driver using the driver:// schema of the format driver://{orgId}/{driverId},
  • the template property defines a Go template that converts the Driver inputs supplied in the Resource Definition into the Driver inputs for the target Driver.

Here is an example Driver definition in YAML format demonstrating how a Virtual Driver called custom-redis can be defined which provisions an ElastiCache for Redis using the Terraform Driver:

id: custom-redis
type: redis
account_types:
- aws
inputs_schema:
  properties:
    values:
      properties:
        suffix:
          title: Name suffix
          description: The Name suffix will be appended to the current application and environment ID.
          type: string
      type: object
    secrets:
      properties:
        account:
          description: AWS credentials to use.
          properties:
            aws_access_key_id:
              type: string
            aws_secret_access_key:
              type: string
          type: object
    type: object
  type: object
target: "driver://humanitec/terraform"
template: |
  values:
    source:
      path: redis
      rev: "refs/heads/main"
      url: "https://github.com/example-org/example-terraform.git"
    variables:
      name: ${context.app.id}-${context.env.id}-{{ .driver.values.suffix }}
  secrets:
    account:
      aws_access_key_id: {{ .driver.secrets.account.aws_access_key_id }}
      aws_secret_access_key: {{ .driver.secrets.account.aws_secret_access_key }}

Notes on the template:

  • The template should either be a string or an object containing string values. All string values will be evaluated as a template and interpreted as YAML.
  • Humanitec context placeholders such as ${context.app.id} are automatically expanded.
  • The inputs from the current Driver can be referenced using .driver.values and .driver.secrets as necessary.
  • Virtual Driver templates support the same set of go template functions supported by Helm .

Register Custom Drivers