Introducing the Container Driver
The Humanitec team is excited to announce the release of the new Container Driver!
The Container Driver in simple terms runs a container in a Kubernetes cluster in your infrastructure. This container can be and do anything you like as long as it writes outputs to specific JSON files. The driver handles almost all of the common driver stuff for you - it can even check files out of git and make them available to your container if that is useful!
The Container Driver provides significant additional flexibility to Platform Engineering teams making it easy to integrate the Platform Orchestrator with additional tools and technologies without the overhead of having to write a custom driver.
Wait, what are drivers again?
One of the most important jobs of the Platform Orchestrator is provisioning resources. If a workload's Score file says it needs an S3 bucket and a DNS name, the Platform Orchestrator has to make sure that these are provisioned so they can be consumed by the workload once it is deployed. The actual provisioning is done by a Driver. The driver takes some input parameters, does some work to create or update whatever is needed, and then returns some outputs.
The Platform Orchestrator provides a number of these drivers out of the box. Some of them are quite specialized such as the various database and DNS drivers which just create databases and DNS names respectively. A handful of drivers are generic and can be used for provisioning lots of things. The most used example of these drivers is the Terraform Driver. This runs Terraform and so can provision anything that can be provisioned via Terraform.
Drivers are an extension point for the Platform Orchestrator. This means that if you need to provision something that cannot be provisioned by an existing driver, you could always write your own driver. It has always been possible to write your own drivers and register them with the Platform Orchestrator, but that is a major undertaking. Not only do you need to write a service that implements the driver API, but you need to make sure it deals with error states and of course it needs to be maintained.
Terraform is not enough any more
It might seem that with a Terraform Driver, there is not much need for any other type of driver - after all what cannot be provisioned with Terraform these days? While the vast majority of Infrastructure as Code is done with Terraform, there are also a lot of teams who choose to use other technologies. Some utilize other tools such as Pulumi, Bicep or AWS CloudFormation. Many have been affected by the recent license change to the Hashicorp Terraform project. The license does not allow Humanitec to provide or support a Terraform Driver using a version under the new license. This means that the existing Terraform Driver is stuck at the last version: v1.5.7.
It seems a lot to ask of Platform Teams to author their own driver to support their IaC of choice - especially as there is likely to be a lot of commonality between different teams. So the Humanitec Engineering team have developed a new type of driver: The Container Driver!
How does the Container Driver work?
The Container Driver runs a Job in your Kubernetes cluster. The job is made up of the container that you supply, and helper containers that run as sidecars provided by Humanitec. These sidecar containers are responsible for setting everything up and handling the marshaling of things to and from the main driver.
The only requirements for the main container are that it must:
- return `0` on success or anything else on error
- write outputs to a set of files in JSON format
- write log messages to stdout
You can configure the following things for your container:
- the container image to run
- command and arguments that the container should be executed with
- files that should be mounted into the container
- environment variables that should be set in the container
- a git repository that should be checked out and mounted on the container
In practice, this means that it is usually not necessary to build an image to use the driver. It is often sufficient to provide a small script to wrap the CLI provided in many providers' default images.
See here for some examples: Container Driver Examples
As of today, the Container Driver can only be used with managed clusters (EKS, AKS or GKE.)
What's next?
Over the coming weeks we will be developing and publishing Virtual Drivers based on the Container driver that provide easy integration for common IaC tooling such as Pulumi, OpenTofu and AWS CloudFormation, so stay tuned!
