6 Terraform with friends

 

This chapter covers

  • Developing an S3 remote backend module
  • Comparing flat vs. nested module structures
  • Publishing modules via GitHub and the Terraform Registry
  • Switching between workspaces
  • Examining Terraform Cloud and Terraform Enterprise

Software development is a team sport. At some point, you’ll want to collaborate on Terraform projects with friends and coworkers. Sharing configuration code is easy—any version-controlled source (VCS) repository will do. Sharing state is where it gets difficult. Until now, our state has always been saved to a local backend, which is fine for development purposes and individual contributors but doesn’t accommodate shared access. Suppose Sally from site reliability engineering (SRE) wants to make some configuration changes and redeploy. Unless she has access to the existing state file, there is no way to reconcile with what’s already in production. Checking in the state file to a VCS repository is not recommended because of the potential to expose sensitive information and also because doing so doesn’t prevent race conditions.

6.1 Standard and enhanced backends

6.2 Developing an S3 backend module

6.2.1 Architecture

6.2.2 Flat modules

6.2.3 Writing the code

6.3 Sharing modules

6.3.1 GitHub

6.3.2 Terraform Registry

6.4 Everyone gets an S3 backend

6.4.1 Deploying the S3 backend

6.4.2 Storing state in the S3 backend

6.5 Reusing configuration code with workspaces

6.5.1 Deploying multiple environments

6.5.2 Cleaning up

6.6 Introducing Terraform Cloud

6.7 Fireside chat

Summary