HashiCorp Cloud Platform (HCP) recently elaborated on automating the Terraform workspace creation using a TFE provider and building an onboarding module. This approach addresses the challenge of manual workspace creation, which has been a bottleneck for teams scaling their operations.
Emmanuel Rousselle, staff solutions architect at HashiCorp, discussed the approach in a blog post. To illustrate how to automate the creation of HCP Terraform workspaces for an application team, Rousselle used an example of a fictitious tech company, HashiCups.
Associating with a common real-world scenario, HashiCups has successfully built its initial cloud landing zones using HCP Terraform. As the platform team begins onboarding an application team, they recognize the need to simplify the process. The traditional method of manually creating workspaces proves inefficient and prone to errors, prompting the team to explore automation solutions.
The process starts with a thorough assessment of requirements. The platform team meets with the application team to understand their familiarity with HCP Terraform workspaces, the environment landscape, and who should have permission to modify infrastructure configurations. Workspaces in HCP Terraform are isolated environments where teams manage specific infrastructure resources, each maintaining its state file for tracking changes.
The application team then adopts a three-environmental landscape, which requires the creation of three workspaces. The platform team also outlines additional requirements for HCP Terraform workspace default settings. Each application team is to have two distinct groups: one responsible for workspace administration and another with the necessary permissions to use the workspaces.
The onboarding module creation begins with developing key configuration files. The variables.tf file defines essential variables, including application_id, admin_team_name, user_team_name, and environment_names. The environment_names variable is validated to include a prod environment, aligning with organizational requirements.
Next, the main.tf file is used to define workspaces and team permissions.
resource "tfe_workspace" "workspace" {
for_each = toset(var.environment_names)
name = "${lower(var.application_id)}-${lower(each.value)}"
description = "Workspace for the ${each.value} environment of application ${var.application_id}"
allow_destroy_plan = each.value == "prod" ? false : true
}
data "tfe_team" "admin_team" {
name = var.admin_team_name
}
data "tfe_team" "user_team" {
name = var.user_team_name
}
resource "tfe_team_access" "admin_team_access" {
for_each = toset(var.environment_names)
workspace_id = tfe_workspace.workspace[each.value].id
team_id = data.tfe_team.admin_team.id
access = "admin"
}
resource "tfe_team_access" "user_team_access" {
for_each = toset(var.environment_names)
workspace_id = tfe_workspace.workspace[each.value].id
team_id = data.tfe_team.user_team.id
access = "write"
}An example of main.tf file (Source)
For the production environment, the workspace is configured to prevent destroying plans adhering to organizational policies. The workspace naming follows a specific convention using string interpolation. The configuration utilizes data sources to fetch team information, though an alternative approach involves using team IDs for input variables, which can simplify the code but may reduce readability.
The Terraform module can accommodate different teams' environments using variable fields instead of hardcoded values. Additionally, Rousselle has elaborated on the Terraform tests, which reside under the tests directory to validate environment names and enforce consistent naming conventions. These tests ensured workspace names were in lowercase and critical environments like production were always included.
Furthermore, test suites are created for several key functions. They start by providing a valid TFE provider configuration and ensuring all necessary prerequisites are in place. The tests then verify that invalid environment landscapes, such as those missing the prod environment or using incorrect names like production, are correctly detected and cause the plan operation to fail.
As a side, HashiCorp has also announced the general availability of Terraform 1.11, which is ready to be used with HCP Terraform. This latest version introduces write-only arguments, allowing users to utilize ephemeral values in specific managed resource arguments, enhancing flexibility and functionality.
Finally, two essential files support the module's documentation: README.md and CHANGELOG.md. The README.md file gives users detailed instructions on the module's purpose, usage, input variables, outputs, and specific requirements or dependencies. Meanwhile, the CHANGELOG.md file tracks all significant changes and version updates over time, ensuring transparency and ease of maintenance for future users.
About the Author
