Multi-Environment Deployment Workflow with env0’s Terraform Provider

Infrastructure is typically built up from multiple layers, starting with the network to the compute layer. In order to deploy your K8s cluster, you typically need your subnets and VPCs defined ahead of time. As I talk to customers about their IaC deployment challenges, I often get asked how env0 can help with orchestrating dependencies amongst these multi-tiered, multi-layered infrastructure deployments.

Today, I’d like to share how a simple, yet powerful, tweak to our TF provider env0_environment resource gives us a method of orchestrating these complex workflows. By introducing a “wait_for” flag in our env0_environment resource, we can now define multiple env0 environments that essentially depend on one another, and also ensure that they get deployed synchronously by Terraform.

Background

env0 Terraform Provider

We’re excited to announce the release of v1.0 of our Terraform Provider! If you’re not familiar with the env0 Terraform Provider, it is simply a way to define your env0 configuration as Terraform code. We have resources for creating Projects, Templates, and most importantly, Environments. For example, this will allow you to create a project factory from within env0 as you onboard new teams.

Terraform - lifecycle

Terraform has a “depends_on” meta-argument flag that helps you explicitly define resource dependencies. Typically, this is optional, as Terraform will automatically calculate the dependencies based on variable and module dependencies. However, with env0, Terraform doesn’t know about the environment dependencies, unless we explicitly use this flag. Even then, env0 environments will simply be deployed synchronously, despite the usage of “depends_on.”

Introducing the “wait_for” flag

By introducing the “wait_for” flag, we can force the env0 Terraform provider to wait for the environment creation before deploying the next resource.

Here’s a simple example of Terraform code that utilizes the wait feature (check the code here).

resource "env0_environment" "infra-base" {
name                       = "infra-base-${var.name}"
 project_id                 = data.env0_project.project.id
 template_id                = "84727784-587b-4e58-83ea-b0e2f9c872bd"
 revision                   = "main"
 approve_plan_automatically = true
 force_destroy              = var.force_destroy
 wait_for                   = "FULLY_DEPLOYED"
}

resource "env0_environment" "infra-mid" {
 name                       = "infra-mid-${var.name}"
 project_id                 = data.env0_project.project.id
 template_id                = "8c86ee3e-c42d-4f7b-b7be-8513f20fcc65"
 revision                   = "main"
 approve_plan_automatically = true
 force_destroy              = var.force_destroy
‍ wait_for                   = "FULLY_DEPLOYED"
 depends_on                 = [env0_environment.infra-base]
‍}

resource "env0_environment" "infra-top" {
 name                       = "infra-top-${var.name}"
 project_id                 = data.env0_project.project.id
 template_id                = "5cfcb877-bdf2-402f-a5fc-343d2e1a8f8e"
 revision                   = "main"
 approve_plan_automatically = true
‍ force_destroy              = var.force_destroy
‍ depends_on                 = [env0_environment.infra-mid]
‍}

Here's a short video of what this looks like in real life.

Other Exciting Features in TF Provider 1.0 release

• AWS, GCP, Azure Credentials, and associated Cost Credentials
• Notifications - Slack and Teams integration
• Private Module Registry resource