OpenTofu Tutorial – Getting Started, How to Install & Examples

Great news for the DevOps and Infrastructure as Code world – OpenTofu’s first stable release is here! 

This OpenTofu tutorial includes:

1. What is OpenTofu?
2. Why OpenTofu matters in the DevOps ecosystem?
3. How to install OpenTofu
4. How to migrate from Terraform to OpenTofu
5. Basic OpenTofu components with examples
6. Key features of OpenTofu
7. Common problems and solutions
8. OpenTofu best practices
9. Advanced OpenTofu features
10. OpenTofu registry
11. Using OpenTofu with Spacelift

OpenTofu is an open-source project that serves as a fork of the legacy MPL-licensed Terraform. It was developed as a response to a change in HashiCorp’s licensing of Terraform, from Mozilla Public License (MPL) to a Business Source License (BSL), which imposed limitations on the use of Terraform for commercial purposes. As an alternative, OpenTofu aims to offer a reliable, community-driven solution under the Linux Foundation.

OpenTofu ensures that one of the core and most popular IaC tool remains open-source. With this you not only get an open-source Terraform alternative, but this also ensures the fact that the later deployment of OpenTofu will take advantage of the community’s feedback. 

In the DevOps world, OpenTofu’s significance is amplified by its capabilities of infrastructure management. It continues the legacy of Terraform by supporting infrastructure as code (IaC). This enables teams to automate and efficiently manage infrastructure deployment, crucial for enhancing operational scalability and reliability.

OpenTofu’s backward compatibility with Terraform’s infrastructure also means organizations deeply integrated with Terraform can transition without disrupting their existing workflows. This compatibility, coupled with the broad support from various organizations in the DevOps community, positions OpenTofu not just as a tool but as a potential standard in the evolving landscape of DevOps, supporting its principles of automation, collaboration, and continuous improvement.

Let’s see different ways you can install OpenTofu.

Alpine Linux

For Alpine, you could either install OpenTofu from the Alpine Testing repository or install the apk directly.

To install OpenTofu from the repository you can run the following command:

To install the apk directly, you will first have to download one of the versions from here, and run the following command:

You can reference the official OpenTofu docs for more details here.

Ubuntu/Debian

To add the repositories, you will need to install some tooling, that should be mostly available on Debian systems:

After this, you will need to ensure you have a copy of the OpenTofu GPG key.

When you are done with this, create the OpenTofu source list:

In the end, install OpenTofu by running:

RHEL/Suse/Fedora

For rpm based systems, you will first need to create the repo:

If you are using yum, save this to /etc/yum.repos.d/opentofu.repo, and if you are using zipper, save this to /etc/zypp/repos.d/opentofu.repo.

After you have created the repo, run the following commands:

Linux (Install via Snap)

MacOS

The OpenTofu package is available in the Homebrew Core repository so you can install it by running the following command:

Portable Binary – Windows

Portable Binary – Linux/MacOS

It is really easy to migrate from Terraform to OpenTofu. At the moment of writing, OpenTofu acts as a drop-in replace for Terraform.

What you need to do to perform the migration is simply install OpenTofu using one of the methods mentioned above that works for your operating system, and after that run:

This will ensure that you will use the OpenTofu registry for your OpenTofu providers.

After that, all of the Terraform commands that you love and use can be performed using the tofu binary.

As OpenTofu was created as a Terraform fork and has backward compatibility with Terraform versions up to 1.6, it has the same basic components.

Provider

OpenTofu providers are essentially plugins enabling OpenTofu to interact with various infrastructure resources. They serve as a bridge, translating OpenTofu configurations into corresponding API calls, thereby allowing OpenTofu to effectively manage a diverse range of resources in different environments. These providers come equipped with their own unique resources and data sources, which can be managed and set up through OpenTofu.

A common misconception about OpenTofu providers is that they are exclusive to cloud service providers like Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), or Oracle Cloud Infrastructure (OCI). However, this is not the case. OpenTofu providers extend beyond these cloud vendors to include others such as Template, Kubernetes, Helm, Spacelift, Artifactory, VSphere, and Aviatrix, among others.

