Initialize Terraform configuration
The core Terraform workflow consists of three main steps after you have written your Terraform configuration:
- Initialize prepares your workspace so Terraform can apply your configuration.
- Plan allows you to preview the changes Terraform will make before you apply them.
- Apply makes the changes defined by your plan to create, update, or destroy resources.
When you initialize a Terraform workspace, Terraform configures the backend,
installs all providers and modules referred to in your configuration, and
creates a version lock file if one doesn't already exist. In addition, you can
use the terraform init
command to change your workspace's backend and upgrade
your workspace's providers and modules.
In this tutorial, you will initialize a Terraform workspace that uses both local
and remote modules, explore the .terraform
directory that Terraform uses to
store your providers and modules, and update your provider and module versions.
In the process, you will learn more about the terraform init
command's
integral role in the Terraform workflow.
Prerequisites
You can complete this tutorial using the same workflow with either Terraform Community Edition or HCP Terraform. HCP Terraform is a platform that you can use to manage and execute your Terraform projects. It includes features like remote state and execution, structured plan output, workspace resource summaries, and more.
Select the HCP Terraform tab to complete this tutorial using HCP Terraform.
This tutorial assumes that you are familiar with the Terraform workflow. If you are new to Terraform, complete the Get Started tutorials first.
In order to complete this tutorial, you will need the following:
- Terraform v1.6+ installed locally.
Clone the example repository
In your terminal, clone the learn-terraform-init
repository.
Navigate to the cloned repository.
Review configuration
This directory contains Terraform configuration that uses multiple providers, a local module, and a remote module. You will use these resources to review how Terraform initializes the working directory.
The example repository includes the following:
LICENSE
includes the text of the Mozilla Public License under which HashiCorp distributes the example configuration.README.md
describes the example configuration.main.tf
includes the resources and data sources used by the example configuration.the
modules/aws-ec2-instance
directory includes a Terraform module to provision an EC2 instance on AWS.terraform.tf
defines theterraform
block, which defines the providers, remote backend, and the Terraform version(s) to be used with this configuration.variables.tf
defines the variables used in this configuration.
Initialize your workspace
Initialize your Terraform workspace.
The output describes the steps Terraform executes when you initialize your workspace.
First, Terraform initializes the backend.
Since the terraform
block does not include a
cloud
or
backend
block,
Terraform defaults to the local
backend.
Next, Terraform downloads the modules required by your configuration.
Terraform recognizes that the module "ec2-instance"
block uses the local
modules/aws-ec2-instance
module. Next, Terraform determines that the module
"hello"
block references a remote module, so it downloads it from the public
Terraform Registry.
Note
When you change a module's source or version, you must either re-initialize
your Terraform configuration or run terraform get
to download the new module.
Next, Terraform downloads the providers required by your configuration.
Since the configuration does not yet have a lock file, Terraform downloaded the
aws
and random
providers specified in the required_providers
block found
in terraform.tf
.
When you initialize a workspace, Terraform will attempt to download the provider
versions specified by the workspace's lock file. If the lock file does not
exist, Terraform will use the required_providers
block to determine the
provider version and create a new lock file. If neither exists, Terraform will
search for a matching provider and download the latest version.
Next, Terraform creates the lock file if it does not already exist, or updates it if necessary.
Terraform's lock file, .terraform.lock.hcl
, records the versions and hashes of
the providers used in this run. This ensures consistent Terraform runs in
different environments, since Terraform will download the versions recorded in
the lock file for future runs by default.
When you manage Terraform configuration in a source control repository,
commit the .terraform.lock.hcl
file along with your configuration files.
Finally, Terraform prints out a success message and reminds you how to plan your
configuration, and to re-run terraform init
if you change your modules or
backend configuration.
Validate your configuration
Now that you have initialized your workspace and downloaded the required modules and providers, Terraform can verify whether your configuration syntax is valid and internally consistent. This includes checking if your resources blocks have invalid or missing arguments. You must initialize your workspace before you can validate your configuration.
Validate your configuration.
Review initialization artifacts
When you initialize a new Terraform workspace, it creates a lock file
named .terraform.lock.hcl
and the .terraform
directory.
Explore the lock file
The lock file ensures that Terraform uses the same provider versions across your team and in remote execution environments. During initialization, Terraform will download the provider versions specified by this file rather than the latest versions.
Open .terraform.lock.hcl
to review its structure and contents.
If the versions defined in the lock file's provider
block do not match the
versions defined in your configuration's required_providers
block, Terraform
will prompt you to re-initialize your configuration using the -upgrade
flag.
You will do this in the next section.
Explore the .terraform
directory
Terraform uses the .terraform
directory to store the project's providers and
modules. Terraform will refer to these components when you run validate
,
plan
, and apply
,
Note
Terraform automatically manages the .terraform
directory. Do not check it
into version control, and do not directly modify this directory's contents.
Exploring the .terraform
directory in this tutorial is meant to deepen your
understanding of how Terraform works, but the contents and structure of this
directory are subject to change between Terraform versions.
View the .terraform
directory structure.
Notice that the .terraform
directory contains two sub-directories: modules
and providers
. These two directories contain the modules and providers used by
your Terraform workspace.
The
.terraform/modules
directory contains amodules.json
file, and a local copy of the remote module, "hello".Open
modules.json
. This file shows that the configuration uses three modules: the "root" module, referring to the configuration in the root directory of your workspace, the localaws-ec2-instance
module, and the remotehello
module.modules.jsonThe
aws-ec2-instance
module refers to a local module, so Terraform refers directly to the module's configuration found within themodules/aws-ec2-instance
directory in the example repository. This means that if you make changes to a local module, Terraform will recognize them immediately.Because the
hello
module is remote, Terraform downloaded the module from its source and saved a local copy in the.terraform/modules/hello
directory when you initialized your workspace. Open the files in.terraform/modules/hello
to view the module's configuration. These files are intended to be read-only, like the other contents in.terraform
. Do not modify them. Terraform only updates a remote module when you runterraform init -upgrade
orterraform get
.The
.terraform/providers
directory stores cached versions of all the configuration's providers.View the
.terraform/providers
directory. When you ranterraform init
earlier, Terraform downloaded the providers defined in your configuration from the provider's source (defined by therequired_providers
block) and saved them in their respective directories, defined as[hostname]/[namespace]/[name]/[version]/[os_arch]
.
Update provider and module versions
In terraform.tf
, update the random
provider's version to 3.6.1
.
In main.tf
, update the hello
module's version to 6.0.0
.
Reinitialize configuration
Because you updated the provider and module versions, you must re-initialize the configuration for Terraform to install the updated versions.
If you attempt to validate, plan, or apply your configuration before doing so, Terraform will prompt you to re-initialize.
Re-initialize your configuration to have Terraform upgrade the module to match the new version you configured in the previous step. Terraform will report an error for the provider, however.
Notice that Terraform downloaded the updated module version and saved it in
.terraform/modules/hello
. However, Terraform was unable to update the provider
version since the new provider version conflicts with the version found in the
lock file.
Re-initialize your configuration with the -upgrade
flag. This tells Terraform
to upgrade the provider to the most recent version that matches the version
attribute in that provider's required_version
block.
View the .terraform/providers
directory structure. Notice that Terraform
installed the updated random
provider version.
Open the lock file. Notice that the random
provider now uses version 3.6.1
.
Even though there are two versions of the random
provider in
.terraform/providers
, Terraform will always use the version recorded in the
lock file.
Update module arguments
Since you have updated your provider and module version, check whether your configuration is still valid.
The new version of the hello
module expects different arguments from the old
version. Replace the entire module "hello"
block with the following:
Re-validate your configuration.
Now your Terraform workspace is initialized and ready to be applied.
Initialize your Terraform workspace with terraform init
when:
You create new Terraform configuration and are ready to use it to create a workspace and provision infrastructure.
You clone a version control repository containing Terraform configuration, and are ready to use it to create a workspace and provision infrastructure.
You add, remove, or change the version of a module or provider in an existing workspace.
You add, remove, or change the
backend
orcloud
blocks within theterraform
block of an existing workspace.
Next steps
Over the course of this tutorial, you initialized a Terraform configuration with
both local and remote modules, explored the .terraform
directory, and updated
your provider and module versions. These steps were integral to understanding
the mechanisms underlying terraform init
.
For more information on topics covered in this tutorial, check out the following resources.
- Complete the Lock and Upgrade Provider Versions tutorial.
- Complete the Migrate State to HCP Terraform tutorial.
- Read more about
init
in the documentation.