Terraform Configuration Management

This document includes details and best practices for managing your Nuon application configuration, using Terraform. Nuon is a standard terraform provider, and can be incorporated in your organization’s Terraform tool chain. This document is primarily targeted at new terraform users.

​

Why Terraform?

We opted to use Terraform as our primary configuration language, to help facilitate the natural evolution of application lifecycles. As your application evolves, and things such as new helm charts, terraform code and images are added, managing your Nuon configuration to map these to your app is a natural fit.

Furthermore, our Terraform provider allows us to easily version features and ensure a quality user experience while iterating the platform quickly.

​

Nuon Terraform vs App Terraform

Your Nuon application config in Terraform, is only for configuring your Nuon app and any installs you are managing for customers or testing purposes. The Nuon terraform provider only interacts with, and manages your tenant on our api. It does not directly interact with your customers, or application code.

Nuon also supports a terraform component, which allows you to connect your existing application terraform to any Nuon app. These terraform components will be deployed as part of your application in an install.

​

Terraform State Management

We recommend setting up some form of remote terraform state management, to prevent your Nuon configuration from being leaked, and to prevent conflicting changes.

There are many best practices around state management online, and this is beyond the scope of this article. However, for teams that are new to Terraform, we recommend one of the following state backends to get started:

• Hashicorp Terraform Cloud
• SpaceLift

​

Best Practices

The following best practices are recommended when working with the Nuon Terraform provider.

​

Multiple Apps

We recommend configuring your Terraform to create multiple apps, in order to offer multiple sandbox options. This can be done by parameterizing your terraform, or moving your application configuration into a module.

local {
  apps = [
    {
      name = "aws-eks"
      sandbox = "aws-eks"
    },
    {
      name = "aws-eks-byo-vpc"
      sandbox = "aws-eks-byovpc"
    },
  ]
}

resource "nuon_app" "main" {
  for_each = { for app in local.apps : app.name => app }

  name     = each.value.name
}

​

Sandbox Mode

It is recommended to use sandbox mode, to create a sandbox version of your apps for testing.

provider "nuon" {
  alias  = "sandbox"
  org_id = var.sandbox_org_id
}

provider "nuon" {
  org_id = var.org_id
}

​

Managing installs

If you plan on managing installs with the Nuon Terraform provider, please make sure to set dependencies on your application configuration:

resource "nuon_install" "east_1" {
  app_id = nuon_app.main.id

  name         = "example"
  region       = "us-east-1"
  iam_role_arn = "iam-role"

  depends_on = [
    nuon_app_sandbox.main,
    nuon_app_runner.main,
    nuon_job_component.job,
    nuon_helm_chart_component.helm,
  ]
}

This is recommended to ensure your installs are always created with the current application configuration, when auto deployed. Since installs can be created and evolved over time, this removes the need to go back and create a release for the configured components.