Drivers

Resource Drivers

Resource Drivers perform the provisioning of Resources. They are one of the principal extension points of Humanitec.
Humanitec provides a core set of drivers that cover many common usecase. As Resource Drivers are web services that implement the Humanitec Resource Driver API. It is therefore possible to write and register additional drivers to provide custom provisioning functionality.
Provisioning a Resource with Driver
1.The driver takes Resource Inputs specified in the resource dependency and the Driver Inputs specified in the Resource Definition.
2.It then perform whatever action is required to create the resource - e.g. calling Cloud APIs or executing IaC code.
3.It returns Resource Outputs and a set of Manifests.
4.These Resource Outputs can then be injected into Workload configuration via Placeholders and the Manifests are injected into the Kubernetes cluster.
Driver Definitions
Drivers can be registered with Humanitec using Driver Definitions. This allows Platform Teams to extend the functionality offered by Humanitec.
Driver Definitions describe the:
URL prefix on which the Driver Endpoints can be found,
​Resource Type that the driver implements (unless the driver is generic) and
Schema describing how Driver Inputs should be specified.
Generic Drivers
Most drivers can only be used to provision a particular Resource Type. Some drivers can provision resources of any type. These are known as Generic Resource Drivers. Examples of generic resource drivers include the humanitec/template driver and drivers that can execute parameterizable IaC scripts such as Terraform.
How Drivers are Implemented
Resource Drivers are web services that implement the Humanitec Resource Driver API. This API is open and can be implemented by any web service served over HTTPS that is accessible from a Humanitec instance.
Resource Drivers are provisioned under a Globally Unique Resource ID (GUResID) which is unique to the Resource Context and the Resource Type. Provisioning the same resource is guaranteed to use the same GUResID every time. When the resource needs to be destroyed, the same GUResID is used.
The GUResID is deliberately opaque so as not to leak any of the Resource Context to the driver. This reduces the risk of unintentional coupling between resources being provisioned and also the risk of leaking internal IDs to a 3rd party. Where Resource Context is required by a driver, it can be injected into Resource Inputs via the context Placholders.

Definitions

References

Last modified 1yr ago