GCE managed group instances' IPs as output

[jgoclawski]

Hi there,

Terraform Version

Terraform v0.11.3

• provider.google v1.6.0

Affected Resource(s)

• google_compute_region_instance_group_manager
• google_compute_instance

Terraform Configuration Files

resource "google_compute_region_instance_group_manager" "default" {
  name               = "${var.name_prefix}-instance-group"
  base_instance_name = "${var.name_prefix}"
  instance_template  = "${google_compute_instance_template.default.self_link}"
  region             = "${var.region}"
  target_pools       = ["${google_compute_target_pool.default.self_link}"]
  target_size        = "${var.instance_count}"
}

Expected Behavior

I would like to be able to discover managed instances IPs via Terraform and expose them as an output.
Use case:
Step 1 - create managed instances with Terraform
Step 2 - run code deploy on them, using Jenkins. Jenkins gets IPs from Terraform's output and uses SSH to connect with them.

Another use case:
Step 1 - create managed instances with Terraform
Step 2 - add instances' IPs to "authorized_networks" on "google_sql_database_instance" resource.

Right now in step 2, we're using gcloud command to discover IPs.

Something like this is possible with AWS, using "aws_instance" data source or "aws_instances" data source.
For GCP, there is no "google_compute_instance" data source. There is however "google_compute_region_instance_group" data source, but it doesn't expose IPs as an attribute.

[paddycarver]

So, good news and bad news.

Good news: this should be possible when #1906 lands. Use the instance_group field of the regional instance group manager to get the self_link for the instance group. Then use the instance_group data source to get a list of self_links for the instances in that instance group. Then use the instance data source introduced in #1906 to get the IP for each. It's annoying, but it's possible.

Bad news: it still won't do what you want. Because managed instance groups are, well, managed, the instances in them are not static. They change over time. This could be from things like autoscaling, it could be from things like an instance getting deleted, it could be from a lot of things. But because the group is managed by Google, not by Terraform, you can't rely on the instances in it remaining static between Terraform runs. This brings a lot of nice benefits! It's a good thing. However, it does mean that Terraform can't be relied upon to do the things you outline in your use cases.

Use case:
Step 1 - create managed instances with Terraform
Step 2 - run code deploy on them, using Jenkins. Jenkins gets IPs from Terraform's output and uses SSH to connect with them.

When a new instance comes up, it will not have the code deployed on it, because Terraform doesn't run continuously. So Terraform won't know about it until the next Terraform apply, meaning Jenkins can't deploy the code over SSH until the next apply. At which point, there's no point in using managed instances groups, just use a regular instance group. If you need to deploy code over SSH, a managed instance group is almost certainly not what you want. Managed instance groups should only rely on instance templates to be ready for use.

Another use case:
Step 1 - create managed instances with Terraform
Step 2 - add instances' IPs to "authorized_networks" on "google_sql_database_instance" resource.

When an instance gets recreated, for whatever reason, you now have an IP that isn't associated with an instance that has access to your database, and you have an instance that doesn't have access to your database. You probably want to use the CloudSQL proxy.

But, as noted in the GCP docs (emphasis mine):

Because of the stateless nature of managed instance groups, you should design or retrofit your application so that it does not depend on specific instance properties that will not persist, such as an IP address or in-memory data.

[paddycarver]

I'm going to close this out, as we've released the compute instance data source, so people should be able to string this together by themselves, if they really want to. I'm weakly against adding documentation/an example on how to do it, because I think it's behaviour that should be discouraged. If anyone feels strongly it should be documented, feel free to chime in, and we can reopen the issue.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!