Multiple environments in Terraform? No worries, use workspaces

When you want to manage (create, modify, and remove) your infrastructure, getting started with Terraform is easy. Just create files ending with .tf containing the description of the resources you want to have.

For example, if we want to create a small infrastructure in GCP cloud provider:

A bastion host.
A VPC
A firewall

We just need to create some .tf files like this:

bastion-host.tf
vpc.tf
variables.tf
output.tf
main.tf
firewall.tf

bastion-host.tf:

resource "google_compute_instance" "mservice_bastion" {
  name         = "mservice-bastion"
  machine_type = "n1-standard-1"
  zone         = var.gcp_zone

  tags                      = ["ssh-mservice"]
  allow_stopping_for_update = true

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }

  network_interface {
    subnetwork = module.vpc.subnetwork

    access_config {
      // Ephemeral IP
    }
  }

  metadata = {
    service = "mservicebastion"
  }

  service_account {
    scopes = [
      "userinfo-email",
      "compute-rw",
      "storage-rw",
      "https://www.googleapis.com/auth/cloud-platform",
      "https://www.googleapis.com/auth/cloud-platform.read-only",
      "https://www.googleapis.com/auth/cloudplatformprojects",
      "https://www.googleapis.com/auth/cloudplatformprojects.readonly",
    ]
  }
}

vpc.tf:

resource "google_compute_network" "tag_network" {
  name                    = var.gcp_vpc_name
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "tag_subnetwork" {
  name          = var.gcp_vpc_subnet_name
  ip_cidr_range = "10.1.0.0/16"
  region        = var.gcp_region
  network       = google_compute_network.tag_network.self_link

  secondary_ip_range {
    range_name    = format("%s-pod-range", var.cluster_name)
    ip_cidr_range = "10.2.0.0/20"
  }

  secondary_ip_range {
    range_name    = format("%s-svc-range", var.cluster_name)
    ip_cidr_range = "192.168.0.0/24"
  }
}

firewall.tf

resource "google_compute_firewall" "mservice_allow_ssh" {
  name      = "mservice-allow-ssh"
  network   = module.vpc.network_name
  direction = "INGRESS"

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["ssh-mservice"]
}

variables.tf

variable "gcp_project" {
  type    = string
  default = "falkinton-0991"
}

variable "gcp_region" {
  type    = string
  default = "us-central1"
}

variable "gcp_zone" {
  type    = string
  default = "us-central1-a"
}

variable "gcp_network" {
  type    = string
  default = "mservice-network"
}

variable "gcp_subnetwork" {
  type    = string
  default = "mservice-subnetwork"
}

variable "cluster_name" {
    type = string
    default = "falkinton-test"
}

main.tf:

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  zone    = var.gcp_zone
}

provider "google-beta" {
  project = var.gcp_project
  region  = var.gcp_region
  zone    = var.gcp_zone
}

Now we need to initialize Terraform (only the first time), generate a plan, and apply it.

$ terraform init
Initializing the backend...
Initializing provider plugins...
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

The init command will initialize your working directory which contains .tf configuration files.

It’s the first command to execute for a new configuration, or after doing a checkout of an existing configuration in a given git repository for example.

The init command will:

Download and install Terraform providers/plugins
Initialize backend (if defined)
Download and install modules (if defined)
Since Terraform v0.11+, instead of doing a plan and then apply it; if you are in interactive use, now you just need to execute terraform apply. The command will create the plan, prompt the user, and if the answer Yes is written, Terraform apply the plan and make all the changes.

Nice, you already can create your infra, but you work alone, in only one environment.

Tfstate Should Be Stored in Remote

In a company or in an OSS project, you don’t work alone so you need to stop to store the tfstate locally and start to store it remotely, in the “cloud”, to share it.

For information or reminder, a tf state is a snapshot of your infrastructure from when you last ran terraform apply. By default, the tfstate is stored locally in terraform.tfstate file. But when we work in team, we must store the tfstate remotely:

We now create a backend resource in order to store the tfstate in a bucket s3 and encrypt it.

backend.tf:

terraform {
  backend "gcs"{
    bucket      = "tagx"
    prefix      = "tf-tagx-state"
  }
}

When we created the gcs bucket resources in which we put our tfstate, we activated the versioning. It’s not an error or a copy-paste. It’s recommended to enable versioning for state files. GCP buckets have that capability, which you can leverage since Terraform has a backend for it. Imagine, suddenly, your state file got corrupted. Thanks to the state files versioning, you can use an older state and breathe.

We created before our tfstate file so we need to convert local state to remote state (and store our state in the s3 bucket we created):

terraform state push

Come in, Workspaces

Before the Terraform workspaces feature, in order to handle with multiple environments, the solution was to create one folder per environment/cloud provider account and put it .tf files. The solution was not convenient, easily maintainable with duplicate .tf files.

Since Terraform v0.10+, to manage multiple distinct sets of infrastructure resources/environments, we can use Terraform workspace.

The Terraform CLI for workspaces offers several commands:

$ terraform workspace list // The command will list all existing workspaces
$ terraform workspace new <workspace_name> // The command will create a workspace
$ terraform workspace select <workspace_name> // The command select a workspace
$ terraform workspace delete <workspace_name> // The command delete a workspace

With the CLI we can easily create, select and list workspace like this:

$ terraform workspace new dev
Created and switched to workspace 'dev'
$ terraform workspace new preprod
Created and switched to workspace 'preprod'
$ terraform workspace new prod
Created and switched to workspace 'prod'

Select the dev workspace:

terraform workspace select dev

With this workspace configuration, when a terraform apply is successfully executed, your tfstate will be now stored in the good environment folder in the gcp bucket:

env:/
    dev/
       state.tfstate    
    preprod/
        state.tfstate    
    prod/
        state.tfstate

Perfect, because it’s a best practice to separate tfstate per environment.

Like you saw, with Terraform workspaces, we manage easily several/multiple environments without headaches.

Thank you for reading/sharing....

Blog

Multiple environments in Terraform? No worries, use workspaces

Falcon

Tfstate Should Be Stored in Remote

Come in, Workspaces

Join Our Newsletter. No Spam, Only the good stuff.

Related