terraform-google-modules / terraform-google-vm

Provisions VMs in Google Cloud

terraform-google-vm

This is a collection of opinionated submodules that can be used as building blocks to provision VMs in GCP:

• Instance template
• Managed instance group
• Unmanaged instance group

Compatibility

This module is meant for use with Terraform 0.13+ and tested using Terraform 1.0+. If you find incompatibilities using Terraform >=0.13, please open an issue. If you haven't upgraded and need a Terraform 0.12.x-compatible version of this module, the last released version intended for Terraform 0.12.x is v5.1.0.

Examples

Examples of how to use these modules can be found in the examples folder.

Project APIs

The following APIs must be enabled on your project:

• compute.googleapis.com
• iam.googleapis.com

See also the project_services module (optional).

Notes

distribution_policy_zones cannot be changed during use. If you have changed them yourself or used to have a default value, then you'll have to force recreate a MIG group yourself.

Tests

For running the integration test cases, please refer to the CONTRIBUTING documentation.

Permissions

The service account used to execute tests for this module should have the following roles:

• roles/compute.admin
• roles/iam.serviceAccountUser

terraform-google-vm's Issues

Documentation tags are incompatible with terraform_docs.sh

The documentation tags were not updated during the Terraform 0.12 upgrade.

Randomize the name arguments of resources in modules invoked by CI

The name arguments of multiple resources are hard-coded which prevents multiple CI jobs from running in parallel due to name collisions. These name arguments should include a random element, like a random_pet_name, to ensure uniqueness.

Unexpected behavior when creating instance_template without public ip

I created an instance template with those inputs

inputs = {
  name = local.name
  network = dependency.vpc.outputs.network
  subnetwork = dependency.vpc.outputs.public_subnetwork
  tags = ["allow-vpn", "allow-monitor", "allow-proxy"]
  source_image_family = "centos-7"
  machine_type = "n1-standard-1"
  can_ip_forward = "true"
  # Boot disk size
  disk_size_gb = "50"

  additional_disks = [
    {
      auto_delete = false
      boot = false
      disk_size_gb = 20
      disk_type = "pd-standard"
    }
  ]
  service_account = {
    email = ""
    scopes = ["userinfo-email", "compute-ro", "storage-ro"]
  }
}

And I use mig module in order to launch instance.
It's run fine and create instance successfully. However, I could only ping one of those instance (I launch 2 instance from mig config) with internal ip.

Some my test case that work normal except above config:

• Point my mig config to manual instance template.
• Launch instance-template with public-ip

It's so weird.

My mig inputs

inputs = {
  target_size = 2
  hostname = local.name
  # instance_template = dependency.instance-template.outputs.self_link

  # Use template created from console temporary
  instance_template = "template name"

  health_check = {
    type                = "tcp"
    initial_delay_sec   = 30
    check_interval_sec  = 3
    healthy_threshold   = 4
    timeout_sec         = 3
    unhealthy_threshold = 5
    response            = ""
    proxy_header        = "NONE"
    port                = 3128
    port_name           = "squid"
    request             = ""
    request_path        = "/"
    host                = ""
  }
}

MIG Module - Empty Autohealing policy requires a terraform apply on each invocation

In the mig module, it defaults to creating an autohealing policy because the initial delay seconds will default to 0 when you do not pass in any value (module main.tf). Every time you run a plan, terraform tries to change add the policy to the mig.

compute_disk_snapshot Weekly Schedule Detects Drift on Every Plan/Apply

Terraform Version

0.13.5
Tested with 0.13.6 and 0.14.8

Terraform Configuration Files

module "disk_snapshots" {
  source  = "../../../modules/compute_disk_snapshot"
  name    = "backup-policy-test"
  project = var.project_id
  region  = var.region

  snapshot_retention_policy = {
    max_retention_days    = 10
    on_source_disk_delete = "KEEP_AUTO_SNAPSHOTS"
  }

  snapshot_schedule = {
    daily_schedule = null
    hourly_schedule = null
    weekly_schedule = {
      day_of_weeks =  [{
        start_time   = "23:00"
        day          = "SATURDAY"
    }]
  }
  }

  snapshot_properties = {
    guest_flush       = true
    storage_locations = ["US"]
    labels            = null
  }

  module_depends_on = []
  disks             = var.instance_disk
}

Expected Behavior

Terraform should deploy the snapshot schedule and attach to disks declared in the variable - which it does. On subsequent terraform apply commands there should be no drift detected and the snapshot schedule policy and attachments should not prevent the apply from completing.

Unexpected Behavior

When deployed with appropriate variables the weekly snapshot schedule is successfully deployed; however, the next Terraform apply or plan detects a drift in the snapshot schedule like:

