Vermyndax vermyndax

Why does this work:

private_ipv4_google_access = "true"

…but this doesn’t:

private_ipv6_google_access = "true"

This anomaly comes to you courtesy of Google’s “google_compute_subnetwork” Terraform resource. A gander at the documentation says this:

Ok. What are the acceptable inputs there? The examples in the documentation provide exactly zero guidance. You either have to go look at the Go code for the resource or do a lot of trial and error. The trial and error is especially fun because they didn’t put any checking around that field whatsoever. It would happily accept “true” but then set it to “DISABLE_GOOGLE_ACCESS” after your Terraform runs. Then on your next apply, you’d see this:

resource "google_api_gateway_api" "api_gw" {
  provider = google-beta
  api_id = "my-api"
}

resource "google_api_gateway_gateway" "api_gw" {
  provider = google-beta
  api_config = google_api_gateway_api_config.api_gw.id
  gateway_id = "my-gateway"
}

Am I the only person here that thinks this resource naming is absurd? I should be able to look at these resource names and immediately understand what is going on here. This is nothing but confusion.

I wish I could say this is the only example of this ridiculousness in the Google/Google-beta provider (speaking of, two providers? Really?) but it’s not.

I really love Terraform. It’s been driving my career advancements for the past 2-3 years. I’ve really enjoyed working with it. As such, I do try to create useful Terraform modules to give back to the community. Most of the module work I have done has been for my employer, but sometimes I make code that is more for myself. This is one such module.

Last night, we solved a long-standing bug in one of our Terraform modules. It’s been haunting us for a long time - damn near over a year. We managed to produce this bug in a CloudFormation stack as well, but we just couldn’t figure out where it was coming from.

For reference, we were trying to stand up an Elastic Container Service cluster with containers using dynamic port routing. When you do this, you build it with an Application Load Balancer (ALB) plus a target group. The way things are supposed to work is that when a container is spun up on the cluster, it chooses an ephemeral port and that port is registered to the target group’s health checks.

That was essentially working, but something was adding an additional and erroneous health check to the exposed port (https/443) which would cause the auto-scaling group to think things were amiss… and continously terminate/rebuild instances. Not a fun situation. Our workaround was to manually remove the health check. But each time the ASG terminated and added an instance, the bad health check would come back. We finally figured this mess out.

I just completed some work on a little project with some unique requirements. It’s a project that uses Terraform to provision infrastructure within AWS. That’s not too terribly hard. We’re trying to make the platform, infrastructure and code as reusable as possible while maintaining customer-specific privacy and security requirements.