Virtual Drivers
Virtual Drivers can be registered using the Register a new Resource Driver endpoint . For a Virtual Driver:
- the
target
property should refer to an existing Driver using thedriver://
schema of the formatdriver://{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 .