#Aws cli workspaces how to#
I would highly recommend going through that to understand how to use AWS assume-role to provision resources in multiple AWS accounts. I haven’t seen a better article than the one below to explain this concept. For this reason, it is suggested that we create three separate workspaces named -Dev, Test, and Prod. In this case, we pass the value of terraform.workspace as key, and hence all the variables have values specifically for Dev, Test, and Prod. The lookup function () is used to pass the key to the variable and receive the value/s in return. In the “variables.tf” source file there are three variables of type = map. Map variable type and associated lookup() functions: The value of terraform.workspace is the value we set at last terraform workspace select $(workspacename) or terraform workspace new $(workspacename)Īt any particular time, there is only one workspace that is active in a repository. However, while using terraform, you can select a specific workspace before you proceed with managing resources if there are workspaces already created.
The selected workspace will have a * against its name.
Type terraform workspace list to check which workspace is selected. Hence after initialization, the value of terraform.workspace is `default`. In the previous links on terraform workspace, per HashiCorp Docs, every initialized working directory has at least one workspace (If you haven’t created other workspaces, it is a workspace named default ). Using terraform.workspace local variable: While navigating through the code, there are a few necessary concepts I want to mention about.
#Aws cli workspaces code#
I have committed the code into my GitHub repository – Working-with-Terraform-workspace-and-AWS. I have a detailed note on that at Creating IAM assume-role relationship between two AWS accounts. AWS IAM has a concept associated with such a use case, which creates a trust relationship between two accounts. The idea, in this project, was to automate terraform using credentials of a user in an AWS separate account (let’s call it Automation account) and be able to provision resources in -Dev, Test, and Prod AWS accounts. In all my previous terraform projects, I did not have to access across AWS accounts. I will provide the URL here once that is ready). Also, I used Azure DevOps pipelines for automation (in part two. These environments belonged to different AWS accounts… So Dev was a separate AWS account, Test was a separate AWS account, and so was Prod. And I want to use the same Terraform configuration (files) to provision these resources. I wanted to provision an AWS VPC and subnets for three environments -Dev, Test, and Prod. Let me expand on the use case I was working on to achieve this integration objective. Here is another interesting note on workspace internals. If you are new to terraform workspace, I’d suggest reading this article and also familiarizing yourself with the workspace commands. In part two I have a detailed walkthrough of the automation process. In this (part one of a two part) note, I explore the idea of integrating terraform workspace usage with Azure DevOps pipelines. There is already a good amount of information related to terraform workspace available, and hence, I am keeping out of discussing the concept behind it. The solution was to use terraform workspace. If you want to read, I ideated on that approach in my previous note and listed the limitation. Then, on the CD side, I thought that I’d run terraform plan and terraform apply on the same package. There are pros and cons on whether to include that folder in the build artifact. terraform folder, I ensured that the configuration was the same across all environments. terraform folder where versioned modules and provider plugins referenced by the terraform configuration are stored. So I thought, let’s run terraform init and terraform validate inside a CI build and package that into an artifact. Since there was nothing to build in terraform, I wanted to make sure the same terraform code was applied across all environments. Following a typical CI/CD model, my idea was to build once and deploy multiple. My objectives was to use Terraform to provision resources across environments in the AWS cloud infrastructure.
0 kommentar(er)
