To also be able to deploy infrastructure in a cloud, we will need Terraform to be able to identify itself in some way in that cloud with sufficient permissions to be able to deploy what we have configured.
We are going to use AWS for our examples, and the easiest way to configure Terraform access to AWS is to configure the system to be able to use the AWS CLI .
Once we have the configuration done as explained there, we will only have to add the AWS provider to our Terraform configuration (if you don't know what a Terraform provider is, do not worry - we will explain it in a future post). There are more ways to make Terraform identify itself to AWS, but for now, we will use the one we just explained, which is also the simplest.
Terraform will identify any file with a .tf extension within our directory as part of the configuration, so for the provider configuration, we can use the provider.tf file and assuming we use the latest version of Terraform (or at least a version higher than 0.13) the configuration would be as follows:
With these four commands, we are going to be able to deploy infrastructure and eliminate it, as long as we have Terraform correctly configured to work with our chosen infrastructure provider (AWS in our examples).
The terraform init command is the one we use to initialize our terraform environment. The provider configuration is checked, modules are downloaded, etc. It is similar to when we do git init to start using git in a project.
It is the first thing we have to do to test a new configuration that we have created or that we have downloaded from our version control.
After successful execution of Terraform init, we should see a message similar to this:
The terraform plan command will create an execution plan. This will show us the resources that will be created, modified, or destroyed in case of executing the terraform apply command on the current configuration.
Terraform keeps track of what has been created with the configuration in the “ state ”, this way, during a Terraform plan it can compare what is already deployed to what should be deployed after the terraform apply execution. The state is also used to prevent changes to other solutions because Terraform will only change or delete resources that are in its state for this solution.
We will cover more information about the Terraform state in future posts, but know it is one of the most important steps since it allows us to correct possible errors before they have been executed.
On the other hand, hours or even days of bug fixing can save us valuable minutes of reviewing the plan…so, it’s up to you!
For this example, we are going to use the following two configuration files (by having the .tf extension, Terraform will interpret this as a single configuration):
provider.tf:
main.tf:
And the result of executing Terraform plan will be (we have cut the less relevant parts):
At the moment, we will probably not understand much of what it tells us, but it is important to see the number of items that are going to be added, changed and destroyed in our infrastructure. This will give us a clue as to what Terraform is going to do when executing Terraform apply is really what we were looking for.
With terraform apply we will finally make the changes described in our configuration. Before doing so, a plan will be made and we will be asked for confirmation:
And after answering yes:
Our configuration is applied and our resources (an instance in this example) are deployed.
With terraform destroy all the infrastructure that has been deployed with our configuration will be erased. Before doing so, a plan will be made and we will be asked for confirmation:
And after answering yes:
The configuration we deployed previously, is destroyed.
Thank you for reading. Stay tuned for future posts about Terraform!