Each provider is tailored with its specific resources and data sources. For instance, the AWS provider includes resources to handle EC2 instances, EBS volumes, and ELB load balancers, all manageable via OpenTofu.

Example Oracle Cloud Provider

Resource

Resources in OpenTofu refer to the infrastructure elements that OpenTofu can manage. This includes, but is not limited to, virtual machines, virtual networks, DNS entries, and pods. Each of these resources is defined by a specific type, such as “aws_instance,” “google_dns_record,” “kubernetes_pod,” or “oci_core_vcn.” Additionally, these resources come with a range of configurable properties like instance size or VCN CIDR.

OpenTofu facilitates creating, updating, and deleting these resources. It automatically manages the dependencies among them to ensure they are established in the appropriate sequence. Furthermore, if desired, you can introduce explicit dependencies between certain resources using the “depends_on” feature. This capability underscores OpenTofu’s flexibility and control in handling complex infrastructure setups.

Example resource

Datasource

A data source in OpenTofu is a configuration element designed to fetch data from an external source. This data can then be utilized as a parameter within resources during their provisioning. When we mention external sources, we are encompassing a variety of origins such as infrastructure set up manually, and resources established through other OpenTofu configurations, among others.

These data sources are specified within the providers relevant to OpenTofu and are referenced using a distinct block called data. The structure and documentation for a data source closely resemble those of a resource. Therefore, if you’re already proficient with resource configuration in OpenTofu, adapting to using data sources should be straightforward.

For example, consider a data source that retrieves information about an existing AWS VPC (Virtual Private Cloud). You can define this data source in OpenTofu to gather details such as the VPC’s ID or CIDR block, which can then be used to configure related AWS resources like subnets or security groups within your OpenTofu configuration. This allows for seamless integration and management of both existing and new infrastructure components.

Example Datasource

Output

An output in OpenTofu is a feature that enables you to conveniently view the value of a specific data source, resource, local, or variable after OpenTofu has executed changes to the infrastructure. This output is defined in the OpenTofu configuration file and can be accessed using the opentofu output command, but only after an opentofu apply has been executed. Additionally, outputs can be employed to share various resources within a module.

Outputs don’t rely on any specific provider – they are a unique type of block that operates independently. The key parameters that an output supports include value, where you define what you want to display, and description (which is optional), where you explain the output’s purpose.

Example Output

Variable

OpenTofu variables provide a way to parameterize configuration files, thereby enhancing their flexibility and reusability. These variables are declared in OpenTofu configurations and can be used to input diverse values without modifying the core configuration. For instance, a variable might be used to define the size of a virtual machine, the name of a resource, or the region in which a resource is deployed.

As in all programming languages, when we are defining a variable, we have to assign it a type, or in some cases, it automatically infers a type.

Supported variable types in OpenTofu:

• Primitive

– String

– Number

– Bool

• Complex

– List 

– Set

– Map

– Object

• Null – Represents absence

There is also the any type, which represents any type of resource, but its usage is not recommended as it will make your code harder to maintain.

Example variables

Local

Local variables in OpenTofu are a convenient way of assigning a value to an expression. They are defined into a locals block, and are referenced by prefixing them with a “local”. 

Expanding on this, locals in OpenTofu act as an intermediary layer in your configurations, helping to simplify and clarify expressions. They can be particularly useful for reducing repetition and making your code more readable and maintainable. This capability to define and manipulate a wide range of attributes and operations through locals is essential for crafting efficient and streamlined infrastructure code. It ensures that OpenTofu configurations remain not just functional but also organized and easy to understand, an important consideration in the evolving landscape of infrastructure management.

Example Local

Provisioners

OpenTofu provisioners are distinct from providers and serve a different purpose. They allow you to execute various commands or scripts either on your local machine or on a remote machine. Additionally, they enable the transfer of files from your local machine to a remote one. These provisioners are contained within a resource, meaning that to utilize one, you simply need to insert a provisioner block into the specific resource in your OpenTofu configuration.

