Terraform is used to manage our infrastructure in the cloud.
We use completely different terraform code for each cloud provider, under
This is much simpler than trying to abstract them away into a ‘lowest common denominator’ set of modules.
The source files for each provider we currently deploy with terraform are under the following directories in our
Each provider directory also has a
projects subdirectory where variables defining each cluster are stored.
A backend defines where Terraform stores its state data files in cloud storage (we use a GCP bucket for the majority of our deployments). Normally, we are using Terraform when logged in with our 2i2c accounts and there’s no need to explicitly define a backend.
But for some projects where we don’t have access to using our 2i2c accounts, e.g. universities that require us to have specific university-affiliated identities, we can configure different backends to access the terraform state stored in those projects. Working this way saves us the pain of trying to work with terraform using two different authentications.
These backend configs are stored in
Currently, we only implement a choice of backend for GCP deployments.
To initialize the backends, you need to run
terraform init command from within the directory where the source files of the specific provider you want to access are.
cd terraform/azure terraform init
Currently, since our GCP terraform config is the only one that uses different backends, an extra
-backend-config flag needs to be passed to the
init command to initialize.
For example, for our Pangeo projects, run:
cd terraform/gcp terraform init -backend-config=backends/pangeo-backend.hcl
If prior backend data exists in a
terraform.lock.hcl, you might see an
Error: Backend configuration changed when trying to initialize that backend. To reconfigure this backend, ignoring any saved configuration, add the
-reconfigure flag to the init command.
We use terraform workspaces
to maintain separate terraform states about different clusters we manage.
There should be one workspace per cluster, with the same name as the
file with variable definitions for that cluster.
Workspaces are defined per backend. If you can’t find the workspace you’re looking for, double check you’ve enabled the correct backend.
Workspaces are stored centrally in the
two-eye-two-see GCP project, even
when we use Terraform for projects running on AWS / Azure. You must have
access to this project before you can use terraform for our infrastructure.
How to change Terraform workspaces#
If the new workspace is stored in the same backend as the current workspace#
If you want to change to a different terraform workspace that is stored in the same backend that you initialised with, you can simply run:
terraform workspace select WORKSPACE_NAME
We recently renamed the
pilot-hubs repository to
infrastructure, however we have not yet renamed the Terraform projects, so they are still named
For example, if you were working in the
pilot-hubs workspace but want to change to
justiceinnovationlab, these are both stored in the same backend and so the command looks like:
terraform workspace select justiceinnovationlab
For the majority of day-to-day work, this will be the prevalent workflow provided you have initialised terraform with
terraform init -backend-config=backends/default-backend.hcl -reconfigure
If the new workspace is stored in a different backend to the current workspace#
To change between workspaces that are stored in different backends, terraform will need to be reinitialised in order to pick up the new backend. The commands, therefore, are:
terraform init -backend-config=backends/<REQUIRED_CONFIG>.hcl -reconfigure terraform workspace select WORKSPACE_NAME
For example, if you were working on our
pilot-hubs, with our default backend initialised, but wanted to change to working on our Pangeo deployments, the commands would look as follows:
terraform init -backend-config=backends/pangeo-backend.hcl -reconfigure terraform workspace select pangeo-hubs