12 Jan 2025 - rich
It started with a discussion about testing, why it is important, and it ended up as an article. Testing Terraform code is important as it insures a level of compliance and an adherence to team, group, or enterprise best practices and cost constraints. But testing methodologies vary. They can be inconsistently followed, or worse, inconsistently applied. As with everything else, there needs to be a methodology and a guarantee that all are actually doing this. And doing it well.
The issue, I believe, is that the testing comes last. Perhaps more about personalities but you either write all your code first, plan it, test it, and then run your tests… or vary the pipeline so that you write it, plan it, test it as you move along with the coding and project process.
There are tools that you pay for that include testing. Terragrunt for example. The paid version. The expensive version. You build your infrastructure and you use the terragrunt modules. The modules include testing.
I want to deploy an EC2 instance in an account in my environment.
The request is quite simple. “Just build an EC2 to do that…”. The implementation is not difficult - pick an instance type, pick an os/ami, determine the security groups you’ll need to use (do they already exist or will you need other ports opened?).
Depending on the flavor (Kali, Ubuntu, AL2024, AL2, RedHat/Fedora/Centos/Rocky/Alma… ) what package repositories, etc…
Can I buld this from or like an existing instance? Oh, what about VPCs and subnets?
What about ssh keys, IAM roles, instance profiles, permissions, users, groups, and roles…
Once you have all the answers to all the questions… you just implement it… it is simple (really) and straightforward.
The request was for a single EC2 instance. What if this was for a cluster? What if Kafka or a service mesh needs to be implemented. What if this involves Outpost, on-prem, and on-cloud… Also, how do you insure best practices for security and auditing? What about compliance?
It would be nice to just build the damned thing. Maybe not push a button, but something close to that. Depending on the environment, the availability zone, the region, whether it is test or QA, or development, or production… build me my ec2!
Most of these can be defined in configuration files… and similar to a system of cascading and hierarchical configuraton that allow for override along the way, much of this can be deposited into config files and strewn about similar to, but hopefully easier to maintain that say a terragrunt with its parent keywords…
In essence, saying, “build me an EC2” when you are standing in a development environment will produce a different result than saying, for example, “build me an EC2” when you are building out a compliance or QA environment. All those questions? The answers can be found in the configs.
And, in true programmatic fasion, these values should be, and can be easily overridden with more words. “build me the latest ubuntu ec2 instance in development on a t3-large instance but allow port 4000 for the jekyll server accessible only from the 10.10.0.0 subnet” What is not mentioned is implied. The subnet - private or public, EIP use for the public interface, etc…
In the early stages of the project, it should be possible to simulate the language, and implement many of the early, basic builds using go/python/bash… once the concepts have been proven the next steps would involve building the scanner and parser for the LALR language and feeding rules into LEX, YACC, and BISON.