Infrastructure as code: Creating a multi-regional blog with Terraform on the OVH Public Cloud – Part 1
Terraform, developed by HashiCorp, is a very popular solution for those who are looking to build and orchestrate an architecture efficiently using Infastructure as code (IaC). In this series of articles, we will give a concrete demonstration of the benefits of using this tool with the OVH public cloud to deploy a high-availability, multi-regional website. Your mission, should you choose to accept it, is to publish an online blog with Let’s Encrypt certificates, and register a domain name — all for less than 10 euros ($15 CAD) per month!
The idea isn’t to offer a step-by-step guide here (we have a guide for this), but rather to use a concrete project as a way of demonstrating how Terraform meets changing expectations in terms of orchestration and automation. Which is a great way to unlock the full potential of IaC!
In this post, we’ll give a quick reminder of why Terraform is so popular, briefly introduce the key concepts behind its use (provider, resource, variable and output), and also introduce concepts like project states and workspaces, which are absolutely essential for anyone looking to work collaboratively.
What is Terraform?
Terraform is an open-source tool for building and maintaining complex cloud-based infrastructures. Written in Go language, it uses declarative configuration files that describe the infrastructure, and define how it is distributed between various providers. Terraform can be used to manage both public and private clouds.
In other words, the tool orchestrates API calls to a long list of providers, and manages all of the resources used by an architecture, from VMs and DNS records to databases, network components, storage blocks and software architecture. It is not cloud-agnostic, but due to its flexible nature, it can accommodate a highly varied range of platforms.
Why is this a game-changer? With Terraform, every element of the architecture elaborated like this can be edited, versioned or shared on an archive. So you can create easily reproducible environments using automation, fully monitor changes and manage the lifecycle. You can also do all of this via a code that is both understandable and easy to maintain.
Provider and Resources
You can describe the infrastructure using configuration (.tf) files, which can either be written using a syntax specific to HashiCorp (HCL), or using JSON. The first step involves configuring a provider for the project, i.e. the provider hosting the resources required for building and developing applications. In practice, it is not uncommon to use several providers for a single project. In fact, this is one of the main purposes Terraform was designed for.
Here is an example of how to describe the provider OpenStack hosted by OVH.
Then, you can simply boot the environment in order to create or remove (destroy) a resource.
Variables and Outputs
It’s impossible to deploy a secure, large-scale infrastructure with values hard-coded into configuration files. With an IaC approach, we’re looking to obtain the most generic result possible. As a result, Terraform predicts the declaration of a certain number of variables, which work as parameters for a project’s various resources. These variables could be a name that identifies a resource, login details, or a deployment region, for example. These variables can be assigned via configuration files, the command line, or parameters related to the runtime environment.
Once you have entered the input variables, it makes sense to format the output variables in order to obtain data which can either be used by the end-user, or by Terraform modules. These outputs (e.g. an IP address or resource) will then expose the data, and use the infrastructure.
In this example, we can see how variables can be used to modify the region in which a container is deployed.
Centralizing states and workspaces
Each time it runs, Terraform creates a state file named terraform.state, which references the resources and their states in JSON format. It is stored locally, but can be saved on a shared space via the Remote Backend function, in order to make collaborative work easier and guarantee that everyone has access to the very latest infrastructure state.
Using this information, on the next run command, Terraform will determine which actions need to be carried out to obtain a list of resources included in the configuration files, from what is already in production (published online). You can also manage other environment using workspaces. You can read about these feature in more detail in this example,
And that’s all for Part 1! In our next article, we’ll take a more detailed look at the ways you can use Terraform with the OVH Public Cloud, and get started deploying a draft version of our blog.
For details on the Terraform templates mentioned in this article, check our GitHub guide documents: