Key Concepts

1. Default Workspace: When you initialize a Terraform project, a default workspace is created. This is where Terraform commands operate if no other workspace is specified.
2. Custom Workspaces: You can create additional workspaces to manage separate states for different environments or configurations.

Creating and Switching Workspaces

• Create a Workspace:
  sh

  Copy code

  terraform workspace new <workspace_name>

• List Workspaces:
  sh

  Copy code

  terraform workspace list

• Switch to a Workspace:
  sh

  Copy code

  terraform workspace select <workspace_name>

• Delete a Workspace:
  sh

  Copy code

  terraform workspace delete <workspace_name>


Example Use Cases

Example 1: Managing Multiple Environments

Suppose you have a Terraform configuration that sets up infrastructure for a web application. You want to manage separate environments (development, staging, production) using workspaces.

1. Create Workspaces:
   sh

   Copy code

   terraform workspace new development
terraform workspace new staging
terraform workspace new production

2. Configure Variables: Use workspace-specific variable files or conditionals within your configuration files to manage environment-specific settings.
   hcl

   Copy code

   variable "environment" {
   description = "The environment for this configuration"
   type = string
   }

   locals {
   environment = terraform.workspace
   }

   resource "aws_instance" "web" {
count = local.environment == "production" ? 3 : 1
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "web-server-${local.environment}"
}
}


3. Switch and Apply Configuration:
   sh

   Copy code

   terraform workspace select development
   terraform apply

   terraform workspace select staging
   terraform apply

   terraform workspace select production
terraform apply


Each workspace maintains a separate state file, ensuring that the resources for each environment are managed independently.

Example 2: Isolating Client Configurations

Imagine you are managing infrastructure for multiple clients, and you want to keep each client’s resources isolated.

1. Create Workspaces for Clients:
   sh

   Copy code

   terraform workspace new clientA
terraform workspace new clientB

2. Client-Specific Variables: Define variables or use conditionals based on the workspace name to configure resources for each client.
   hcl

   Copy code

   variable "client_name" {
   description = "The client for this configuration"
   type = string
   }

   locals {
   client = terraform.workspace
   }

   resource "aws_s3_bucket" "client_bucket" {
bucket = "myapp-${local.client}-bucket"
acl = "private"
}


3. Switch and Apply Configuration:
   sh

   Copy code

   terraform workspace select clientA
   terraform apply

   terraform workspace select clientB
terraform apply


This ensures that each client’s resources are managed separately, preventing any accidental overlap or interference.

Summary

Workspaces in Terraform provide a powerful way to manage multiple environments or configurations within a single codebase. By using workspaces, you can maintain separate state files and easily switch between different setups, whether for different environments (like development, staging, production) or different clients. This isolation helps to ensure that changes in one workspace do not affect resources in another, providing a more organized and secure way to manage infrastructure.

The post Workspaces in TerraforM appeared first on For all your terraform needs.

Prevent_Destroy in Terraform

Terraform has a few options for detecting and managing drift of resources.

 lifecycle {
    prevent_destroy = true
  }

However, these options only work with terraform – i.e. terraform only prevents and detects it’s own drifts…

Say you mark a resource as prevent_destory, it will respect that. However, it doesn’t stop an admin from deleting the resource through the console (of course, how would it know about that)?

Enter Terraform Refresh

Just need to remember to run refresh every time. From their documentation:

Terraform plan and apply operations run an implicit in-memory refresh as part of their functionality, reconciling any drift from your state file before suggesting infrastructure changes.

The post Manual Drift and terraform appeared first on For all your terraform needs.

Multiple Users and Terraform State file

terraform state pull  Always use terraform state pull prior to starting work on the tf project.

terraform state pull 

terraform state push

The post Multi User Edits and Terraform State file appeared first on For all your terraform needs.

Also read Multi developer Terraform and

Reusable Modules in Terraform 

One of the common questions that arises is that of combining Non Production Environments.

Typically, network administrators are driving this – so that they have a single place to manage all the non production networking elements.

However, IaC would have the opposite approach. To IaC, each environment should be codified – including any firewall rules and other security elements (NAT instances etc.) that are part of that environment. When planned in this way, it makese sense to have separate environments for DEVELOPMENT, TEST and STAGING.

Summary – Single NON PRODUCTION or MULTIPLE Non Production Environments?

There are a slew of other considerations that go into this – but those two are the more commonly debated ones.

Need an experienced Cloud Networking or a Cloud Data Protection Expert?  Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.

The post Production Terraform appeared first on For all your terraform needs.