OpenTF Language Documentation

This is the documentation for OpenTF's configuration language. It is relevant to users of OpenTF CLI, and TACOS (TF Automation and Collaboration Software). OpenTF's language is its primary user interface. Configuration files you write in OpenTF language tell OpenTF what plugins to install, what infrastructure to create, and what data to fetch. OpenTF language also lets you define dependencies between resources and create multiple similar resources from a single configuration block.

About the OpenTF Language​

The main purpose of the OpenTF language is declaring resources, which represent infrastructure objects. All other language features exist only to make the definition of resources more flexible and convenient.

An OpenTF configuration is a complete document in the OpenTF language that tells OpenTF how to manage a given collection of infrastructure. A configuration can consist of multiple files and directories.

The syntax of the OpenTF language consists of only a few basic elements:

resource "aws_vpc" "main" {
  cidr_block = var.base_cidr_block
}

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
  # Block body
  <IDENTIFIER> = <EXPRESSION> # Argument
}

• Blocks are containers for other content and usually represent the configuration of some kind of object, like a resource. Blocks have a block type, can have zero or more labels, and have a body that contains any number of arguments and nested blocks. Most of OpenTF's features are controlled by top-level blocks in a configuration file.
• Arguments assign a value to a name. They appear within blocks.
• Expressions represent a value, either literally or by referencing and combining other values. They appear as values for arguments, or within other expressions.

The OpenTF language is declarative, describing an intended goal rather than the steps to reach that goal. The ordering of blocks and the files they are organized into are generally not significant; OpenTF only considers implicit and explicit relationships between resources when determining an order of operations.

Example​

The following example describes a simple network topology for Amazon Web Services, just to give a sense of the overall structure and syntax of the OpenTF language. Similar configurations can be created for other virtual network services, using resource types defined by other providers, and a practical network configuration will often contain additional elements not shown here.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 1.0.4"
    }
  }
}

variable "aws_region" {}

variable "base_cidr_block" {
  description = "A /16 CIDR range definition, such as 10.1.0.0/16, that the VPC will use"
  default = "10.1.0.0/16"
}

variable "availability_zones" {
  description = "A list of availability zones in which to create subnets"
  type = list(string)
}

provider "aws" {
  region = var.aws_region
}

resource "aws_vpc" "main" {
  # Referencing the base_cidr_block variable allows the network address
  # to be changed without modifying the configuration.
  cidr_block = var.base_cidr_block
}

resource "aws_subnet" "az" {
  # Create one subnet for each given availability zone.
  count = length(var.availability_zones)

  # For each subnet, use one of the specified availability zones.
  availability_zone = var.availability_zones[count.index]

  # By referencing the aws_vpc.main object, OpenTF knows that the subnet
  # must be created only after the VPC is created.
  vpc_id = aws_vpc.main.id

  # Built-in functions and operators can be used for simple transformations of
  # values, such as computing a subnet address. Here we create a /20 prefix for
  # each subnet, using consecutive addresses for each availability zone,
  # such as 10.1.16.0/20 .
  cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 4, count.index+1)
}