There may be two main reasons why Terraform was born: The DevOps and Cloud Industry is rising, with the need for an infrastructure-as-code tool to deploy.
2006 → AWS + EC2 = developers can launch an on-demand cloud server in minutes.
2007 → EC2 public = Infrastructure as a service was born
Your server in three clicks, you create it, you modify it, and you destroy it
2010 → AWS X CloudFormation
2014 → Terraform initial releases
Imagine if, through your code, you could dynamically create and manage your service infrastructure in the clouds
Terraform is an infrastructure as code (IaC) tool, open-source and written in Go by Hashicorp.
It allows you to declare, via your code, what you want for your infrastructure
- Whether it's the initial provisioning, updating or destruction of your infrastructure, it's the code that drives.
- You declare in your config files the desired state of your infrastructure. Terraform is only going to perform the minimum to get to the state you described.
- You can see and understand your infrastructure by looking at your code
- It's usually versioned with git, so you can roll back at any stage.
- You can use it to test in multiple environments before production. Push the same code into a dev environment, and you can safely test changes. You can use all development best practices like asking a code review by your pair/colleagues... You can iterate quickly and make big changes by changing a few lines. In short, it is paradise for the way of doing DevOps.
Your live infrastructure already has a web server and a database running. Your config in your code corresponds perfectly to that. You add in your Terraform configuration that you finally want two databases. When you commit, Terraform will create an extra database and do nothing else. It has reached the desired state declared in your code.
Terraform uses the “push” approach. Imagine, you want to create a server on AWS. You declare it, you push and poof your server appears in your AWS account.
Terraform is not limited to a provider (AWS) or to the Cloud in general. Almost any type of infrastructure can be represented as a resource in Terraform. From your docker containers on your local machine to your cloud account on DigitalOcean, it's a crazy thing. I'm not going to give you the entire list of possible providers, there's the whole world . And that makes Terraform even more magnificent. You have the power of creation over any destination.
We will first initialize Terraform, validate our files, plan our actions and finally apply our changes.
We just start by saying that we want to work on AWS, and we choose our version and our region. To access AWS we specify the credentials which are our two usual keys. They are referenced via a system of variables. These variables are all stored in a file that we will see later.
Now that we have declared the destination, we will declare what we want to create as infrastructure. As usual, when you don't know where to start, we look at the doc. We will create a resource.tf file where we declare an Ubuntu machine and a Postgres database.
Now that we have defined everything we want, we are going to fill all that with the corresponding variables. We create a variables.tf file dedicated to that. Note that the secrets should never be in the clear in a file, but to simplify things, we'll do it like this.
Brainboard allow you to deploy a Terraform code without writing a single line of code. Once you design your infrastructure, the Terraform code is auto-generated and the deployment is almost instant. Think of it like a cockpit for your infrastructure, wherever it is built with Amazon AWS, Microsoft Azure, Google Cloud Platform or Scaleway!
A new feature coming up on the 25th of December will boost-rap your migration to Brainboard ;)