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.
Electron owns way too much of my disk. It’s time to move on.
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.