1

I'm new about GCP network.

I recently use Direct VPC egress. If I disable Direct VPC egress and use followed format DATABASE_URL

postgresql://user:password@localhost/db_name?host=/cloudsql/project_id:region:db_id

, it works, but if I enable VPC egress, it emit an error.

couldn't listen at "/tmp/cloudsql-proxy-tmp/connection_name ~ bind: invalid argument

I guess VPC subnet of VPC direct egress doesn't allow something egress ports or Internet Connection using IP, though I thought VPC network can use google private access. I know cloud SQL network separated from project VPC network thus, we must use VPC peering, but I want to use public IP only with cloud SQL proxy if we can. When we use subnetwork with Direct VPC egress, must we use private IP address of cloud SQL?

Improve this question
11
  • 1
    I am not sure Cloud Run direct VPC egress supports unix-socket connection to Cloud SQL. It is possible to use the CR direct-VPC along with Cloud SQL Auth Proxy to access private IP based Cloud SQL instance. This community thread had some decent deep-dive on this configuration. googlecloudcommunity.com/gc/Serverless/… Commented Jan 21, 2024 at 17:01
  • 1
    @GangChen is right. Cloud SQL connection on Cloud Run open a unix socket on a Cloud SQL instance with public IP. For that, you don't need a VPC access. If you want to use a Cloud SQL with only a private IP, you can't use the Cloud Run built in connector to Cloud SQL. You can use a side car proxy to open this unix socket on private IP with a VPC access. The trick here is to share the same volume between the side car (which open the socket) and the main container (which consume the socket) Commented Jan 21, 2024 at 21:12
  • 2
    Cloud Run and Cloud SQL are not part of your project's VPC. Connectors, etc are not transitive. That means traffic going into a VPC will not be routed outside that VPC. This will not work: Cloud Run -> VPC -> Cloud SQL Public IP. This will work: Cloud Run -> VPC -> Cloud SQL Private IP. There is no benefit I can think of to trying to use Direct VPC Egress for Cloud SQL public addresses beyond the fact that it will not work. Commented Jan 21, 2024 at 21:17
  • 1
    I found this cloud.google.com/blog/products/serverless/… quite useful. In both direct VPC egress and VPC access connector's cases, the destination resources have internal IP addresses. Commented Jan 22, 2024 at 2:03
  • Thank you much information. In addition, I need to use VPC so that a cloud run service exposed to a public internet communicates with another cloud run in another project via shared VPC (I already know how to make it work). My main interest is whether or not we can use hybrid unix socket connection to sql via cloud sql proxy (or direct access) and VPC private access using Direct VPC and it's no problem to use private IP access if we have no choice to access to cloud sql's public IP. Commented Jan 22, 2024 at 2:46

1 Answer 1

Reset to default
1

Update(2024/02/03):

I found that cloud sql proxy restricts 108 chars path with unix socket. And my DB socket path has more characters than it in the environment. You can access to cloud sql with public IP only when using PRIVATE_RANGES_ONLY traffic configuration and conform unix socket's restrictions.

From SQL Config:

enter image description here

From Cloud Run Config:

enter image description here

From Cloud Run Access Log:

enter image description here

You can also access using private IP as following followed by description.

Deprecated:

Further research, I conclude cloud run's default cloud-sql-proxy connection can't configure private-ip option of https://github.com/GoogleCloudPlatform/cloud-sql-proxy now.

This means the socket with proxy doesn't connect to private IP and should imply proxy using private google access to access identity aware proxy in VPC even if private_range_ip_only traffic config used.That is why unix socket connection is refused.If we want to use unix socket connection in VPC, only the way I thought is to run cloud sql proxy with private-ip option specified in sidecar as guillaume blaquiere's comment.

Current confident way to work around is private ip access as @John Hanley describes.

The article @gang-chen introduce is very helpful.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.