Provisioners are generally viewed as a measure of last resort within OpenTofu, as they step outside the tool’s declarative model. This model typically focuses on defining the desired end-state of infrastructure, whereas provisioners perform imperative actions.

OpenTofu includes three main types of provisioners:

• local-exec: Executes commands on the local machine.
• file: Used for file transfers, typically in conjunction with a connection block for specifying details of the remote machine.
• remote-exec: Executes commands on a remote machine, also usually used with a connection block for remote access details.

Example provisioner

OpenTofu is a valuable tool in the IaC world. It brings several features designed to offer flexibility, efficiency, and a community-driven approach to infrastructure management.

Open source and community-driven

One of the foundational aspects of OpenTofu is its open-source nature, ensuring it is freely available and easy to change. This fosters a community-driven development process, where contributions and improvements are sourced from a diverse group of users and organizations. Having OpenTofu under the Linux Foundation umbrella brings several benefits to the product’s well-being and ensures steady development.

Provider ecosystem

Similar to Terraform, OpenTofu works with a range of providers that extend its functionality to different technologies and services, including major cloud platforms, databases, and more.

Execution plans

Once the infrastructure is defined by the user, OpenTofu generates an execution plan. This plan outlines the actions that OpenTofu will undertake and seeks the user’s confirmation before proceeding with any modifications to the infrastructure. This critical step allows for a thorough review of the proposed changes, providing an opportunity to confirm or adjust them before OpenTofu executes any operations, such as creation, modification, or deletion of infrastructure components.

State management

OpenTofu keeps track of the state of managed infrastructure, ensuring that changes are applied incrementally and consistently. This state management is key to understanding current and past configurations and to planning future changes.

Modular design

Giving the ability to organize code as modules promotes reusability, and maintainability, making OpenTofu manage large scale and complex infrastructure easier.

As with Terraform, you will face some common challenges with OpenTofu, too.

Being the successor of Terraform, OpenTofu inherits many best practices from it, such as:

• Limit manual changes – Once you use IaC, you should ensure that you limit manual changes, as these changes may incur costly drifts in the future
• Modularize your code – Make your code DRY, ensure you can reuse it and maintain a clean an organized structure for your OpenTofu projects
• Use remote state – Take advantage of remote state to enhance collaboration between your team members and ensure that there are no parallel operation happening on the same configuration
• Use version control – This helps with ensuring that you use a vcs for the source of truth of your code and simplifies tracking changes, collaboration, and reverting to an older version if required
• Use variables and outputs – Parametrize your configuration to promote reusability and flexibility. By also leveraging outputs, you can share information about your resources, and even export configurations from modules
• Take advantage of loops and conditional – Loops and conditional ensure your code can encompass multiple use cases, and enhance reusability

Import block

With OpenTofu, importing existing resources is easier than ever. Starting from Terraform 1.5.0, the option of importing resources through an import block has become possible.

The import block requires two parameters: the ID of the resource to be imported and the HCL address for the new resource block. Here’s a simplified example for an Amazon VPC:

After adding the import block, you can execute a plan for generating the code for the resource. This is done by using:

This generated code can be reviewed and adjusted if necessary, followed by a standard apply operation to complete the import into the state.

Loops/Conditionals

Loops and conditional statements are a crucial feature of OpenTofu. Without this capability, OpenTofu, wouldn’t be one of the best solutions on the market for IaC management. 

There are essentially two types of loops you can use directly on a resource:

• for_each
• count

Both achieve the same behavior, but essentially, for_each is looping on a set or a map, and count creates the same resource multiple times, but using a number. 

If you are using count on a variable list, you will face a potential problem: if the list has many elements and you decide, for whatever reason, do delete an element from the middle of the list, every other resource from the middle to the end will get recreated because it changes its index. This is something that can be easily avoided with for_each, as you won’t face any issues with indexes

Example for_each

Example count

You can also use for loops when you are building different expressions and you also have the possibility of using if blocks inside of them:

In the above expression, we are cycling through a list of numbers using a for loop, and we are building a list with all of the even numbers by checking if the remainder of the division by two is equal to 0.

Ternary operators are also available in Terraform.

