Terraform Components

Terraform components allow you to deploy Terraform from a public or connected repo, to provision infrastructure resources in customer installs. Please refer to the Terraform reference for full configuration options.

​

Configuring a Terraform component

To configure a Terraform component, specify a repo, the required build paramaters and Dockerfile path.

resource "nuon_terraform_module_component" "terraform" {
  name   = "terraform"
  app_id = nuon_app.main.id
  terraform_version = "1.6.3"

  connected_repo = {
    directory = "terraform"
    repo      = "your-org/your-repo"
    branch    = "main"
  }
}

You can configure Terraform components to use either a public repo (using a public_repo block) or a private GitHub repo (using a connected_repo block). Read more about VCS configuration here.

​

TF Var / Env Var Configuration

You can configure both environment and terraform variables for a component using component variables.

These variables can access inputs, other components, the sandbox, and details on the install itself.

Some common examples:

resource "nuon_terraform_module_component" "terraform" {
  name   = "terraform"
  app_id = nuon_app.main.id
  terraform_version = "1.6.3"

  connected_repo = {
    directory = "terraform"
    repo      = "your-org/your-repo"
    branch    = "main"
  }

  var {
    name = "database_instance"
    value = "{{.nuon.installs.input.database_instance}}"
  }
}

​

State Management

All Terraform state is managed using an S3 backend, within the Nuon platform.

In order for Terraform modules to be compatible with Nuon, and not lose state, they must set the backend to the s3 backend.

terraform {
  required_version = ">= 1.3.7"

  backend "s3" {}

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
}

​

Execution and Permissions

The runner is responsible for executing Terraform, which means that Terraform is executed from within the Kubernetes cluster in aws-eks sandboxes, and from with ECS Fargate for aws-ecs sandboxes. In both cases, this is inside of the install network.

Since Terraform is executed from within the install sandbox, Terraform resources can access both the local Kubernetes cluster, or resources within the network (such as internal APIs).

The runner uses a dedicated IAM role defined in the sandbox when executing Terraform.