Allow use of TCP sockets instead of Unix sockets when using "Automatic instance discovery"

[steve-kidreads-app]

Feature Request

I suggest a cl flag like this, that would force cloudsql-proxy to use TCP sockets even if Unix sockets are supported:
-tcp=[IP]:[PORT]

Background

When Unix sockets are supported, they are the default:
https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/97815fd45aea66bdd5703e83bcc8cab68f1ef593/cmd/cloud_sql_proxy/cloud_sql_proxy.go#L239-L241

You can override this default, but only if you're willing to also specify the instance:
https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/97815fd45aea66bdd5703e83bcc8cab68f1ef593/cmd/cloud_sql_proxy/cloud_sql_proxy.go#L199

cloudsql-proxy supports "Automatic instance discovery" which is useful:
https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/97815fd45aea66bdd5703e83bcc8cab68f1ef593/cmd/cloud_sql_proxy/cloud_sql_proxy.go#L243-L247

But there is no way to use "Automatic instance discovery" and specify TCP sockets when Unix sockets are supported. No cl switch exists.

Why it would be useful

This would be a useful feature because developers collaborating but using different platforms could use the same dev configuration (i.e. their code points to 127.0.0.1:3600) and rely on automatic instance discovery to proxy that to the correct instance. The benefit of automatic instance discovery in this context is that developers set their active project in gcloud and don't then have to also set it in the cloudsql-proxy cl (or risk having the two out-of-sync). I'm sure that Unix sockets are more performant, but for developer consistency this option would be great.

Caveat

Admittedly, it's not clear what to do in situations where there are multiple instances: do they just get mapped to consecutive ports starting with [PORT]? I don't actually know what "Automatic instance discovery" does today on non-Unix systems. In my use-case, I have one instance per project.

[kurtisvg]

I've actually thought about this a bit before, and probably two reasonable approaches. The first would be a starting port (maybe specified by flag as you've suggested), and incrementing the value for consecutive instances. An alternative would be starting with the default ports for a specific engines (Mysql=3306, Pg=5432, etc) and incrementing for multiple instances of the same engine.

The trick I think is probably figuring out how to make the "automatic discovery" as deterministic as possible - if you did alphabetically, you're open to someone adding a new instance in the project and suddenly all your ports are off by one. Maybe by instance creation date? But deleting an instance could have the same problem, so I don't know how useful it would be long-term.

[steve-kidreads-app]

Either of those approaches seem reasonable.

Does "automatic discovery" work on non-Unix systems? If so, someone must have had to answer this question.

For my purposes, it will always be deterministic because I have only one database per instance. But if you wanted to account for multiple-instance cases, why not just write a "tcpsockets-[instance]" file to -dir with IP:PORT inside?

[kurtisvg]

Automatic discovery isn't really supported on Windows because it relies on Unix domain sockets and the proxy doesn't support them on windows. It hasn't really been a huge priority to do so since most users prefer TCP sockets on Windows.

[enocom]

Not exactly a fix to this issue, but the new v2 dialer will default to TCP sockets.

[enocom]

The new v2 proxy (currently in public preview) defaults to TCP sockets. We've decided to skip porting the automatic instance discovery feature to v2, given our preference for explicit configuration.

However, if you'd prefer to skip specifying instance connection names ahead of time, we do support FUSE on v2 (both on macOS and Linux).

There still might be a feature request in here, but it's probably worth reformulating it after trying out v2.

[enocom]

Correction: we will support FUSE on v2. That functionality is currently working its way through review. Follow the progress here: #1312.