Incremental Adoption of Terraform

How to use Terraform without rewriting everything

In any organization of a sufficiently large size, the path to new technology adoption must include incremental use of that technology. Whether it be a new front end framework, or a new orchestration technology. It is very difficult to advocate for a technology when step 1 is “Get rid of everything that you currently have”. Unless you are small and can do that (looking at you 🦄 startups).

Big companies doing big things

Terraform is a great tech that you can bring in slowly and have a meaningful impact in day 1. It is a tool that can help organizations manage and control their IT infrastructure as code, rather than as a set of snowflake changes made through a web console.

Using with existing infrastructure involves understanding four key concepts.

1. The difference between remote and local state
2. How to switch between them
3. The data keyword,
4. The import command.

Remote State

Remote State lives in “the cloud”. That can be an S3 bucket, azure, or just a rest api. Its a giant json object that is a mirror image of your infrastructure. Local state is that same file, just saved onto your hard drive where only you can see it.

If you don’t have a backend configured with terraform then this section doesn't apply to you. If you are working on a team who does, one of the most import things you want is the ability to change your tfstate without affecting other peoples commands. If you have a remote backend than any change you make affects that remote file that others are using.

To limit this, simply comment out the code in your backend statement, run a terraform init again and terraform will copy from remote, to local. Now you are free to change that file as much as you want, without affecting other developers.

Data vs Import

Understanding the data keyword can help make things easier as well. Using data allows you to reference a resource in terraform without controlling that resource. Sometimes you might have a vpc that a ton of other things are using and you still want people to make manual changes to it, you can bring it into your infrastructure and use it as you would any other terraform resource

The import keyword is the next level up. When you import a resource you are telling terraform, “Hey I don’t only want to access the resource, I want to fully control it”. Terraforms import command has two parts: what you want that resource to be called locally, and the remote id that the resource points too. Be aware, not all resources can be imported, a full list is available here. The command is simple after that, if you wanted to import an ec2 instance and refer to it as web locally: terraform import aws_instance.web i-3456a . Terraform will then prompt with the resource statement that must be added locally. Bring that statement into your file, import again and things should work. Be aware importing one resource sometimes requires the importation of separate resources. Example: importing an aws security_group will import multiple security_group_rules .

All that’s left now is running a terraform plan, looking at the output and adjusting your configuration until it matches what is in the remote state. You’ll know you’ve got everything set when terraform plan returns nothing.

Interested in working with terraform and other devops technologies? Reach out via SO and apply https://stackoverflow.com/jobs/companies/oddball