TrademarkTrademark
Features
Documentation

Getting Started with the Google Cloud Terraform Provider

everything about the Google provider for Terraform
Brendan ThompsonJanuary 1, 2024
Getting Started with the Google Cloud Terraform Provider
Key takeaways
  • The Terraform Google Cloud provider gives engineers a common declarative interface to define and deploy GCP resources through the GCP API.
  • The provider ships in two variants: google for the generally available version and google-beta for testing upcoming GCP features.
  • By default the provider authenticates using Application Default Credentials via gcloud; you can also use a service account key file, environment variables, or an OAuth 2.0 access token.
  • Setting project, region, and zone at the provider level supplies sensible defaults, while default_labels applies a label set to every resource the provider creates.

The Google Cloud provider in brief

The Terraform provider for Google Cloud Platform lets you 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 version
  • google-beta: the beta version

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

The sections below cover how to configure the provider and show a couple of examples of it in use.

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 so you can point it at a service account key file. This file must be in JSON format. You can also use environment variables. 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.

On top of those credential based approaches, you can also authenticate with an OAuth 2.0 access token. You set this token with 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 lets you set values like:

  • project
  • region
  • zone
  • default_labels

These aren't all the options, but they're the most useful.

Setting the project at the provider level means engineers don't need to set the project on each resource. You can still override the project at a resource level. Both region and zone let you set the defaults for where resources (e.g., virtual machines) get provisioned. The most useful option, in my opinion, is default_labels, which applies a set of default labels to every resource this instance of the provider creates. In other providers, that's not so easy to do.

Examples

Now that we know how the provider is configured, let's 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 sets the project, region and zone properties. That way, by default, we don't have to configure this at a resource level.

In the next example we'll run an instance of both the GA and Beta providers. This lets you configure resources differently, or use 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). The example doesn't show any configuration differences between GA and Beta for this resource type, but if there were any, this is how you'd handle them.

Where to go next

This post covered the basics of configuring the GCP provider for both GA and Beta, across authentication and general configuration. For authentication, the main mechanisms are ADCs and temporary OAuth access tokens. I generally recommend using ADCs configured automatically via GCE instance identity. For general configuration, we looked at how to 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.

About the author
Brendan Thompsonsolutions engineer at Scalr
Brendan Thompson is a solutions engineer at Scalr, specializing in Terraform and cloud infrastructure.