In the above example, we are using a local boolean variable “enable_vpc” and based on it, we will conditionally create vpcs. We are checking if “enable_vpc” is equal to true, and if it is we will create 1 vpc, otherwise we won’t create any vpcs.

Sensitive/Nonsensitive

In OpenTofu, the concepts of sensitive and nonsensitive data are used to handle the exposure of potentially confidential or sensitive information in outputs or logs.

You have the option to either use the sensitive parameter on a variable or an output, and you even have two functions available that will mark your data as sensitive or nonsensitive.

The sensitive function takes any value and marks it as sensitive. OpenTofu then treats this value with confidentiality, ensuring it does not appear in logs or output. It is particularly useful when a sensitive value arises from within your module, such as data loaded from a file:

The nonsensitive function takes a sensitive value and returns a copy of it with the sensitive marking removed. This is useful when you’ve derived a non-sensitive result from a sensitive value and wish to expose it in your output. However, caution is advised since using this function can expose sensitive values if not used appropriately:

Testing capabilities

The tofu test command in OpenTofu is designed to facilitate integration testing for your OpenTofu configurations.

How it works in a nutshell:

• Create a testing suite –  Defining a test suite through reading *.tftest.hcl files. These files contain the test definitions
• Reading Global Input Variables – It reads all global input variables applicable to the entire test suite
• Execution Order – The test files are sorted alphabetically to establish an execution order
• Executing Test File –  Each test file in the suite is executed sequentially. Within each test file:

– The run configurations are prepared and validated

– The tofu plan+apply or tofu apply operations are performed

– It checks for expected failures

– Assertion conditions are verified

– The suite status is updated after each run

• Summary and Cleanup – After executing the tests, OpenTofu prints out summaries for each test file and for each run. It then attempts to destroy the resources provisioned by each run in reverse order, ensuring clean-up of the testing infrastructure.
• Termination Status – The command exits with a status code 0 if all tests passed or 1 if any tests failed​

Read more on how to define tests here.

OpenTofu has its own registry for providers and modules. The provider registry protocol and the module registry protocol are systems used by OpenTofu to discover details and install providers and modules.

Providers are uniquely identified by addresses formatted as hostname/namespace/type. This protocol supports versioning, where each provider address is associated with multiple versions following Semantic Versioning conventions. Service discovery begins with the OpenTofu CLI querying a hostname to locate providers, which is essential for ensuring compatibility with specific OpenTofu versions and platforms. The protocol also outlines the necessary steps for listing available versions of a provider and retrieving provider packages, including download URLs and necessary metadata like checksums and signing keys, so make sure to check it out to view some usage examples.

Modules, on the other hand,  are identified by a specific address format (hostname/namespace/name/system), with each address containing multiple versions following Semantic Versioning. The protocol includes steps for listing available module versions and retrieving specific module versions for download as in the provider case. You will also need to check the documentation to view some usage examples. It also provides a service discovery mechanism, where the CLI uses a hostname to locate modules. This approach facilitates the management and distribution of modules in a structured and efficient manner.

OpenTofu is supported natively within Spacelift.

To see how easy it is to use it, check out this article.

If you are looking for help in migrating from Terraform to OpenTofu, or if you are searching for an infrastructure management platform that supports top flavors of infrastructure as code (including OpenTofu 1.7), configuration management, and container Orchestration, don’t hesitate to reach out to Spacelift.

As a founding partner of the initiative, Spacelift offers the native and commercial support you need to ensure your OpenTofu success. Learn more about OpenTofu Commercial Support & Services.

OpenTofu’s first stable release is here. You can easily install it and the migration from Terraform is pretty straightforward. With OpenTofu you get all the advantages that Terraform offers, and judging by the fact that it is open source and under the Linux Foundation umbrella, you get what Terraform never had – a community-first development approach.

Terraform and OpenTofu are on feature parity right now, but they will most likely drift in the future, and you will have to choose the IaC tool to use.

If you want to take your OpenTofu workflow to the next level, you can use Spacelift. Create a free account today or book a demo with one of our engineers.