Getting Started with the Google Cloud Terraform Provider

Introduction

This article looks at the Terraform provider for Google Cloud Platform, which you use to define, configure, and deploy resources in a GCP account. Like every Terraform provider, the GCP provider gives engineers a common interface to the GCP API. That common interface is the point: you can work across several clouds without learning a separate, provider-specific configuration language for each one (AWS CloudFormation, Azure Bicep, and so on).

The Google provider is a little different in that it ships in two versions:

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

Two variants let engineers and organisations try upcoming GCP features early, so they can prepare for the change before it lands in the GA provider.

Next we dig into the provider itself. We will cover:

• 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 most providers on the Terraform Registry, this one can be configured and authenticated in several ways. 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.