CloudSQL: support for Private networking

[rolandkool]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Google recently announced that CloudSQL private networking moved to Beta: https://cloud.google.com/blog/products/databases/introducing-private-networking-connection-for-cloud-sql
It would be nice if the Google provider for terraform would add support for this feature as well.

New or Affected Resource(s)

• google_sql_database_instance

[Stono]

Hey!
It'd be great if this was added, we kinda need it :-)

[sereeth]

Any eta on when this might be supported?

[gburiola]

@sereeth / @Stono what you can do in the meantime is enable private networking using gcloud and local-exec.

The gcloud commands are:

gcloud beta compute addresses create google-managed-services-default \
    --description='Peering range reserved for Google' --global \
    --network=default --purpose=VPC_PEERING --prefix-length=16

gcloud alpha services vpc-peerings connect --network=default \
    --ranges=google-managed-services-default --service=servicenetworking.googleapis.com
    
gcloud beta sql instances patch cloudsql-instance --network=default

resource "null_resource" "cloudsql-private-ip" {
  provisioner "local-exec" {
    "command" = "gcloud beta compute addresses create google-managed-services-default --description='Peering range reserved for Google' --global --network=default --purpose=VPC_PEERING --prefix-length=16 && gcloud alpha services vpc-peerings connect --network=default --ranges=google-managed-services-default --service=servicenetworking.googleapis.com && gcloud beta sql instances patch cloudsql-instance --network=default || true"
  }
}

The || true at the end is because the last command takes more than 5 minutes to run and gcloud times out. There's no option on the gcloud command to specify the timeout so I reset the return code with || true.
In my tests the last command always works despite the gcloud timeout

[sereeth]

@Stono I take it the network should be whatever network you want? i.e the network our GKE cluster uses.

[craigdbarber]

I'll be working on this. PR to follow :)

[robertpate]

IF this is available now, how do I configure my terraform?

[craigdbarber]

We're waiting on one final PR to merge for this to become available in the beta project: hashicorp/terraform-provider-google-beta#46

[glerma-sadasys]

Help! approve PR ^ pretty please!

[glerma-sadasys]

@gburiola The current beta for gcloud does not appear to support those arguments anymore.

22:56 $ gcloud beta compute addresses create google-managed-services-default \
    --description='Peering range reserved for Google' --global \
     --network=default --purpose=VPC_PEERING --prefix-length=16
ERROR: (gcloud.beta.compute.addresses.create) unrecognized arguments:
  --network=default (did you mean '--network-tier'?)
  --purpose=VPC_PEERING (did you mean '--project'?)
  --prefix-length=16

EDIT: UPDATE: This was due to my outdated SDK version. After updating, the --purpose and prefix-length options now exist!

[robertpate]

I am running the local-exec right after creating the database and a user, and I am getting:
ERROR: (gcloud.beta.sql.instances.patch) HTTPError 409: Operation failed because another operation was already in progress.
Anybody seeing this? Is there anything I can do to make the operation sequential?

[Chupaka]

Error on what? Be more descriptive, and create new issue :)

[glerma-sadasys]

I am running the local-exec right after creating the database and a user, and I am getting:
ERROR: (gcloud.beta.sql.instances.patch) HTTPError 409: Operation failed because another operation was already in progress.
Anybody seeing this? Is there anything I can do to make the operation sequential?

I ran into this issue. Essentially the cloud sql instance is still "in progress", being provisioned when this happens. Thus if you try to run subsequent local-exec gcloud commands before it finishes, could run into that error. I had to get around this by doing a little "depends on" trickery:

resource "null_resource" "apply-cloudsql-private-ip" {
  provisioner "local-exec" {
    command = <<EOF
    gcloud beta compute addresses create ${var.peering_address_range_name}-${var.project_id} \
    --global \
    --addresses ${var.peering_cidr_range} \
    --prefix-length ${var.peering_cidr_prefix} \
    --description "Peering range for Google Services" \
    --project ${var.project_id} \
    --purpose VPC_PEERING  \
    --network ${var.network} \
    --quiet
EOF
  }
}

resource "null_resource" "destroy-cloudsql-private-ip" {
  provisioner "local-exec" {
    when = "destroy"

    command = <<EOF
    gcloud beta compute addresses delete ${var.peering_address_range_name}-${var.project_id} --global
EOF
  }
}

resource "null_resource" "vpc-to-services-peering" {
  provisioner "local-exec" {
    command = <<EOF
    gcloud beta services vpc-peerings connect \
    --service servicenetworking.googleapis.com \
    --network ${var.network} \
    --ranges "${var.peering_address_range_name}-${var.project_id}"  \
    --project=${var.project_id} \
    --quiet
EOF
  }

  depends_on = ["null_resource.apply-cloudsql-private-ip"]
}

resource "null_resource" "destroy-vpc-to-services-peering" {
  provisioner "local-exec" {
    when = "destroy"

    command = <<EOF
    gcloud compute networks peerings delete cloudsql-mysql-googleapis-com --network ${var.network} --quiet
    gcloud compute networks peerings delete servicenetworking-googleapis-com --network ${var.network} --quiet
EOF
  }
}

resource "null_resource" "patch_sql" {
  provisioner "local-exec" {
    command = <<EOF
    gcloud beta sql instances patch ${google_sql_database_instance.default.name}   --network ${var.network}  --quiet
    gcloud beta sql instances patch  ${google_sql_database_instance.default.name}  --no-assign-ip
EOF
  }

  // Do not change this order, otherwise can cause issues for you.
  depends_on = ["google_sql_database_instance.default", "google_sql_database.db", "google_sql_user.default", "null_resource.vpc-to-services-peering"]
}

It's not pretty, but it worked. That allows the database instance to complete before moving on to other actions. Hope that helps.

[craigdbarber]

This indirect dependency is handled in the beta provider's implementation, see: https://github.com/terraform-providers/terraform-provider-google-beta/blob/2.0.0/website/docs/r/sql_database_instance.html.markdown

[adrianlop]

@craigatgoogle that's great news but unfortunately that 2.0.0 branch can't be used in terraform, afaik it has to be a Release so terraform can download it using terraform init, right?

[craigdbarber]

I'll defer to @danawillow as to the best strategy for utilizing the beta provider.

[danawillow]

Yup, private IP support will be in the 2.0.0 release of terraform-provider-google-beta, which has not happened yet.

[danawillow]

Closing this issue since the code has been checked in.

[ipstatic]

Is there an ETA on that release? Or is there a way to run use this before the release?

[rileykarson]

You can build from HEAD on the 2.0.0 branch and run it with a release copy of Terraform; we don't offer any guarantees of safety/stability so I wouldn't recommend doing so for anything other than testing purposes.

Our best ETA is that the 2.0.0 release will be roughly in line with Terraform 0.12's first beta.

[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 👉 hashibot-feedback@hashicorp.com. Thanks!