Using Workspaces for Environments

Terraform workspaces help you manage multiple, distinct states for the same Terraform configuration. Think of them as separate environments like 'dev', 'staging', or 'prod'.

This means you can use one set of .tf files to deploy infrastructure to different places without changing your code, promoting reusability and consistency.

When you first initialize Terraform in a directory (using terraform init), you're automatically using the default workspace.

All your initial terraform apply operations will store their state in this default workspace, unless you create and select another one. It's always present!

To create a new environment, use the terraform workspace new command. This command also automatically switches your current context to the newly created workspace.

Let's create a dev workspace:

terraform workspace new dev

Terraform will then create a separate state for this dev environment.

You can see all available workspaces in your current configuration directory using the terraform workspace list command.

The currently active workspace will be marked with an asterisk (*), helping you keep track of your different environments.

terraform workspace list

To switch between existing workspaces, use the terraform workspace select command, followed by the workspace name. This command changes your active environment.

Let's switch back to the default workspace:

terraform workspace select default

Any subsequent Terraform operations will now target the default environment's state.

You can make your configurations dynamic by referencing the current workspace name using the built-in terraform.workspace variable. This is perfect for naming resources or setting environment-specific tags.

Try running this example. First, run terraform init, then terraform workspace new dev, and finally terraform apply. Observe the bucket name and tags.

The most critical aspect of workspaces is that each one maintains its own entirely separate state file.

This means resources deployed in your dev workspace will not interfere with those in your prod workspace, even if they're defined by the same configuration files. Terraform manages these state files in a hidden directory (.terraform/environments) within your working directory.

When an environment is no longer needed, you can delete its workspace using terraform workspace delete <name>.

• Important: You cannot delete the currently active workspace.
• Crucial: Always ensure you've destroyed all resources associated with that workspace using terraform destroy before deleting it. Otherwise, orphaned resources might remain!

terraform workspace select default
terraform workspace delete dev

While workspaces are great for minor variations of the same configuration, they aren't always the best choice. Consider these points:

• Workspaces: Ideal for small environmental differences (e.g., resource counts, tags) with the same core infrastructure design.
• Separate Directories: Better for significantly different infrastructure designs or when different teams manage entirely separate environments.

Choose the approach that best fits your project's complexity and team structure.

You've learned about Terraform workspaces. Let's test your understanding.

Great job! You've explored Terraform workspaces, a powerful feature for managing multiple environments from a single configuration. Remember these key takeaways:

• Workspaces provide isolated state files for different environments (e.g., dev, prod).
• Use terraform workspace new, list, and select to manage them.
• The terraform.workspace variable allows for dynamic, environment-specific configurations.
• Always destroy resources before deleting a workspace to avoid orphaned infrastructure.

This allows for flexible and organized infrastructure deployment!