Terraform Weekly - Issue #3

April 16, 2020

Welcome to issue 3 of this experiment. I continue to play with the format and content but am starting to feel things come together into a model that makes sense. Either reply to this mail or email me at [email protected] with any feedback.

If you like what you see here, please forward to others who would be interested.

Poka-yoke is a Japanese term that means ‘mistake-proofing’ or ‘inadvertent error prevention’.

With power comes some danger. Here, Sven Hans Knecth from Capital One covers a number of techniques that his team uses to provide safe Terraform operations .

HERE'S THE THING: They are all reasonable, but I wonder about the trade off for rule 2 -

Rule 2: Use Terraform Data calls to provide information

One challenge with using data sources for connecting components of Terraform is ending up with unexpected changes in your operations. If you define a resource in component A and use in in component B via a data source, then you might run into a situation where you are doing unrelated work in component B but have to apply a change cascading from component A. There's not a good universal solution for this. Instead, use terraform_remote_state. Coupling that with something like Terraform Cloud/Enterprise run triggers reduces unplanned changes.

Terraform 0.12.20 introduced two new features - try() and can().

The can() function is part of an experimental new input validation feature and try() is supposed to be used for error handling (but everyone's going to abuse it for a bunch of other things.)

HERE'S THE THING: Terraform is a wonderful tool that has a huge weakness when it comes to affordances for quick developer feedback. Validations? Deprecation warnings? Logging?

These are great improvements that make it easier to engineer more reliable infrastructure management code. I am looking forward to seeing more improvements like these.

Muffy Barcocy (a former coworker) writes about her experiences managing AWS RDS databases at Instacart.

The post covers some basics so if you are familiar with Terraform and RDS skip to the "Applying changes" section where she details the challenging impedance mismatch between with RDS and Terraform

HERE'S THE THING: The combination of Terraform's model where changes are expected to be be immediately visible and RDS apply_immediately=false does not work well together.

When you apply changes with apply_immediately=false it will be stored in AWS and applied during your next maintenance window. In the meantime the AWS API will return the previous settings and it will appear like you have unapplied changes. Not a good situation if you like to keep your state clean.

The solution is not perfect, but it is usually better to apply the changes immediately even if that means scheduling when you merge your code.

Releases

An un-ordered list of releases in the ecosystem (plugins, testing libraries, etc)…