resource "google_compute_resource_policy" "snapshot_policy" {
      ~ id        = "projects/##PROJECT_ID##/regions/us-east4/resourcePolicies/ssms-instance-dev-cb-snapshot" -> (known after apply)
        name      = "ssms-instance-dev-cb-snapshot"
        project   = "##PROJECT_ID"
        region    = "https://www.googleapis.com/compute/v1/projects/##PROJECT_ID##/regions/us-east4"
      ~ self_link = "https://www.googleapis.com/compute/v1/projects/##PROJECT_ID##/regions/us-east4/resourcePolicies/ssms-instance-dev-cb-snapshot" -> (known after apply)

      ~ snapshot_schedule_policy {
            retention_policy {
                max_retention_days    = 10
                on_source_disk_delete = "KEEP_AUTO_SNAPSHOTS"
            }

          ~ schedule {

              ~ weekly_schedule {
                  - day_of_weeks { # forces replacement
                      - day        = "SATURDAY" -> null
                      - start_time = "23:00" -> null
                    }
                  + day_of_weeks { # forces replacement
                      + day        = "SATURDAY"
                      + start_time = "23:00"
                    }
                }
            }

            snapshot_properties {
                guest_flush       = true
                labels            = null
                storage_locations = [
                    "us",
                ]
            }
        }
    }

If running an apply, the snapshot schedule tries to edit the schedule but errors out:

Error: Error when reading or editing ResourcePolicy: googleapi: Error 400: The resource_policy resource 'projects/##PROJECT_ID##6/regions/us-east4/resourcePolicies/ssms-instance-dev-cb-snapshot' is already being used by 'projects/##PROJECT_ID##/zones/us-east4-b/disks/ssms-instance-dev-cb', resourceInUseByAnotherResource

Steps to recreate

1. Deploy a snapshot schedule using the module and terraform apply
2. Without editing terraform code run another terraform apply

Getting exception: use google beta provider for MIG module

Error: module.mig.google_compute_instance_group_manager.default: "auto_healing_policies": [REMOVED] This field is in beta. Use it in the the google-beta provider instead. See https://terraform.io/docs/providers/google/provider_versions.html for more details.

Error reading instance template

I'm running into an error when running a second apply: the instance template name doesn't match a regex that seems to assume the name should be between 0 and 19 characters.

Since there is a string containing the date appended to the name_prefix input, it's something that I cannot control.

The first apply works fine (creation), but the second apply fails (read):

Error: Error reading Instance Template "squid-europe-west1-20191125171408399700000001": googleapi: Error 400: Invalid value 'projects/rnm-hostedsvcs-comsvcs-sq7051/global/instanceTemplates/squid-europe-west1-20191125171408399700000001'. Values must match the following regular expression: '[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?|[1-9][0-9]{0,19}', invalidParameter

Error: Error reading Instance Template "squid-europe-west4-20191125171408472600000002": googleapi: Error 400: Invalid value 'projects/rnm-hostedsvcs-comsvcs-sq7051/global/instanceTemplates/squid-europe-west4-20191125171408472600000002'. Values must match the following regular expression: '[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?|[1-9][0-9]{0,19}', invalidParameter

Support terraform 0.13 in all submodules

Currently only the umig module supports 0.13. We should support 0.13 in all submodules as well

unsupported block type error

Trying to add this to my code, I get the following during terraform init

terraform init
Initializing modules...
Downloading terraform-google-modules/vm/google 6.0.0 for vm_instance_template...
- vm_instance_template in .terraform/modules/vm_instance_template/modules/instance_template
There are some problems with the configuration, described below.

The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.

Error: Unsupported block type

  on .terraform/modules/vm_instance_template/modules/instance_template/versions.tf line 22, in terraform:
  22:   provider_meta "google" {

Blocks of type "provider_meta" are not expected here.

terraform versions:

terraform --version
Terraform v0.12.29
+ provider.external v1.2.0
+ provider.google v3.39.0
+ provider.google-beta v3.39.0
+ provider.kubernetes v1.13.2
+ provider.null v2.1.2
+ provider.random v2.3.0

instance template module: attempt to use `subnetwork_project` variabe fails with API error for not supported cross-project reference

There is some issue with implementation of subnetwork_project as cross-project reference fails with following error:

~/workspace/google/terraform-google-lb-http/examples/shared-vpc]$ terraform apply -auto-approve
module.cloud-nat.random_string.name_suffix: Refreshing state... [id=t24x9w]
data.template_file.group-startup-script: Refreshing state...
module.gce-lb-http.google_compute_firewall.default-hc[0]: Refreshing state... [id=group-http-lb-hc-0]
module.gce-lb-http.google_compute_http_health_check.default[0]: Refreshing state... [id=group-http-lb-backend-0]
module.gce-lb-http.google_compute_global_address.default: Refreshing state... [id=group-http-lb-address]
google_compute_network.default: Refreshing state... [id=shared-vpc-lb-http]
module.mig.data.google_compute_zones.available: Refreshing state...
module.mig_template.data.google_compute_image.image_family: Refreshing state...
module.mig_template.data.google_compute_image.image: Refreshing state...
google_compute_router.default: Refreshing state... [id=us-central1/lb-http-router]
google_compute_subnetwork.default: Refreshing state... [id=us-central1/shared-vpc-lb-http]
module.cloud-nat.google_compute_router_nat.main: Refreshing state... [id=us-central1/lb-http-router/cloud-nat-lb-http-router]
module.mig_template.google_compute_instance_template.tpl: Creating...

