Losing my Terraform Religion
I’ve been doing Terraform since 2015, the first year of its existence. It was incredibly neat and powerful and absolutely nobody had heard of it. The number of Terraform resources have exploded, and I think you can probably program your toaster with it today. In my current project, the team and I decided to use Crossplane instead of native Terraform, due to some limitations where community Terraform has not evolved and has been surpassed by other ideas.
Running a Terraform project requires a Trinity (or more) of datapoints in order to run and maintain terraform deployed infrastructure. If you loose any of these three, you are in for more work and you might consider deleting the infrastructure and re-deploying from scratch:
Trinity Item 1 — The Terraform Code. It may seem like a trivial task to keep track of your code, but at any scale it becomes a problem remembering where the code is that you used to deploy that thing from 3 months ago. If you Uni-Repo then what folder and what branch did you use to deploy it. Did you deploy off of a feature branch and it got deleted? If you multi-repo then you have to remember what git repo this came out of.
Trinity Item 2 — The State File. So lets take a typical setup, you have a storage container (s3, azure storage) for your terraforms, and then for organization you created some sub folders. say “infra/base/networking/sandbox/mything1.tfstate”. In order for this state file to be useful, you have to know exactly what code version created it. I have seen whole infrastructures disappear because the state for “Sandbox” was used with the rest of the settings (TFVars) set to ‘Develop’.
Trinity Item 3 — The Terraform binary version. Although some improvements have been made, the version of the binary is stored and controls the format of the TFState. If your corporate standard is v0.12, and some yahoo runs your core infra with v0.13, then unless you go and restore your state file to previous version, your team and project now all needs to upgrade to v0.13
Trinity Item 4 — The ‘pipeline’ that ran it. Assuming that you run your terraforms in a pipeline you need to keep track of what pipeline (and what parameters you used) to create a specific set of infra. Normally the ‘pipeline’ is where you corral and co-ordinate the other trinity items. But if you are looking at a VM and trying to figure out what pipeline created it, you better have tagged the VM or you may have a hard time tracing deployed infra back to the pipeline that created it.
Trinity Item 5 — The TFVars file. A common setup is to have ‘sandbox.tfvars’ , ‘develop.tfvars’. Usually these are stored side-by-side in the git repo with the terraform code, and you just need to make sure that your TFVars file and your State File are the same and in agreement.
Solution 1 — Terraform Enterprise
There are two solutions that come to mind. All of my above rant can be solved with Terraform Enterprise and their concept of workspaces. When you get tired of the above, check it out. The team at HashiCorp are smart and know these pain points. Unfortunately most people that are Terraforming have cut their teeth on using it in Azure Devops, or Jenkins or the CI/CD server that is their workhorse for everything. So other than personal use, I haven’t been able to use Terraform Enterprise.
Solution 2 — Crossplane
Assuming you have some exposure to Kubernetes, wouldn’t it be nice if you could just “terraform apply -f my-infrastructure.yaml’. In our current project we are hoping that Crossplane will ease this pain and get us back to having fun defining Infrastructure in a declarative language.