Terraform’s aws_key_pair resource requires an existing user-supplied key pair- it won’t create one for you. At first glance it would seem that leveraging this would require us to pre-generate a key pair outside of Terraform’s lifecycle, but we can do this natively with a bit of creative resource management.
Recently I’ve been exploring Consul’s Events mechanism as a way to propagate broadcast data across our infrastructure. It’s a useful pipeline, given our existing use of Consul- message systems like NATS or similar might be a more purpose-built solution, but being able to leverage existing infrastructure and code lets us deploy new solutions quickly and cheaply.
Until (somewhat) recently, Nginx development was somewhat of an adventurous journey. Official documentation was largely nonexistent; Evan Miller’s decade-old guide was the often-referenced canonical source of material. Publication of an authoritative development guide came only a few years ago, significantly lowering the bar to entry for third party developers. It’s an excellent source of material, but it doesn’t cover every aspect of authoring and extending Nginx, meaning that complex or uncommon features still require a bit of blog browsing, copypasta, and diving into the Nginx source to figure out what’s going on.
Module feature testing is one of these aspects. Writing simple Nginx modules is straightforward, but discussion of module config files is often glossed over or ignored entirely. The canonical development guide does a reasonable job of touching on some of the functionality and definitions available to config files, but it’s short on examples, and it ignores a crucial aspect of developing complex modules or integrations with third party libraries: feature testing.