Getting Started - Azure

Build Infrastructure

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, azurerm and random:

glenn@Azure:~/test$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on
- 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

In the same directory as the file you created, run terraform apply.

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 azurerm_resource_group.rg, meaning that Terraform will create this resource. Beneath that, it shows the attributes that will be set. When the value displayed is <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 plan.

If 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.

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.