GCP CloudSQL: Proxy connections about provider-gcp HOT 7 OPEN

Until Crossplane has a fully baked solution for this can I suggest that we just add the connection string to the generated secret and document it? The sample here is broken until that gets fixed really: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/wordpress/gcp/wordpress.yaml (it uses the IP address "endpoint" not the full connection string). At least it's broken for an app running outside GCP (haven't tried it in GKE).

I already see the connection string in the status of the cloudsqlinstance:

$ kubectl get cloudsqlinstance -o yaml
apiVersion: v1
items:
- apiVersion: database.gcp.crossplane.io/v1beta1
  kind: CloudSQLInstance
  metadata:
    annotations:
      crossplane.io/external-name: default-mysql-claim-j2b85
...
  status:
    atProvider:
      backendType: SECOND_GEN
      connectionName: cf-sandbox-dsyer:us-central1:default-mysql-claim-j2b85
...

so I believe it is available to the controller that creates the secret. The command line for cloud_sql_proxy would look like this:

cloud_sql_proxy -dir/cloudsql -instances=cf-sandbox-dsyer:us-central1:default-mysql-claim-j2b85=tcp:3306

so that status.connectionName from the CloudSQLInstance is needed in the app deployment for the proxy sidecar.

from provider-gcp.

It's public by default - at least that's what I see. But you can't connect with a regular mysql client, only the proxy (unless you authorize your client's network explicitly).

from provider-gcp.

I also have not thought this through particularly thoroughly, but I've previously imagined a supplement to Crossplane that was capable of automatically injecting proxies (CloudSQL, service mesh sidecars, etc) into workloads (perhaps using a mutating webhook) by intelligently analysing their connectivity needs as declared (somehow) by Crossplane. My suspicion is that this functionality would be best if it were not baked into Crossplane but was instead an optional addon.

from provider-gcp.

@dsyer Would exposing status.atProvider.connectionName alongside the existing ones in the connection secret be enough to satisfy your use case?

The sample here is broken until that gets fixed really: https://github.com/crossplaneio/crossplane/blob/master/cluster/examples/wordpress/gcp/wordpress.yaml (it uses the IP address "endpoint" not the full connection string). At least it's broken for an app running outside GCP (haven't tried it in GKE).

The Wordpress example is intended to be used in a private network. That's why it instructs you to create a network, subnetwork etc. If you'd like to use the CloudSQLInstance from an app that is outside GCP, another option besides proxy is to expose CloudSQLInstance IP address to the public. To achieve this, you can set spec.forProvider.settings.ipConfiguration.ipv4Enabled: true. An example YAML looks like the following:

apiVersion: database.gcp.crossplane.io/v1beta1
kind: CloudSQLInstance
metadata:
  labels:
  name: crossplane-wordpress-cloudsql
spec:
  providerRef:
    name: example
  forProvider:
    region: us-west2
    databaseVersion: MYSQL_5_7
    settings:
      ipConfiguration:
        ipv4Enabled: true
      tier: db-n1-standard-1
      dataDiskType: PD_SSD
      dataDiskSizeGb: 10
  writeConnectionSecretToRef:
    namespace: crossplane-system
    name: demo-database-connection

In fact, spec.forProvider struct is almost exactly same as GCP API object.

from provider-gcp.

Would exposing status.atProvider.connectionName alongside the existing ones in the connection secret be enough to satisfy your use case?

Yes.

I think ipConfiguration.ipv4Enabled=true is the default. At least it doesn't behave any differently for me. You get a public IP address, but you can only connect to it though the connectionName.

from provider-gcp.

You get a public IP address

I am not sure. As far as I remember, the default is false. The IP you're getting is probably the private in-VPC IP. You should be able to see the IP addresses and their properties under status or on GCP console to see which one is private/public.

from provider-gcp.

@dsyer #159 this should at least make it easier for you to consume the connectionName but I don't have much context around how CloudSQL proxies work.

Do you think @negz is exposing only connectionName enough to fix this issue for all CloudSQL proxy connection scenarios?

from provider-gcp.