Error: Error creating instance template: googleapi: Error 400: Invalid value for field 'resource.properties.networkInterfaces[0].subnetwork': 'projects/gl-ik-shared/regions/us-central1/subnetworks/shared-vpc-lb-http'. Cross-project references for this resource are not allowed., invalid

  on .terraform/modules/mig_template/terraform-google-modules-terraform-google-vm-cb3d6cc/modules/instance_template/main.tf line 51, in resource "google_compute_instance_template" "tpl":
  51: resource "google_compute_instance_template" "tpl" {

FR: make fields of health_check optional

Currently all fields of mig.healthcheck is mandatory so one has to write a config below:

module "mig" {
  source                  = "terraform-google-modules/vm/google//modules/mig"
  version                 = "1.3.0"
  ...
  health_check = {
    type                = "http"
    initial_delay_sec   = 30
    check_interval_sec  = 5
    timeout_sec         = 5
    healthy_threshold   = 1
    unhealthy_threshold = 5
    response            = ""
    proxy_header        = "NONE"
    port                = 80
    request             = ""
    request_path        = "/"
    host                = ""
  }
}

It's quite verbose compared to plain google_compute_health_check which will be like

resource "google_compute_health_check" "my-service-http-health" {
  provider = google-beta
  name     = "my-service-http-health"

  initial_delay_sec   = 30
  check_interval_sec  = 5
  timeout_sec         = 5
  healthy_threshold   = 1
  unhealthy_threshold = 5

  http_health_check {
    port         = var.image_port
    request_path = "/healthz"
  }
}

It would be great if modules/mig can set sane default and make params optional

compute_instance module only works if project_id is configured at the provider level

Data source:

data "google_compute_zones" "available" {
}

in submodule modules/compute_instance/main.tf does not take the project id as parameter. Which leads to the following error when using this module in a configuration where the project id is not configured at the provider level:

Error: project: required field is not set

  on .terraform/modules/compute_instance/terraform-google-modules-terraform-google-vm-a8795e3/modules/compute_instance/main.tf line 31, in data "google_compute_zones" "available":
  31: data "google_compute_zones" "available" {

The project ID needs to be exposed as an optional variable in the module as it is the case in other submodules (mig, instance_template).

Replace implicit dependency on provider project ID with project_id variable

feature(mig): support wait_for_instances

The google_compute_region_instance_group_manager resource takes an optional argument wait_for_instances that would be useful to pass for things like cascading updates.

Instance templates do not in their current form allow creation of scratch disks

Instance templates do not in their current form allow creation of scratch disks. The missing parameters mean that you end up defaulting to incompatible flags when you try to setup NVME, etc... I've submitted a PR (#75 ) that attempts to alleviate that problem by adding in the missing parameters.

Add new outputs from instance template

terraform-google-lb uses target-tags to configure a load balancer with an managed instance group. we should output target-tagsfrom the instance template module to make a more straightforward integration.

In "mig_with_percent" module, add variable "project" in "google_compute_zones" data source

The data source:

data "google_compute_zones" "available" {
  region = var.region
}

should be:

data "google_compute_zones" "available" {
  region  = var.region
  project = var.project_id
}

Since it should derive the project ID from other resources and not provider.
Somewhat similar to #60

Add autogen templates to reduce duplicate code

As morgante mentioned it in #19, mig and mig-with-percent share the most code. To avoid the one side change, I also think we need to add the checkscript not to forget the change shared codes between mig and mig-with-percent.

Update testing to new approach

We should update the testing to use Cloud Build and a new Service Account per run, as documented here.

Purpose/why for preemptible_and_regular_instance_templates module

A five minute click around and read of the docs suggests that preemptible_and_regular_instance_templates module exists because the normal instance_template module can be only preemptible or regular, but not both.

Is this correct? I would suggest it's worth adding "why would I use this" to all the modules README very close to the top 😄

compute vm module example to simple link results in 404

https://github.com/terraform-google-modules/terraform-google-vm/blob/master/modules/compute_instance/examples/compute_instance/simple will result in github 404

Same content on terraform registry 404 error...
https://registry.terraform.io/modules/terraform-google-modules/vm/google/3.0.0/submodules/examples/compute_instance/simple

Also, for unmanaged IG the example link is also 404.
https://github.com/terraform-google-modules/terraform-google-vm/blob/master/modules/umig/examples/umig/simple

workaround

This links seems to be the one that should be used and works...
compute instance...
https://github.com/terraform-google-modules/terraform-google-vm/tree/master/examples/compute_instance/simple

umig...
https://github.com/terraform-google-modules/terraform-google-vm/tree/master/examples/umig/simple

Default value for `hc_port` is incorrect attribute value type

hc_port variable (MIG submodule) has an empty string as default value, but this should be a number. If it is unset, it fails with:

Error: Incorrect attribute value type

  on .terraform/modules/squid-mig/terraform-google-modules-terraform-google-vm-59ea1a0/modules/mig/main.tf line 143, in resource "google_compute_health_check" "tcp_healthcheck"
:
 143:     port = var.hc_port

Inappropriate value for attribute "port": a number is required.

Maybe we could default to port 80 or null ?

Add instance labels to disk

Hi there !

We face an issue with our cost allocation on GCP.

Here the bug.
https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_instance#boot_disk

When we create an instance on GCE with Terrraform, the disk doesn't get the labels that we give to the instance. There is no "labels" option in the "boot_disk" section.
To get that you must create a seperate disk, add labels on it, and attach it to the instance.

But not everybody want to deal with the disk management. If we need a simple instance, we are just calling the google_compute_instance resource.

Is there a way to add the same labels that you give to your instance to the disk during the deployment ? Or can it be add to the provider/resource ?

Why I asking this ? Because in the billing section of Google, when you sort by labels on Compute service, I can't see the cost of my drive. If my instance have a label "application=mariadb" the disk doesn't have it. We see this:
[Charges for other usage]

Thanks for your help !

Support public IPs

Does this module support public IP ? We'd need an access_config block in the VM's network_interface for this to happen.
If we want to support both, I suggest looking at the Forseti VM code as it took me a while to figure it out.

Lint-tests fail, because of undeclared module in outputs

compute_instance module only works if region is configured at the provider level

Data source:

data "google_compute_zones" "available" {
}

in submodule modules/compute_instance/main.tf does not take the region as parameter. Which leads to the following error when using this module in a configuration where the region is not configured at the provider level:

Error: Invalid index

  on .terraform/modules/compute_instance/terraform-google-modules-terraform-google-vm-a8795e3/modules/compute_instance/main.tf line 42, in resource "google_compute_instance_from_template" "compute_instance":
  42:   zone     = data.google_compute_zones.available.names[count.index % length(data.google_compute_zones.available.names)]
    |----------------
    | count.index is 0
    | data.google_compute_zones.available.names is empty list of string

The given key does not identify an element in this collection value.

The region needs to be exposed as an optional variable in the module as it is the case in the mig submodule.

update_policy documentation seems incorrect

Per https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_region_instance_group_manager#rolling_update_policy , only minimal_action and type are required field for update_policy. However when I run terraform plan with following:

module "my_mig" {
  source            = "terraform-google-modules/vm/google//modules/mig"
  version           = "5.1.0"
  instance_template = module.my_module.self_link
  region            = var.region
  target_size       = var.instance_count
  update_policy = [{
    type            = "PROACTIVE"
    minimal_action  = "REPLACE"
    max_surge_fixed = 1 
  }]
  hostname          = "my_host"
  named_ports = [
    {
      name = "http",
      port = "80"
    }
  ]
  network = "default"
}

I got following error message:

The given value is not suitable for child module variable "update_policy"
defined at
.terraform/modules/my_module.my_mig/modules/mig/variables.tf:71,1-25:
element 0: attributes "instance_redistribution_type", "max_surge_percent",
"max_unavailable_fixed", "max_unavailable_percent", and "min_ready_sec" are
required.

Destroy: X is already in use by another resource

Running a terraform destroy on a set of ILB + MIG template + MIG results in multiple errors:

Error: Error deleting instance template: googleapi: Error 400: The instance_template resource 'projects/rnm-hostedsvcs-comsvcs-sq-7aea/global/instanceTemplates/rnm-squid-europe-west1-20191122182637629300000002' is already being used by 'projects/rnm-hostedsvcs-comsvcs-sq-7aea/regions/europe-west1/instanceGroupManagers/squid-europe-west1-mig', resourceInUseByAnotherResource

Error: Error deleting region instance group manager: googleapi: Error 400: The instance_group_manager resource 'projects/rnm-hostedsvcs-comsvcs-sq-7aea/regions/europe-west1/instanceGroupManagers/squid-europe-west1-mig' is already being used by 'projects/rnm-hostedsvcs-com-svcs-sq-7aea/regions/europe-west1/backendServices/squid-ilb-europe-west1',resourceInUseByAnotherResource

Error: Error reading HealthCheck: googleapi: Error 400: The health_check resource 'projects/rnm-hostedsvcs-comsvcs-sq-7aea/global/health
Checks/squid-europe-west1-tcp-healthcheck' is already being used by 'projects/rnm-hostedsvcs-comsvcs-sq-7aea/regions/europe-west1/instanceGroupManagers/squid-europe-west1-mig', resourceInUseByAnotherResource

Here is the config:

module "squid-ilb" {
  source           = "github.com/terraform-google-modules/terraform-google-lb-internal"
  project          = var.project_id
  network_project  = var.xpn_project_id
  network          = var.xpn_name
  subnetwork       = var.xpn_subnet_name
  region           = var.region
  name             = var.lb_name
  ports            = ["80"]
  source_tags      = [var.region]
  session_affinity = "CLIENT_IP"
  health_check     = var.lb_health_check
  target_tags      = var.lb_target_tags
  backends = [
    { group = module.squid-mig.instance_group, description = "Squid managed instance groups" }
  ]
}

module "squid-mig-template" {
  source               = "terraform-google-modules/vm/google//modules/instance_template"
  version              = "~> 1.1"
  project_id           = var.project_id
  network              = var.xpn_self_link
  subnetwork           = var.xpn_subnet_self_link
  subnetwork_project   = var.xpn_project_id
  name_prefix          = var.machine_name
  source_image         = var.image_name
  source_image_family  = ""
  source_image_project = var.image_project_id
  machine_type         = var.machine_type
  labels               = var.machine_labels
  tags                 = var.machine_tags
  service_account = {
    email  = var.service_account_email
    scopes = toset(["cloud-platform"])
  }
  # startup_script       = "SQUID STARTUP SCRIPT"
}

module "squid-mig" {
  source              = "github.com/terraform-google-modules/terraform-google-vm//modules/mig"
  project_id          = var.project_id
  instance_template   = module.squid-mig-template.self_link
  region              = var.region
  network             = var.xpn_name
  subnetwork          = var.xpn_subnet_self_link
  subnetwork_project  = var.xpn_project_id
  hostname            = "squid-${var.region}"
  autoscaling_enabled = true
  autoscaling_cpu = [
    {
      target = 0.95
    }
  ]
  min_replicas           = 10
  max_replicas           = 30
  hc_port                = 80
  tcp_healthcheck_enable = true
  named_ports = [{
    name = "tcp"
    port = 3128
  }]
  update_policy = [{
    type                         = "PROACTIVE"
    instance_redistribution_type = "PROACTIVE"
    minimal_action               = "REPLACE"
    max_surge_fixed              = null
    max_unavailable_fixed        = null
    max_unavailable_percent      = 10
    max_surge_percent            = 10
    min_ready_sec                = 100
  }]
}

Can hostname be updated in automatically DNS A record in provided zone ?

Hello,
Is there anyway we can automatically create DNS A record when VMs created in cloud DNS like below ?
Any thoughts ?

resource "google_dns_record_set" "dns_record" {
  # name = "${google_compute_instance.instances.*.name[count.index]}.${google_dns_managed_zone.dns_zone.dns_name}"
  count        = var.replicas
  name = "${format("%s%02d", var.name, count.index + 1)}.${var.dns_zone}"
  #name = "${google_compute_instance.node.*.name[count.index]}.${var.dns_zone}"
  managed_zone = "${var.dns_name}"
  type = "${var.dns_record_type}"
  ttl  = "${var.dns_record_ttl}"
  rrdatas = ["${google_compute_instance.node.*.network_interface.0.network_ip[count.index]}"]
}

Thanks in advance!!

In "mig" module, append `-vm` to `base_instance_name`

In the 'mig' module, we have:

resource "google_compute_region_instance_group_manager" "mig" {
  base_instance_name = var.hostname
  name   = "${var.hostname}-mig"
}

In the instance_template module, the template name can be given a nice name as well, via the name_prefix variable:

resource "google_compute_instance_template" "tpl" {
  name_prefix             = "${var.name_prefix}-"
}

But, the naming template for VM instances is tied to the name of the MIG, and cannot be named in a similar manner

If I provide a value of backend for "hostname", I end up with:

• A MIG named backend-mig, which is nice
• A VM template named backend-vm-template-nnnnnnnnnnnnnnnn, if that's what I want
• VM instances named backend-xxxx, which is not so nice and I cannot adjust

It would be nice if the base_instance_name would be set as

  base_instance_name = "${var.hostname}-vm"

so that my vm instances have names like:

• backend-vm-nnnn

An explicit prefix variable would also do the trick.

MIG - healthchecks inconsistency

If both tcp_healthcheck_enable and http_healthcheck_enable variables are enabled, only http_healthcheck would be used https://github.com/terraform-google-modules/terraform-google-vm/blob/master/modules/mig/main.tf#L20-L22, https://github.com/terraform-google-modules/terraform-google-vm/blob/master/modules/mig/main.tf#L59. Since they're mutually exclusive, I'd suggest having just one health_check variable, which would include all other health check related variables, e.g. hc_path, hc_port, hc_interval_sec, hc_timeout_sec etc.

COMPUTE INSTANCE/UMIG: unable to specify a zone/distribution group

Sorry I'm a noob, and probably an idiot on top.

I get an error when I try to specify a zone:

module "vm_umig" {
  source             = "terraform-google-modules/vm/google//modules/umig"
  version            = "5.1.0"
  project_id         = var.project_id
  network            = var.network
  subnetwork         = var.subnetwork
  distribution_policy_zones = ["us-central1-a"]
  num_instances      = "1"
  instance_template  = module.vm_instance_template.self_link
  region             = var.region
  #access_config      = [[local.access_config]]
}

Error: Unsupported argument

  on redis.tf line 34, in module "vm_umig":
  34:   distribution_policy_zones = ["us-central1-a"]

An argument named "distribution_policy_zones" is not expected here

Error: Unsupported argument

  on redis.tf line 34, in module "vm_umig":
  34:   zone = "us-central1-a"

An argument named "zone" is not expected here.

I'm trying to deploy 9 nodes from an instance template, 3 each in us-central-1a, 1b, and 1c. I don't care about d and f. i see in the code for the module that there are settings for both zone and distirbution_policy-zones. is there a way to specify the zones I deploy to?

Thanks !

Available zones datasource prevents linking with project factory

Trying to create a project, then deploy an MIG on it. This currently can't be done in the same TF config as the data.google_compute_zone.available (line 29 in main.tf) runs before all resources and errors out:

Error: googleapi: Error 404: Failed to find project rnm-sharedsvcs-net-squid-ab53, notFound

Here is the TF config:

module "squid-project" {
  source          = "terraform-google-modules/project-factory/google//modules/fabric-project"
  version         = "~> 3.2"
  parent          = var.parent
  billing_account = var.billing_account
  prefix          = var.organization_prefix
  name            = "sharedsvcs-net-squid-${local.suffix}"
  labels = {
    cloud         = "gcp"
    business_unit = "sharedsvcs"
    team          = "network"
    project       = "squid"
    env           = "common"
  }
  activate_apis = [
    "compute.googleapis.com",
    "loadbalancing.googleapis.com"
  ]
}

...

module "squid-mig" {
  source              = "terraform-google-modules/vm/google//modules/mig"
  version             = "~> 1.0"
  region              = var.region
  project_id          = module.squid-project.project_id # LINKING PROJECT DOES NOT WORK
  instance_template   = module.squid-mig-template.self_link
  hostname            = "squid-${var.region}"
  autoscaling_enabled = true
  autoscaling_cpu = [
    {
      target = 0.95
    }
  ]
  min_replicas           = 4
  tcp_healthcheck_enable = true
  named_ports = [{
    name = "tcp"
    port = 3128
  }]
  update_policy = [{
    type                         = "PROACTIVE"
    instance_redistribution_type = "PROACTIVE"
    minimal_action               = "REPLACE"
    max_surge_fixed              = 2
    max_unavailable_fixed        = 2
    max_unavailable_percent      = 0
    max_surge_percent            = 0
    min_ready_sec                = 100
  }]
}

support for confidential compute instances

Add flag to support confidential compute instance types

This is basically another flags to the template similar to shieldedVM flag

for ref: see

• cloud-foundation-fabric#179
• terraform-provider-google docs

---

I'm going to followup this issue with a PR but do not merge it (eval is fine!). This specific PR requires google-beta since the conf. compute flags have not yet made it to provider=google

---

Please add blue green deployment example like it was in previous module

It's very frustrating that previous examples
https://github.com/GoogleCloudPlatform/terraform-google-managed-instance-group/tree/1.1.15/examples/blue-green
use ultimately not the same syntax

Allow IP assignment in instance templates

The google_compute_instance_template allows to reserve IP address:

network_ip - (Optional) The private IP address to assign to the instance. If empty, the address will be automatically assigned.

This feature is missing in the instance_template submodule.

MIG module: RegionInstanceGroupManager is forced to be re-created on every provision

That causes resource already exist API error on every subsequent provision attempt:

Error: Error creating RegionInstanceGroupManager: googleapi: Error 409: The resource 'projects/gl-ivankorniienko-seed-251912/regions/us-west1/instanceGroupManagers/multi-mig-lb-http-group1-mig' already exists, alreadyExists

  on .terraform/modules/mig1/terraform-google-modules-terraform-google-vm-cb3d6cc/modules/mig/main.tf line 32, in resource "google_compute_region_instance_group_manager" "mig":
  32: resource "google_compute_region_instance_group_manager" "mig" {



Error: Error creating RegionInstanceGroupManager: googleapi: Error 409: The resource 'projects/gl-ivankorniienko-seed-251912/regions/us-east1/instanceGroupManagers/multi-mig-lb-http-group2-mig' already exists, alreadyExists

  on .terraform/modules/mig2/terraform-google-modules-terraform-google-vm-cb3d6cc/modules/mig/main.tf line 32, in resource "google_compute_region_instance_group_manager" "mig":
  32: resource "google_compute_region_instance_group_manager" "mig" {

unexpected umig requirement

AFAIK unmanaged instance group does not require any instance template, it just needs below parameters:

• Name
• Region and Zone
• Network and Subnetwork
• List of instances (falling under provided Subnetwork and Zone)

The current Terraform module to create unmanaged instance group is attached to an instance template resource which will create number of identical instances, this eliminates the definition of unmanaged instance group.

Expected requirement would be to collect instances ID to simply add it in the instance group which could be unidentical/not created via a common instance template

MIG: target_size being set when autoscaling is enabled

Hi

I am using the MIG module (v1.4.0) to manage instance groups with auto-scaling. The instance group has been up and running for some time and auto scaler kicked in, therefore increasing the number of instances above min_replicas.

The problem is when I run terraform apply on a scaled up instance group, the module tries to set target_size to min_replicas (code) and google throws an error about it:

Error: Error resizing RegionInstanceGroupManager: googleapi: Error 412: Resizing of autoscaled regional managed instance groups is not allowed. If you want to manually adjust target size remove the autoscaler or set autoscaling policy mode to OFF., conditionNotMet

And as stated in the error, the target_size shouldn't be set at all when an autoscaler is attached to the instance group (provider docs):

This value should always be explicitly set unless this resource is attached to an autoscaler, in which case it should never be set.

This problem wouldn't show up if the group is at min_replicas scale, since no change would be calculated during the plan and the target_size value won't be set.

This would probably fix it:

target_size = var.autoscaling_enabled ? var.min_replicas : var.target_size
to

target_size = var.autoscaling_enabled ? null : var.target_size

Instance template module does not allow an ephemeral IP address

It is not possible to create an instance with an ephemeral IP address.
May be related to #80

[mig] Allow configuring scale-in control for autoscaler

Autoscalers in GCP allow defining scale-in controls (https://cloud.google.com/compute/docs/autoscaler#scale-in_controls) that give some control on how instances should be reduced from an autoscaling group (amount and time window to consider).

From the documentation, this is already exposed by the provider (https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_region_autoscaler#scale_in_control), but not used or exposed by this module.

We should keep the current behaviour (no scale-in control by default), but give the ability to tweak this behaviour by configuration.

If this request is ok I can work on this if needed/wanted

Attaching public IP to instance.

The instance_template allows allocating a list of IPs via access_config parameter. But it's not clear to me how to attach an IP form that list to the instance. I can do that from the GCP Console after creating the instance but is it possible to do that from Terraform?

If I pass the same list of of IPs to static_ips parameter on compute_instance sub module, it'd complain

Requested internal IP is outside the subnetwork CIDR range

Any help is appreciated.

service_account should not be required for instance_template module

Hi,

I want to create a template without a service_account attached to the instance.

According to the docs this is an optional argument.

If you agree I can submit a PR.

Thanks!

Setting MIG update policy is not possible

Setting the update policy is broken, this is because all values are required by the module, such as;

type = "PROACTIVE" instance_redistribution_type = "PROACTIVE" minimal_action = "REPLACE" max_surge_fixed = 0 max_surge_percent = 20 max_unavailable_fixed = 2 max_unavailable_percent = 0 min_ready_sec = 50 replacement_method = "RECREATE"

However some of the values are conflicting, max_surge_percent conflicts with max_surge_fixed, and max_unavailable_fixed conflicts with max_unavailable_percent, making it impossible to run the terraform apply.

Unable to specify device name of disks in instance template module

Currently the instance template module does not support passing the device name for additional disks.

This is needed when trying to create Stateful MIGs.

Ideally the following configuration would work:

module "template" {
  source               = "terraform-google-modules/vm/google//modules/instance_template"
  project_id           = var.project_id
  subnetwork           = var.subnetwork
  service_account      = var.service_account
  subnetwork_project   = var.project_id
  source_image_family  = "ubuntu-1804-lts"
  source_image_project = "ubuntu-os-cloud"
  name_prefix          = "my-app"
  additional_disks = [{
    auto_delete  = false
    boot         = false
    disk_size_gb = 20
    disk_type    = "pd-standard"
    device_name  = "mydata"
  }]
}

module "mig" {
  source            = "terraform-google-modules/vm/google//modules/mig"
  project_id        = var.project_id
  region            = var.region
  target_size       = 1
  hostname          = "my-app"
  instance_template = module.template.self_link
  stateful_disks = list({
    device_name = "mydata"
    delete_rule = "NEVER"
  })
}

But instead an error is returned:

Error: Error creating RegionInstanceGroupManager: googleapi: Error 400: Invalid value for field 'resource.versions[0].instanceTemplate': 'https://www.googleapis.com/compute/beta/projects/my-project/global/instanceTemplates/my-app-2021*****. Instance template my-app-2021*** does not contain stateful disks [mydata]., invalid

Could we add the device name field to the additional_disks variable?

CentOS 6 EOL

The CentOS 6 has reached its EOL and is no longer available as a GCE image.

Usually, it should not be an issue, but if for the instance_template module the image_family is set to empty string, terraform considers it as unset and falls back to the centos-6 image family.

Such a fallback makes some pipelines fail with smth like this:

Error: error retrieving image information: googleapi: Error 404: The resource 'projects/centos-cloud/global/images/family/centos-6' was not found, notFound

  on .terraform/modules/sim-preemptible-template.vm_instance_template/modules/instance_template/main.tf line 25, in data "google_compute_image" "image_family":
  25: data "google_compute_image" "image_family" {

MIG - Update policy cannot be created

There is an issue with the update_policy variable: it requires all fields to be set, but if you set all the fields (see 1.), the API will give you an error. If you set only API-required fields (see 2.), the module gives an error

1. Passing all arguments:

module "squid-mig" {
  source              = "terraform-google-modules/vm/google//modules/mig"
  version             = "~> 1.0"
  ...
  update_policy = [{
    type                         = "PROACTIVE"
    instance_redistribution_type = "PROACTIVE"
    minimal_action               = "REPLACE"
    max_surge_fixed              = 2
    max_unavailable_fixed        = 2
    max_unavailable_percent      = 0
    max_surge_percent            = 0
    min_ready_sec                = 100
  }]
}

Fails with:

2. Passing only API-required arguments:

module "squid-mig" {
  source              = "terraform-google-modules/vm/google//modules/mig"
  version             = "~> 1.0"
  region              = var.region
  project_id          = module.squid-project.project_id
  instance_template   = module.squid-mig-template.self_link
  hostname            = "squid-${var.region}"
  autoscaling_enabled = true
  autoscaling_cpu = [
    {
      target = 0.95
    }
  ]
  min_replicas           = 4
  tcp_healthcheck_enable = true
  named_ports = [{
    name = "tcp"
    port = 3128
  }]
  hc_port = 80
  update_policy = [{
    type                         = "PROACTIVE"
    instance_redistribution_type = "PROACTIVE"
    minimal_action               = "REPLACE"
    max_unavailable_percent      = 0
    max_surge_percent            = 0
    min_ready_sec                = 100
  }]
}

fails with:

Module does not accept auto_healing_policies

terraform keeps repeating that block is not expected.

It seems auto_healing_policies is not declared or added to variables.tf .

Can someone confirm ?

I need autohealing to work for this module.

Not able to provide healthcheck to modules/mig

We currently use this module (modules/mig) to declare MIG. we also define google_compute_backend_service and google_compute_health_check in our TF file. We now want to share the existing health check between backend service and MIG but it seems there is no way of doing so without destroying and recreating existing health check. It would be nice if modules/mig can accept externally created healthcheck like google_compute_backend_service does.

Our terraform config for reference:

module "my_mig_template" {
  source               = "terraform-google-modules/vm/google//modules/instance_template"
  version              = "2.1.0"
  network              = "default"
  name_prefix          = "my-service-${local.commit-sha}"
  disk_size_gb         = "10"
  disk_type            = "pd-ssd"
  enable_shielded_vm   = true
  machine_type         = "e2-small"
  source_image_family  = "cos-stable"
  source_image_project = "cos-cloud"
  source_image = reverse(split("/", module.container.source_image))[0]
  metadata     = map(
    "gce-container-declaration", module.container.metadata_value,
    "google-logging-enabled", "true")
  labels = {
    "container-vm" = module.container.vm_container_label
  }
}

module "my_mig" {
  source            = "terraform-google-modules/vm/google//modules/mig"
  version           = "2.1.0"
  instance_template = module.my_mig_template.self_link
  region            = var.region
  target_size       = "1"
  hostname          = "myservice"
  named_ports = [
    {
      name = "http",
      port = var.image_port
    }
  ]
  network = var.network
}

resource "google_compute_backend_service" "my-service-service" {
  name                            = "my-service-service"
  port_name                       = "http"
  protocol                        = "HTTP"
  enable_cdn                      = true
  timeout_sec                     = 30
  connection_draining_timeout_sec = 35

  backend {
    group = module.my_mig.instance_group
  }

  log_config {
    enable = true
    sample_rate = 1
  }

  health_checks = [
    google_compute_health_check.my-service-http-health.self_link,
  ]
}

resource "google_compute_health_check" "my-service-http-health" {
  provider = google-beta
  name     = "my-service-http-health"

  check_interval_sec  = 5
  timeout_sec         = 5
  healthy_threshold   = 1
  unhealthy_threshold = 10

  http_health_check {
    port         = var.image_port
    request_path = "/healthz"
  }
}

Add support for Terraform 0.12