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.

Basic Git commands

• git init
• git status
• git checkout -b <branch-name>
• git add
• git commit -m "your message goes here"
• git remote add
• git push
• git pull
• git clone

The post GitHub Actions versus GitLab CI/CD appeared first on For all your terraform needs.

However, sometimes, instead of destroying resources, all you want to do is shut them down or disable them. This is also doable using remote-exec in terraform

Shutting down an EC2 instance on aws

resource "aws_instance" "app" {
  # ...

  provisioner "remote-exec" {
    when    = "destroy"
    inline = [ "systemctl stop service" ]
  }
}

The post Resource Shutdown via terraform appeared first on For all your terraform needs.

Is terraform a suitable tool for creating and managing cloud IAM resources? The short answer is – no. Especially, if you are going to be dealing with a large number of such creation requests.

Time taken to apply terraform for IAM

Check whether the IAM resource already exists – across all buckets that store state. This could take hours. Can you afford to wait for hours for a simple identity creation or a role assignment?

State drift – Console based roles and assignments

Certain IAM actions performed via the console will cause state drift. The next run of your IAM script will not pick these up – and essentially wipe them out.

Of course, if you have IAM creation etc. locked out for console users, you will not face this particular issue.

Summary

For smaller scoped IAM requests – say you have a dozen or so requests to deal with – terraform for IAM may be a workable solution.

The post Terraform for IAM resource creation appeared first on For all your terraform needs.

}

The issue has been fixed in version 3.3.0 of the azure provider

The post Error: retrieving `contact` for KeyVault: keyvault.BaseClient#GetCertificateContacts: Failure sending request: StatusCode=0 — Original Error: context deadline exceeded appeared first on For all your terraform needs.

The Terraform Data Block – Retrieving a Project Id for a GCP project

data “google_project” “project” {
}

output "project_number" {
  value = data.google_project.project.number
}

Terraform Destroy and the Data Block

When executing the terraform destroy command on our Terraform configuration, Terraform does not perform a destroy action on the resource called by the data block. It is a read only block.

The data block is also called when executing the terraform plan command, so your external resource must be present before you execute the terraform plan and terraform apply commands.

Searching for Projects using the terraform data block

One can apply a filter to search for specific projects – e.g. projects about to be deleted

data "google_projects" "my-organization-projs" {
  filter = "parent.id:23232323 lifecycleState:DELETE_REQUESTED"
}

data "google_project" "deletion-candidate" {
  project_id = data.google_projects.my-organization-projs.projects[0].project_id
}

Summary

Instead of hard coding IDs of resources, the terraform data block allows dynamic retrieval of resource IDs. It also allows searching / filtering based a filter inside the data block.

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 Retrieving Resource IDs in Terraform – The Terraform Data Block appeared first on For all your terraform needs.

To me, the primary use case is that I want to prompt a user to provide the value for the input variable. In that case, I HAVE to use variables.tf.. I simply define the variable and leave it’s value blank (of course, within the resource, this variable has to be a REQUIRED value).

The post tfvars versus variables.tf appeared first on For all your terraform needs.

Get-Command terraform

If this is pointing to the older terraform version, simply delete the older terraform.exe file.

ReInstall the newer version.  Now, do Get-Command again to see the executable path.

VS Code should also pick up whatever version exe is returned by the Get-Command terraform.

The post VS Code does not pick up the latest terraform version appeared first on For all your terraform needs.

The post VS Code Scripts Error: Cannot be loaded because running scripts is disabled on this system appeared first on For all your terraform needs.

The installed provider plugins are not consistent with the packages selected in the dependency lock file:
│ – registry.terraform.io/hashicorp/azurerm: the cached package for registry.terraform.io/hashicorp/azurerm x.y.x. (in .terraform\providers) does not match any of the checksums recorded in the dependency lock file
│ – registry.terraform.io/hashicorp/random: there is no package for registry.terraform.io/hashicorp/random 3.4.3 cached in .terraform\providers

Resolution

Step 1 – Look for this lock file (terraform.lock.hcl) in your current module. Delete it.

Step 2 – Re Run terraform init -upgrade

The post Error – ‘registry.terraform.io/hashicorp/local: there is no package for registry.terraform.io/hashicorp/local cached in .terraform/providers’ appeared first on For all your terraform needs.