In this lesson you will use the configuration created in the previous lesson to build infrastructure on Azure.
The first command to run for a new configuration is
terraform init, which
initializes various local settings and data that will be used by subsequent
commands. For details, see Terraform: init.
Terraform uses a plugin-based architecture to support the numerous infrastructure and service providers available. Each provider is its own encapsulated binary distributed separately from Terraform itself. The
terraform init command will automatically download and install any provider binary for the providers in use within the configuration.
This example initializes two providers,
glenn@Azure:~/test$ terraform init Initializing provider plugins... - Checking for available provider plugins on https://releases.hashicorp.com... - Downloading plugin for provider "azurerm" (1.21.0)... - Downloading plugin for provider "random" (1.3.1)... Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.
The Random provider is an example of a logical provider. A logical provider works entirely within Terraform and does not interact with other services. Random is good to know about. It defines resources to generate random values for use as unique identifiers. The Random provider isn't used again in this guide.
» Apply Changes
Note: The commands shown in this guide apply to Terraform 0.11 and
terraform version to confirm your running version.
In the same directory as the
main.tf file you created, run
You should see output similar to this:
glenn@Azure:~/test$ terraform apply An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: + azurerm_resource_group.rg id: <computed> location: "westus2" name: "myTFResourceGroup" tags.%: <computed> Plan: 1 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. ...
This output shows the execution plan, describing which actions Terraform
will take in order to change real infrastructure to match the configuration.
The output format is similar to the diff format generated by tools
such as Git. The output has a
+ next to
meaning that Terraform will create this resource. Beneath that,
it shows the attributes that will be set. When the value displayed
<computed>, it means that the value won't be known
until the resource is created.
The execution plan is an important artifact. To simplify things, this tutorial does not save the plan, but in practice, you'll usually want to export the plan to a file, review the plan, and then execute that same plan. If you run
terraform apply without specifying a plan, Terraform will recalculate the plan, which may vary from the plan you previously created by running
terraform apply failed with an error, read the error message
and fix the error that occurred. At this stage, it is likely to be a
syntax error in the configuration.
If the plan was created successfully, Terraform will now pause and wait for
approval before proceeding. If anything in the plan seems incorrect or
dangerous, it is safe to abort here with no changes made to your infrastructure.
In this case the plan looks acceptable. Type
yes at the confirmation
prompt to proceed.
Executing the plan should only take a few seconds, and then you will see something like this:
... #Enter a value: yes azurerm_resource_group.rg: Creating... location: "" => "westus2" name: "" => "myTFResourceGroup" tags.%: "" => "<computed>" azurerm_resource_group.rg: Creation complete after 2s
You can go to the Azure portal to see the new resource group.
» Terraform State
When Terraform created the resource group it also wrote data into the
terraform.tfstate file. State keeps track of the IDs of created resources so that Terraform knows what it is managing. This state file is extremely important. It is generally recommended to
setup remote state
when working with Terraform, to share the state automatically, but this is
not necessary for simple situations like this Getting Started guide.
Note: Terraform state may contain sensitive information in plain text, such as passwords and connection strings. Another reason to use a remote backend to save state is to avoid storing state in an insecure location.
You can inspect the current state using
terraform state show:
glenn@Azure:~/test$ terraform state show id = /subscriptions/<subscription id>/resourceGroups/myTFResourceGroup location = westus2 name = myTFResourceGroup tags.% = 0
In this example, the subscription id was displayed, but it has been replaced by
<subscription id> in the text. Subscription ID is an example of sensitive information stored in plain text. State is typically much more lengthy than this.