Getting Started with the Google Cloud Terraform Provider

Introduction

In this article, we look at the Terraform Provider for Google Cloud Platform. This provider allows for the definition, configuration and deployment of assets within a GCP account. Like all Terraform providers, the GCP provider acts as a common interface for engineers to interact with the GCP API. The use of a common interface means that engineers can interact with multiple cloud providers without having to maintain specific provider configuration technology knowledge. (e.g. AWS CloudFormation, Azure Bicep)

The Google provider is unique because it offers two versions:

• google – the general available
• google-beta – the beta version

Having the two variants of the provider enables engineers and organisations to test upcoming features. This early testing ensures that they’re effectively able to prepare, and utilise those changes.

The next step is to delve deeper into the provider. We will be covering:

• Configuration of the provider
• Example uses of the provider

Configuration

Configuration, for the purposes of this article, is broken up into Authentication and General Configuration.

Authentication

Like all providers on the Terraform Registry there are many ways to configure the provider. And, many ways to authenticate the provider to the given cloud platform. By default the provider will try to authenticate with GCP using User Application Default Credentials (ADCs) via the gcloud CLI utility.

The provider exposes the credentials argument to allow for the configuration of a path to a service account key file. This file must be in JSON format. Alternatively, the use of environment variables is also possible. The following shows available environment variables ordered by precedence:

• GOOGLE_CREDENTIALS
• GOOGLE_CLOUD_KEYFILE_JSON
• GOOGLE_KEYFILE_JSON

Authentication is automatically available when running Terraform commands if:

• they are being run on a GCE instance
• or on a workstation where the gcloud auth application-default login command has been executed.

These two solutions offer the simplest mechanism to authenticate with GCP.

In addition to the above credential based approaches to authenticating with GCP the use of an OAuth 2.0 access token is possible. This token can be configured by the access_token property or the GOOGLE_OAUTH_ACCESS_TOKEN environment variable. You can learn more about generating an access token here.

General Configuration

The provider allows for the setting of values, such as:

• project
• region
• zone
• default_labels

Whilst these may not be all the options, they are the most useful.

Setting the project at the provider level means that engineers do not need to set the project when creating resources. The project can still be overridden at a resource level. Both region and zone allow setting the defaults for where resources (e.g., virtual machines) are provisioned. The most beneficial configuration option – in my opinion – is default_labels this allows for applying a set of default labels to all resources provisioned by this instance of the provider. In other providers, this is not so easily done.

Examples

Now that we have an understanding of how the provider is configured we can look at a couple of examples.

For all of these examples, assume that the gcloud auth application-default login command has been run.

In the following code, we can configure the provider in its most basic form like:

provider "google" {
project = "example"
region  = "australia-southeast2"
zone    = "australia-southeast2-b"
}

The above example shows configuring the project, region and zone properties. This ensures that – by default – we do not have to configure this at a resource level.

In the next example we will look at having an instance of both the GA and Beta providers. Doing this allows for different configuration of resources, or different resources entirely.

provider "google" {
project = "example"
region  = "australia-southeast2"
zone    = "australia-southeast2-b"
}

provider "google-beta" {
project = "example"
region  = "australia-southeast2"
zone    = "australia-southeast2-b"
}

resource "google_container_cluster" "ga" {
provider = google

name = "ga-cluster"
 
initial_node_count = 1

timeouts {
create = "30m"
update = "40m"
}
}

resource "google_container_cluster" "beta" {
provider = google-beta

name = "beta-cluster"
 
initial_node_count = 1

timeouts {
create = "30m"
update = "40m"
}
}

In the above Terraform code we can see two instances of the google_container_cluster. The first uses the GA version of the GCP provider (google). The second uses the Beta version of the GCP provider (google-beta). Whilst the above example does not show any specific configuration differences for the given resource type between GA and Beta if there were this is how that can be achieved.

Summary

We have gone through the basics of configuration for the GCP provider, both GA and Beta. Looking at authentication and general configuration. When it comes to authentication, the main configuration mechanisms are through ADCs, and temporary OAuth access tokens. It is generally recommended to use ADCs configured automatically via GCE instance identity. With general configuration, we looked at how we can set sensible defaults for all resources provisioned by the Terraform Google provider. For all the details on the provider configuration, read through the Google Provider Configuration Reference.

‍