Terraform CDK

Another way to think about CDAutomation

In last few months we are assigned the task to create some standards around CD. We had a few things to consider as one can not do the automated CD without the underlying infra. We were tasked to onboard a new micro-service in Dev/QA environment with pre-requisites and eventually get deployed to EKS cluster. This process should be ergonomic in Dev, while promotable to higher environments. Another motivation was to write something for Google-Cloud as currently there is no official getting started guide in terraform website.

Requirements

1. Ergonomic design for Dev/QA environments
2. Repeatable and promotable process
3. Reduce documentation, rather keep the documentation relevant with time
4. Handle both, provisioning and deployment
5. Do not re-invent the wheel: Just don’t(Integrate with existing systems)
6. Establish some developer centric process to expedite the onboarding(Preferred: GitOps or Developer Portal)

Our first objective was to break up the process into multiple steps which can be automated and integrated. Given this, I shall take some time to summarise the older process.

Older Process of onboarding

1. Dev team shall propose a new idea and scope of a Micoservice
2. They shall prepare a architecture diagram, design diagram for this proposal
3. Once approve, they shall create a Microservice integration page for the service, this should include the following

a. Define the access required to GCP services

b. Resource requirement for the service (CPU, Memory, Disk, etc…)

c. Observation information like, expected Latency, Error rate, Saturation, etc…

d. Security requirements and exposure to risk(TODO: Still not clear how this should be automated)….. Probable options as terraform sentinel

Approach

In order to solve the first set of the problem, we went with an approach of dev centric GitOps workflow. Here, Dev’s can define the resources that they need and code can provision it for them. This however, has to be approved by the SRE/CloudOps team to ensure no security laps are introduced. To enumerate this lets follow the steps below:

1. Out initial approach was to first create policies using this new tool. This is most undestructive way while it provides some confidence
2. We created a repo to manage some common resources like, IAM role, polices, EKS, SQS, etc…
3. Now the developers can refer them in yaml file where they define all the resources and policies required by any given Microservice
4. We selected tf-cdk in place of terraform as we wanted to avoid a lot of processing in tf-locals. While learning a language could be a task, we had some experts in typescripts.
5. Using a language is beneficial as it provides better means to validate yaml file , typecasting , clear conditions and loops

Terraform-CDK https://www.terraform.io/cdktf

Terraform CDK is extremely useful if we need to do some pre-processing for the resources. YAML processing is a very interesting use case for the same. One can create the Interface(Class) to contain the object definitions for the yaml file and typecast that to the interface. One can read more about the terraform-cdk from the terraform official page i.e. https://www.terraform.io/cdktf.

Pre-processing benefits :

1. Process Yaml file as language specifics
2. Write typecast and object validation
3. Process the file as an object , not like a map as one has to do in standard tf code

Let’s write some code

I have written some code in Github that should be made public soon. I am going to explain the idea here, preprocessing, interface mapping and then creating the terraform objects.

Preprocessing

Let’s pick an example of the yaml file that developers/operators shall supply, I have made an example file that is processed,

project.yaml

test.yaml file

This will be our yaml file that we can process. Let me illustrate the pre-processing code.

preprocessing.yaml

Processing

Here, we just need to process the object i.e. projectInfo. This object shall encapsulate the gcpObjects within. Makes the processing extremely dev friendly.