Create and use no-code modules

No-code provisioning in Terraform Cloud lets users deploy infrastructure resources without writing Terraform configuration. This lets organizations adopt a self-service model by giving developers with limited infrastructure knowledge a way to deploy the resources they need.

Modules can codify your infrastructure standards and architecture requirements, making it easier for Terraform configuration authors to deploy infrastructure that complies with best practices. No-code provisioning lets users deploy infrastructure in modules without writing any Terraform configuration, which makes your standards even easier to comply with, and removes the dependency on infrastructure teams or ticketing systems to give developers their required resources.

In this tutorial, you will review a no-code module that complies with our architectural recommendations. Then, you will publish it to your Terraform Cloud private registry and use it to deploy resources. In the process, you will review the no-code workflow from the perspective of two personas: the module author, and the module user.

Prerequisites

This tutorial assumes that you are familiar with the Terraform and Terraform Cloud workflows. If you are new to Terraform, complete the Get Started collection first. If you are new to Terraform Cloud, complete the Terraform Cloud Get Started tutorials first.

In order to complete this tutorial, you will need the following:

• A Terraform Cloud account with Plus edition features.
• An AWS account.

Fork example repository

Fork the example repository for this tutorial, but rename the repository to terraform-aws-rds to satisfy module repository naming constraints in Terraform Cloud.

Then, clone your fork of the repository, replacing USER with your own username.

$ git clone git@github.com:USER/terraform-aws-rds.git

Navigate to the repository directory.

$ cd terraform-aws-rds

Review module design recommendations

Unlike standard module deployment, users do not provision infrastructure in no-code modules by referencing them in written configuration. Because of this, you must write no-code modules in a specific way.

No-code modules must follow standard module structure and define all resources in the root repository of the directory. This lets Terraform Cloud inspect the module, generate documentation, track resource usage, and parse submodules and examples. It will display this data in your Terraform Cloud registry.

Open main.tf and review the no-code module configuration. This module definition uses the public vpc module to create networking resources, then deploys an RDS instance, subnet group, and security group within that designated VPC.

Declare provider block within module

Notice that the module configuration includes a declaration for the AWS provider.

provider "aws" {
  region = us-east-2
}

data "aws_availability_zones" "available" {}
##...

The main difference between no-code modules and ordinary modules is that the no-code workflow requires declaring provider configuration within the module itself. Authors of standard modules usually avoid including the provider configuration within the module because it makes the module incompatible with the for_each, count, and depends_on meta-arguments. Since users will not reference no-code modules in written configuration, there is no risk of this conflict.

When users provision infrastructure with a no-code module, Terraform Cloud will automatically launch a new workspace to manage the module's resources. Because no-code modules contain their provider configuration, organization administrators must also enable automatic access to provider credentials. You will review options for configuring credential access later in this tutorial.

Limit configurable variables and attributes

Because no-code ready modules target users who are unfamiliar with Terraform and infrastructure management, reduce the number of decisions the user needs to make. A well-designed no-code module is scoped to a specific use case and limits the number of variables a user needs to configure.

Potential use cases for this module are testing changes to database schemas, or general load testing. Because of this, the module configuration makes assumptions about expected usage, but still gives users the flexibility to configure a few resource attributes through input variables.

For example, the aws_security_group.rds defines a single ingress rule, scoping inbound traffic to the instance to a single CIDR block, representing a hypothetical internal VPN.

resource "aws_security_group" "rds" {
  name   = "education_rds"
  vpc_id = module.vpc.vpc_id

  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["192.80.0.0/16"]
  }

  egress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "education_rds"
  }
}

It also enforces logging for all connections to the database through a parameter group.

resource "aws_db_parameter_group" "education" {
  name   = "education"
  family = "postgres13"

  parameter {
    name  = "log_connections"
    value = "1"
  }
}

The RDS instance configuration itself uses multiple variable values to allow developers to configure the database as needed. However, it hardcodes the engine, engine_version, instance_class, and allocated_storage attributes to satisfy organizational requirements.

The configuration also uses the random_pet resource to append a unique suffix to the provider database name. RDS instance names must be unique within a region, so this modification protects users from provisioning errors in case the database identifier is already in use.

provider "random" {}

resource "random_pet" "random" {
  length = 1
}

resource "aws_db_instance" "education" {
  identifier             = "${var.db_name}-${random_pet.random.id}"
  instance_class         = "db.t3.micro"
  allocated_storage      = 5
  engine                 = "postgres"
  engine_version         = "14.1"
  username               = var.username
  password               = var.db_password
  db_subnet_group_name   = aws_db_subnet_group.education.name
  vpc_security_group_ids = [aws_security_group.rds.id]
  parameter_group_name   = aws_db_parameter_group.education.name
  publicly_accessible    = true
  skip_final_snapshot    = true
}

