In the last post we went over the main setup of this blog. However, we can go the extra mile. If we ever want to deploy another instance of this site (or any other), we would have to repeat the process, potentially making a mistake. Plus, it is a great chance to learn something!

Enter Terraform, an Infrastructure as Code tool that allows us to define our resources declaratively. This is a repeatable and safe way to deploy our pipeline and build the resources we need to get the site running.

A Brief Introduction to the Nomenclature

First, resources are anything that can be created, managed, and destroyed by the tool for a given service provider. They can be VMs, storage, DNS entries, or even accounts. Resources may be customized through inputs, which are unbound variables set during execution from several sources, often unversioned.

Then we have providers, which are bindings through which Terraform will understand those resources and how to work with them.

As a result of the interactions with the providers and resources, a snapshot of the infrastructure is stored in the state, which can be stored locally and added to the version control system, or remotely in a centralized storage.

The state is populated by the outputs, which keep crucial information in variables for later use. These can be used as inputs to other resources, too.

Terraform also has modules, which we will not cover in this post, but are a way to re-use configuration files.

Terraform performs its job in several stages:

• Init: will load all the providers to talk to the services specified in the configuration files.
• Plan: will perform an initial assessment of the infrastructure and describe the actions needed to achieve the desired state.
• Apply: will perform these actions.
• Destroy: will discard the resources when they are no longer needed.

Basic Anatomy of a Terraform Project

As Terraform uses a declarative approach, there is no "blessed" main file that will be loaded first. However, it is conventional to use main.tf as a place to set up providers, variables.tf to declare variables, and *.auto.tfvars to load sensitive information that should not be under version control. The rest is usually free-form.

This is how I initially set up the project:

~/s/i/t/blog ❯❯❯ tree .
.
├── build.tf
├── dns.tf
├── main.tf
├── monitoring.tf
├── routing.tf
├── secret.auto.tfvars
├── storage.tf
└── variables.tf

0 directories, 8 files

• build.tf contains the Google Cloud Build trigger definition.
• dns.tf contains the DNS records and zones.
• main.tf contains the providers and some other config.
• monitoring.tf has some handy alerts regarding certificates and uptime.
• routing.tf describes the frontend and backend for the load balancer, and sets up things like CloudCDN.
• storage.tf creates and sets up the bucket with the relevant policies.
• variables.tf and secret.auto.tfvars hold variables and their values.

A Breakdown of the Pipeline

Before We Continue

Make sure to create a service account with limited access to the resources we are going to create, and to enable the Google Cloud Build app in GitHub, as well as registering the relevant service account in the Google Search Console and to follow the procedures needed for verifying the site.

Main

We need to add both google and google-beta to access some functionality in Google Cloud. As you can see, we are storing the state in another bucket, and we are using a service account with limited permissions to set up these resources.

Variables

These are the placeholders we are going to override or set up on future builds.

Storage

We created a bucket with public read policy so the load balancer could fetch the files. We now have to make this process repeatable:

CI/CD Pipeline

The pipeline is split in two. First, the trigger, that points to the cloudbuild.yaml file:

Then, the cloudbuild.yaml file proper, which is the one we saw in the last post:

Serving the site

We need to set up the domain name, IP, verify our ownership of the bucket, and point the A record.