Support configuring proxy with environment variables

[micheas]

With instances being a command line argument I cannot use k8s secrets to set the instance and then recycle the same deployment.yaml file between environments, but rather resort to a generator for the k8s config.

An example can be found at:

https://github.com/itkj/docker-cloud-sql-proxy/blob/master/Dockerfile#L10

from itkj/docker-cloud-sql-proxy on docker hub.

[enocom]

We're working on some major structural improvements to the proxy. Once those are complete, we'll come back to address this issue.

[enocom]

The new v2 proxy uses cobra and makes it easy to integrate with viper. Now that the v2 proxy is out, I have this in my backlog.

[enocom]

This work will unblock https://github.com/GoogleCloudPlatform/cloud-sql-proxy/issues/1045.

[hessjcg]

What if we did a kind of naming scheme for the environment variables:

# global flag
CLOUD_SQL_PROXY_PORT=5000 
CLOUD_SQL_PROXY_CREDENTIALS_FILE=./keys/service_account.json # global flag

# instance specific flags
CLOUD_SQL_PROXY_INSTANCE_1=hello:world:db1 # instance flag
CLOUD_SQL_PROXY_INSTANCE_1_PORT=8080
CLOUD_SQL_PROXY_INSTANCE_1_PRIVATE_IP=true #Boolean env var?

CLOUD_SQL_PROXY_INSTANCE_2=hello:world:db2
CLOUD_SQL_PROXY_INSTANCE_2_PORT=8081
CLOUD_SQL_PROXY_INSTANCE_2_USE_IAM_AUTHN=true

[enocom]

I think we should make the list of instance connection names zero indexed and also define an INSTANCE_CONNECTION_NAME variable for the first instance, for the cases when someone is connecting to only a single instance:

CLOUD_SQL_PROXY_INSTANCE_CONNECTION_NAME=proj:reg:myinst
CLOUD_SQL_PROXY_INSTANCE_0=proj:reg:myinst
CLOUD_SQL_PROXY_INSTANCE_1=proj:reg:myotherinst

[enocom]

Also, to configure individual instances, we'll continue to use query params:

CLOUD_SQL_AUTO_IAM_AUTHN=true
CLOUD_SQL_PROXY_INSTANCE_0=proj:reg:myinst?auto-iam-authn=false