CDK for Terraform - A Quick Introduction To HACHICORP'S New IAC TOOL

Hachicorp Terraform

WHAT'S CDK for TERRAFORM?

CDK for Terraform (CDKTF) allows using generic programming languages to define and provision infrastructure. Terraform CDK provides access to the entire Terraform ecosystem without learning HashiCorp Configuration Language (HCL) and provides more elasticity to create your infrastructure with the power of a programming language for conditionals, specific input/output, testing, abstraction, dependency injection, and useability.  

 

HashiCorp Terraform teams and AWS CDK teams collaborated to create the Terraform CDK by leveraging CDK construct programming model and javascript interoperability interface, which were the two key technologies of the AWS CDK. AWS CDK construct programming model is a set of language native frameworks for developing infrastructure resources and adaptors that generate configuration files for an underlying provisioning engine. 

 

Although it’s still in active development, Terraform CDK currently supports Java, Python, TypeScript, C#, and Go (experimental).

How does Terraform CDK work?

CDK-Terraform uses libraries from the AWS Cloud Development Kit to translate the code into infrastructure configuration files for Terraform.

At a high level:

  1. Create an Application: Using the built-in or a custom template to create a project in your chosen language.
  2. Define Infrastructure: Use your preferred programming language to create the infrastructure you want to provision for your selected providers. cdktf extracts the schema from Terraform providers and modules to generate the necessary classes for your application.
  3. Deploy cdktf CLI commands to convert your code into a JSON configuration file that can be used with Terraform directly to provision your infrastructure.

 

You can use every Terraform provider and module available on the Terraform Registry.

Advantages Of using CDK for TERRAFORM :

Works with existing providers and modules. 

cdktf-cli includes a CLI tool that lets you import modules and providers hosted currently in the Terraform Registry, allowing you to leverage any of the Terraform resource providers or standard modules.

 

Preserve your current Development/DevOps Flow. 

With the cdktf-cli, the current Terraform flow remains the same, including the ability to plan changes before applying. In addition, cdktf-cli provides commands like `cdktf diff` and `cdktf deploy`, similar to AWS CDK users.

 

Familiar programming language to declarative state. 

With cdktf, you write infrastructure code using standard programming languages(if it is currently supported). Still, it produces your desired infrastructure state as standard JSON, just like the regular terraform process. Terraform for CDK provides the flexibility and power of using a programming language without sacrificing the robust and declarative state approach.

 

Language support.

cdktf lets you define IaC using Java, Python, TypeScript, C#, Go, with support for more languages coming in the future.

 

Open-source. cdktf is an open-source project. If you require a new/existing feature for the CDK for Terraform, You can review existing GitHub issues and upvote. Additionally, you can request new features by opening a new git issue. In addition to opening issues, you can contribute to the project by opening a pull request.

 

 

The CDK for Terraform project is in Beta. cdktf is still in active development, and thus you should use it with care and at your discretion.

What is the ideal Usage for CDK FOR Terraform?

You should examine whether to use CDKTF when:

 

  1. You want Developers to have the flexibility of writing infrastructure code in a programming language they’re familiar with instead of DevOps guys writing in a completely unfamiliar HCL language that needs additional training.
  2. You need to manage infrastructure complexities using abstractions, to create infrastructure constructs and resources to model a reusable infrastructure pattern formed of many resources and provider libraries.
  3. You prefer a procedural/OOP language to define your infrastructure instead of using HCL or Yaml based templates. 
  4. You want the autocompletion and other features that most IDES provide. 
  5. You want the strictness of a compiled language to write your Infrastructure code.