Take Terraform Providers to the Next Level Using Inmanta

Terraform is an infrastructure and resource management tool that provides integration with over a thousand types of devices, platforms, and APIs. Inmanta on the other hand also operates at a higher level in which it provides end-to-end & multi-domain service orchestration, self-healing, and service management through a powerful modeling language.

The Inmanta Terraform Adapter allows you to combine this power: it enables you to use Inmanta’s advanced multi-domain service orchestration with all Terraform providers, without the need to have Terraform installed.

In short, this combination lets you:

• Use any Terraform provider as if it is an Inmanta adapter,
• Generate an Inmanta module from any Terraform provider,
• Have a more fine-grained and broader management over your infrastructure state through Inmanta Web Console,
• Benefit from Inmanta’s multi-domain service orchestration, truly intent-based and full lifecycle management system.

In this post, we will show you how this blend works.

Usage Methods

There are two ways that you can utilize Terraform providers through Inmanta:

1. Terraform providers in Inmanta models: import Terraform providers in your model and populate resources based on the Provider‘s documentation.
2. Inmanta Terraform Generator: generate Inmanta modules from Terraform providers and use it in your model.

In the second approach, we will automatically fetch the needed Provider and build an Inmanta model from it, without you ever needing to refer to that provider’s documentation to find the right values. This approach is more convenient but the choice is yours to make.

Let’s unpack these methods and inspect how either of them works.

 Terraform providers in Inmanta models

Our Terraform Adapter allows the Inmanta Service Orchestrator to use any existing Terraform provider. For instance, take the following snippet of Terraform code, that uses the Helm provider to deploy the Helm chart simple_example to Kubernetes.

terraform{     required_providers{         helm = {             source = "hashicorp/helm"             version = "2.4.1"    
     }     } }  provider "helm" {   kubernetes {     config_path = "~/.kube/config"   } }  resource "helm_release" "test" { 
  name = "helmtest"   chart = "simple_example" }

In Inmanta code, using the Terraform adapter, this looks very similar.

import terraform  helm_provider = terraform::Provider(     namespace="hashicorp",     type="helm",     version="2.4.1",     
config={         "kubernetes": [{             "config_path": "~/.kube/config",         }]     }, )  terraform::Resource(     
provider=helm_provider,     type="helm_release",     name="test",     config={             "name": "helmtest",            
 "chart": "simple_example",     }, )

Inmanta Terraform Generator

We can take this one step further. Terraform providers carry information about what arguments they can accept. We can use this information to generate an Inmanta module that corresponds to the Terraform provider.

For example, following the instruction provided here:

git clone https://github.com/inmanta/terraform-generator cd terraform-generator pip install . python src/__init__.py 
--namespace hashicorp --type helm --version 2.4.1 ../libs   

We get a module that corresponds to the Terraform provider. This allows us to write the model even more concisely.

import helm import helm::provider  helm_provider = helm::Provider(     kubernetes=helm::provider::Kubernetes(         
config_path="~/.kube/config",     ) )  helm::Release(     inmanta_id="test",     chart="simple_example",     
name="helmtest",     provider=helm_provider, )

Internals

Terraform providers are independent executables that are downloaded and run by Terraform. They communicate with the main Terraform process over a well-defined protocol. All the required state of the providers is passed over to the main Terraform process to be stored in a storage backend.

The Inmanta Terraform Adapter implements these same steps:

• It downloads the required provider from the Terraform registry,
• starts the provider process,
• communicates with the provider, as if it is the main Terraform process and provides proper state storage for the provider.

Additional Resources

The Inmanta Terraform modules are part of the Inmanta Service Orchestrator 5 release. If you are interested, check out these links for more information:

• Inmanta Terraform Adapter documentation and GitHub repository.
• Inmanta Terraform Generator GitHub repository.