1

My scenario started off with needing private IP access for Cloud SQL from a build server running as a compute engine instance in the same project. For some context, my build server connects to Cloud SQL to execute DDL SQL statements (automatic SQL migrations based on the diff between init.sql that is part of my repository and the schema on the targeted database) if the deployed artifact is expecting new rows / tables. I accomplished this using a VPC peering connection between the VPC GCP uses for Cloud SQL databases and the VPC I explicitly created for my compute engine instances.

My scenario eventually evolved into moving the build server into a separate project. Because of lack of transitive peering, I created a shared VPC where my Cloud SQL project is considered the host project, and my build server project is considered the service project. This is all working great.

I had moved the build server into a separate project with the eventual goal of creating a third project for my staging environment. I was then planning to enable private IP connections between my build server and the two other projects. However, now that I'm trying to add my staging environment, I found that this is impossible because according to the docs:

You can create and use multiple host projects; however, each service project can only be attached to a single host project.

Whereas I wanted both the production and staging projects to be host projects for my build server service project.

Is there anyway to meet these two requirements?

  1. Keep my build server(s), production environment and staging environment as three separate projects.
  2. Have private IP connectivity between my build server and both production and staging database.

Am also open to critiques/feedback about the setup I've outlined here, because at end of day I've only derived above requirements from what I know and have set up so far.

Mario Ishac
  • 5,060
  • 3
  • 21
  • 52

1 Answers1

3

The solution is to have the same VPC for the build server and the 2 databases (prod and staging). The problem is the non-isolation of the environments that can lead to issues.

I have 2 propositions to change/adapt the design:

  • Keep the environment identical: 1 for the production, 1 for the staging. 2 different projects, strong isolation, and easy reproductibility because of the same design on both environments. But more expensive
  • Keep public IP on Cloud SQL database and use Cloud SQL proxy to reach them. You gain an encrypted channel and your are no longer tight with peering, private P and shared VPC. Having a public IP not mean having authorized networks. You authorize no network (similar to a firewall rule 0.0.0.0/0 deny all), you only have a public IP.
guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Hey Guillaume, thanks for responding. Regarding #1, I thought that is what I have right now. But you said it's a changed/adapted design, so can you clarify what part is different from original design, and how VPC can stretch across 3 projects? Regarding #2, this looks like a very good solution. Would the proxy reside in build server project and connect to public IP of database in different project, or would it reside in same project as database and then build server would peer into proxy? – Mario Ishac May 14 '21 at 01:15
  • In the #1, you can't have only one build project (as I understood in your description). You need to duplicate also the build part. for the #2, open the tunnel where you use it; thus on the build server. – guillaume blaquiere May 14 '21 at 07:33
  • 1
    Ah got you, for #1 you're saying I'd have to have two build server projects that each have a shared VPC with their respective environment. I'd like to stick to one build server, so I'll give #2 a try over these next few days. Thanks for following up. – Mario Ishac May 14 '21 at 07:38