|
| 1 | +# Enable ACM features with Terraform - Part 3 |
| 2 | + |
| 3 | +This is part three of the tutorial to accompany a short series of blog articles explaining how to enable [Anthos Config Management (ACM)](https://cloud.google.com/anthos/config-management) with Terraform. |
| 4 | + |
| 5 | +In the [first part](../acm-terraform-blog-part1), we explained how to use Terraform to create a cluster and manage its config from git via [Config Sync](https://cloud.google.com/anthos-config-management/docs/config-sync-overview). |
| 6 | + |
| 7 | +In the [second part](../acm-terraform-blog-part2) we added guard rails for the cluster configuration via [Policy Controller](https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller). |
| 8 | + |
| 9 | +In this article we'll demonstrate how, using Config Connector, you can provision your GCP cloud resources following the same Kubernetes-native model. |
| 10 | + |
| 11 | +## Provision GCP resources |
| 12 | + |
| 13 | +1. Set the variable for the project from [part two](../acm-terraform-blog-part2). We will re-use that project but create a new cluster since we cleaned up at the end of the first section. If you are working in a different project, enable required GCP APIs, as described in [part one](../part1/README.md). |
| 14 | + |
| 15 | + ```bash |
| 16 | + PROJECT_ID = [PROJECT_ID] |
| 17 | + ``` |
| 18 | +1. Note that [wordpress-bundle.yaml](./config-root/wordpress-bundle) was updated to use GCP MySQL database. Also we added [configconnector.yaml](./config-root/configconnector.yaml) to initialize the instance of Config Connector add-on on the cluster. |
| 19 | + |
| 20 | +1. Use [kpt](https://kpt.dev) to customize the `config-root` directory that will be configured as the source of the objects installed on the cluster. |
| 21 | + |
| 22 | + ```bash |
| 23 | + kpt fn eval --include-meta-resources --image gcr.io/kpt-fn/set-project-id:v0.1 ./config-root -- "project-id=$PROJECT_ID" |
| 24 | + kpt fn render ./config-root |
| 25 | + ``` |
| 26 | +1. Submit the updated configuration into your branch. |
| 27 | +1. Ensure that `sync_repo` and `sync_branch` variables are updated in [terraform.tfvars](./terraform/terraform.tfvars) |
| 28 | +1. Before running Terraform, notice the changes in [gke.tf](./terraform/gke.tf): |
| 29 | + - We are using the `[beta-public-cluster](../modules/beta-public-cluster)` module |
| 30 | + - `config_connector` variable is set to true |
| 31 | + - We are using `workload-identity` module to create a Google Service Account and connect it to a Kubernetes Service Account that is running in Config Connector `cnrm-system` namespace, allowing Config Connector to create GCP resource. |
| 32 | +1. As as in the previous part, create the cluster using Terraform: |
| 33 | + |
| 34 | + ```bash |
| 35 | + # obtain user access credentials to use for Terraform commands |
| 36 | + gcloud auth application-default login |
| 37 | +
|
| 38 | + # continue in /terraform directory |
| 39 | + cd terraform |
| 40 | + export TF_VAR_project=$PROJECT_ID |
| 41 | + terraform init |
| 42 | + terraform plan |
| 43 | + terraform apply |
| 44 | + ``` |
| 45 | + NOTE: if you get an error due to the default network not being present, run `gcloud compute networks create default --subnet-mode=auto` and retry the commands. |
| 46 | + |
| 47 | +1. To verify things have synced and Policy Controller is installed, you can again use `gcloud` to check status: |
| 48 | + |
| 49 | + ```bash |
| 50 | + gcloud alpha container hub config-management status --project $PROJECT_ID |
| 51 | + ``` |
| 52 | + |
| 53 | + As things initialize, you may see a few transient `error: KNV1021: No CustomResourceDefinition is defined` messages. This occurs when constraints from the repo are synced before Policy Controller has had a chance to load the appropriate template from the policy library. It will eventually reconcile. |
| 54 | + |
| 55 | + After a short time, in addition to the `Status` showing as `SYNCED` and the `Last_Synced_Token` matching the repo, there should also be a value of `INSTALLED` for `Policy_Controller`. |
| 56 | + |
| 57 | + |
| 58 | +1. Connect your kubectl instance to the newly created cluster: |
| 59 | + |
| 60 | + ```bash |
| 61 | + # get values from cluster that was created |
| 62 | + export CLUSTER_ZONE=$(terraform output -raw cluster_location) |
| 63 | + export CLUSTER_NAME=$(terraform output -raw cluster_name) |
| 64 | +
|
| 65 | + # then get creditials for it |
| 66 | + gcloud container clusters get-credentials $CLUSTER_NAME --zone $CLUSTER_ZONE --project $PROJECT_ID |
| 67 | +
|
| 68 | + ``` |
| 69 | + |
| 70 | +1. Verify that Config Connector addon is installed and configured: |
| 71 | + ```bash |
| 72 | + kubectl wait -n cnrm-system --for=condition=Ready pod --all |
| 73 | + ``` |
| 74 | + |
| 75 | + Note: The controller Pod can take several minutes to start. Once Config Connector is installed correctly, the output is similar to the following: |
| 76 | + |
| 77 | + ```bash |
| 78 | + pod/cnrm-controller-manager-0 condition met |
| 79 | + ``` |
| 80 | +1. It will take a while for the SQL database to be created. You can check on the status: |
| 81 | + ```bash |
| 82 | + kubectl describe sqlinstance -n wp |
| 83 | + ``` |
| 84 | + |
| 85 | +1. Finally, validate that Wordpress powered Cloud SQL database was created: |
| 86 | + |
| 87 | + ```bash |
| 88 | + curl -L $( kubectl get service wordpress-external -n wp -o=json | \ |
| 89 | + jq -r '.status["loadBalancer"]["ingress"][0]["ip"]') |
0 commit comments