The code language I'm using is Terraform (Hashicorp Configuration Language or HCL) as the 'infrastructure as code' to automate the process of GCP creating everything for the server stack, and Helm charts for the M2 application. I've gotten as far as Terraform will create the GKE cluster, node pool, and Cloud SQL database, including the VPC network, virtual peering, and it's all secured with service accounts, etc. The database is on a private IP address with SSL applied, and I can confirm it is linked properly as far as on the same private VPC network as the GKE cluster (which has a public endpoint and Ingress setup with an external load balancer). The next step is to enable GKE to work on the Cloud SQL instance.
In the Google Guides section, they describe various methods to connect GKE and Cloud SQL, here at this link:
https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine
Cloud Auth Proxy is mentioned, although in my research, I heard going with that option it was a more complex route -- and in the Google Guide, it says:
"If you are using Google Kubernetes Engine, the preferred method is to use GKE's Workload Identity feature."
Which seems to indicate that using GKE's Workload Identity, to link GKE to Cloud SQL, is a separate option than via Cloud Auth Proxy, no?
For example, in my Terraform file, in creating the primary cluster, I have:
// GKE: GOOGLE KUBERNETES ENGINE
// Creates the primary cluster
resource "google_container_cluster" "primary" {
name = var.cluster
project = var.project_id
location = var.zones
... ... ...
// This is required to have workloads and to enable gke metadata on the node pods.
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
... ... ...
I'm using YAML files for my Magento 2 application, but I'm running that as a separate deployment from the Terraform code which manages the GCP server stack, which deploys the app only once the Terraform has configured the server stack on GCP. I currently do not have any YAML files configured manually with the Terraform code base; however, if there is a way to add a YAML to a Terraform chart, then I would be eager to learn more about that process.
I've added the Workload Identity to the GKE cluster, but so far my testing hasn't resulted in GKE successfully linking to the Cloud SQL database.
However, there is a new 'simplified operator available in YAML file to connect GKE and Cloud SQL available here:
Per the above link, what is the difference between Cloud SQL Proxy Operator and Cloud Auth Proxy?
Does Cloud SQL Proxy Operator work along with Google's Workload Identity (per the link below) -- to connect GKE and Cloud SQL -- or is Workload Identity not necessary? My next test for the Workload Identity will be to bind the GCP service account on the database to the Kubernetes service account, but I don't know if that will be sufficient to enable GKE to work directly on the Cloud SQL database -- or whether Cloud SQL Proxy Operator or Cloud Auth Proxy would also be helpful to add that as well.
- Is Cloud SQL Proxy Operator only intended to be packaged in YAML files (or run directly in gcloud CLI)? I would prefer to use Terraform code for any part of the main GCP server stack, since that's what I've already custom coded. Since Cloud SQL Proxy Operator seems fairly new, then unless a Terraform code or module is added or becomes available, I don't know how else to implement Cloud SQL Proxy Operator to the Terraform code that I've already been working on (and my Terraform code repository is quite extensive already).