Open variables.tf to review the variable configuration. These are the limited variable values that users will have to enter to deploy the module.

variable "db_name" {
  description = "Unique name to assign to RDS instance"
}

variable "db_username" {
  description = "RDS root username"
}

variable "db_password" {
  description = "RDS root user password"
  sensitive = true
}

The no-code provisioning workflow prompts users to set values for the module's input variables that do not have defaults before creating the new workspace and deploying resources. Users will be able to override any variable values with defaults in future runs. The new workspace will also access any global variable sets in your organization, giving you another way to set configuration defaults.

Publish no-code ready module

Module repositories published to the Terraform registry must follow the name format terraform-<provider>-<name> and have semantically versioned tags associated with releases.

First, create a tag for your module.

$ git tag 1.0.0

Then, push the tag.

$ git push --tags
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/user/terraform-aws-rds.git
 * [new tag]         1.0.0 -> 1.0.0

Navigate to your fork of the example repository in Github. Under Releases, click Create a new release. Create a release for your 1.0.0 tag.

Next, go to your organization's Terraform Cloud registry, click Publish, then select Module.

Select your version control provider, then select your terraform-aws-rds repository.

On the Add Module screen, check Add Module to no-code provision allowlist. Then, click Publish module.

When you enable no-code provisioning on a module, Terraform Cloud displays a No-Code Ready badge next to the module name and adds a Provision Workspace button to the details page.

Now, select Configure Settings , which takes you to the No-code provisioning settings page.

Select 1.0.0 (latest) from the Select module version dropdown. When users provision a workspace for this module, Terraform will deploy this module version.

Then, select Add dropdown options for the db_username variable. Enter education in the text box.

Finally, select Save.

Create a project

Navigate to your organization's Projects & workspaces landing page. Click New in the top right corner and select Project in the dropdown menu.

Enter No-Code as the project name, then click Create.

Create provider credentials variable set

Navigate to the Variable Sets page for your organization and create a new variable set.

Enter No Code Credentials for the name.

Scroll down to the Variable set scope section and select Apply to specific projects and workspaces. Then, select the No-Code project from the Apply to projects dropdown.

Find the AWS credentials you want to use for the workspaces in this project, or create a new key pair in the IAM console. Then, set the credentials as variables using +Add Variable.

Now, click Create variable set.

Deploy no-code ready module

The preceding sections described the no-code workflow for the module designer and publisher. Now, you will follow the deployment process for a module user.

Navigate to the Registry for your organization and select the rds module.

Click the Provision workspace button on the module's details page to launch the workflow. Terraform Cloud prompts you for values for the input variables. Notice the dropdown for the db_username variable contains the value you predefined.

Set the variables to the following:

Then, click Next: Workspace settings.

On the workspace settings page:

• Set the workspace name to learn-terraform-no-code-provisioning.
• Select the No-Code project from the Project dropdown.
• In the Apply methods section, leave the method as Auto-apply. Terraform Cloud will automatically apply successful runs in the workspace, including the first one that will launch on workspace creation. The manual apply method would automatically launch a plan in the new workspace, and then prompt operators to manually approve the plan.

Click Create workspace to create the workspace and deploy your resources.

Review no-code workspace

When you create the workspace, Terraform Cloud launches a new run. Because of the auto-apply, it automatically creates your infrastructure.

The workspace indicates that it uses the no-code workflow. It also highlights the outputs for the configuration to give users easy access to the resource attributes they need.

A no-code workspace has less functionality than a normal workspace. Because you cannot interact with the Terraform configuration for the workspace, you can only change the infrastructure by editing the variable values. You cannot apply configuration changes to existing no-code workspaces. If the module’s configuration changes, users must destroy the workspace and create a new one to provision resources with the updated configuration.

Clean up your infrastructure

Destroy the resources you created as part of this tutorial to avoid incurring unnecessary costs. Navigate to your Workspace Settings, then to Destruction and Deletion. Select Queue destroy plan to delete your resources. Terraform Cloud will automatically apply the run.

Optionally delete the workspace, No-Code project, No-Code Credentials variable set, and the module from your Terraform Cloud organization.

Next steps

In this tutorial, you published and used a no-code module, which let you automatically deploy Terraform resources without writing configuration for the workspace. Along the way, you reviewed the design recommendations and requirements for no-code modules.

Review the following resources to learn more about how Terraform can support your organization's workflows.

• Review the documentation for no-code provisioning.
• Learn how to configure optional object attributes for modules.
• Learn how to enforce OPA policies and detect drift with Terraform Cloud.