Over engineering a badly thought out terraform data provider

All the well managed AWS accounts I have access to include some form of security group control over which IP addresses can connect to them. I have a home broadband connection that provides a dynamic IP address. These two things do not play well together.

Every now and again my commands will annoyingly fail with ‘access denied’. I’ll run a curl icanhazip.org, raise a new PR against the isolated bootstrap project that controls my access, get it reviewed and after running terraform, restore my access. This process has to be improvable right? I know, more code will fix it!

As an experiment in writing a custom data provider for Terraform, the real reason I did any of this, I decided to try and remove the IP address from the code base completely and instead make it a run time determined value. The, never to be merged, Icanhazip data source pull request that implements this is still available and shows how to add a simple data source to terraform. Becoming a little more familiar with the code base, and how to test it properly, thanks to Richard Clamp of the Terraform GitLab provider for lots of pointers on testing, were worth the time invested even with the rejected PR.

Was this data provider a good idea? No, not really. The HTTP data source solution proposed by Martin Atkins is a much better approach and requires no changes to terraform itself. The code is easy to follow:

# main.tf

# use the swiss army knife http data source to get your IP
data "http" "my_local_ip" {
    url = "https://ipv4.icanhazip.com"
}

# write it to a local file to prove everything's fine
resource "local_file" "my_ip" {
    content  = "${chomp(data.http.my_local_ip.body)}"
    filename = "/tmp/my_ip"
}

and it does exactly what my pile of Golang does -

$ terraform apply
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ cat /tmp/my_ip
312.533.143.224

The more time that passes since this little experiment, the more I think the whole idea was a terrible one. My use case, bootstrapping AWS access with security groups, is at best a very niche one. It assumes your bootstrap tool isn’t restricted and only works if everyone executes terraform from the same location. Was it a complete waste of time? Not really. I learned a lot about how data sources work and how I’d implement a sensible one in the future. I also know the Terraform PR reviewers are quick, courteous and good at spotting well meaning mistakes, which as a user of the tool itself is quite reassuring.