Terraform

Infrastructure repositories tend to want an exact version of tools. It’s desirable that when I work on Terraform code on my laptop, I use the same version as will be used in production, and the same version that my colleagues use. While I like to use Nix Flakes for per-project development environments, nixpkgs is not much help here. It carries a single version of each of these tools — whichever one happened to be current when the package was last bumped — and it builds them from source. Both of those are the right defaults for a distribution and the wrong ones for pinning a team to terraform 1.9.8 specifically, verified against the checksum HashiCorp published for it.

At CfgMgmtCamp 2020, I gave a talk entitled “Terraform Without The Mess”, in which we looked at how the history of features in Terraform affect the way we structure and write our Terraform configuration today, and make opinionated recommendations about how to structure modern Terraform code in a way which makes changes simple, predictable and safe.

IAM Policy Documents are ubiquitous in AWS - they are used not only for standalone policies you might attach to users or roles, but also for S3 bucket policies, SNS topic policies and more. Unfortunately, the JSON syntax can be error prone to hand write, and the default mechanism for creating policies in many configuration management tools is template rendering.

One of the easiest ways of building resilience into a system running in AWS is to use an autoscaling group. Generally speaking, I use one for any service which is required to self-heal - even when aiming to maintain a steady number of instances, as is desirable when running servers for Consul and Nomad, as well as a whole host of other clustered systems. Unhealthy instances can simply be replaced, usually without operator intervention, and launch configurations can be used to simplify upgrading clustered software one instance at a time.