Terraform Study Notes: Terraform and Infrastructure as Code concepts

With this post, we are starting the preparation for Terraform Certification introducing the concepts of Infrastructure as code, its rules, and how Terraform is declining it into configuruation writing and applying. Following an overview of Terraform architecture, this post will delve into the principles of adopting an immutable approach to infrastructure. So, let’s start with the Terraform Associate study notes!

The Infrastructure as Code

infrastructure as code (IaC) is the process of managing and provisioning computer infrastructure elements through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

Declarative programming is a paradigm that expresses the logic of computation without describing its control flow. In this way, it doesn’t matter the order in which things should be deployed and every deployment is consistent. Suppose the paradigm is well-kept and no imperative codes are processed during the deployment. In that case, the final system is always consistent: the final element delivered with IaC has only two states:

  1. Deployed and healthy
  2. Not Deployed

For this reason, a developer who is approaching this methodology should forget the procedural and the OOP programming style. The code simply describes what the infrastructure should be without care of the dependency on the other infrastructure elements.

Introducing Terraform

Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API.

HashiCorp and the Terraform community have already written thousands of providers to manage many different types of resources and services. You can find all publicly available providers on the Terraform Registry

The core Terraform workflow consists of three stages:

  • Write: You define resources, which may be across multiple cloud providers and services
  • Plan: Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration.
  • Apply: On approval, Terraform performs the proposed operations in the correct order, respecting any resource dependencies.

Terraform takes an immutable approach to infrastructure, reducing the complexity of upgrading or modifying your services and infrastructure.

Terraform generates a plan and prompts you for your approval (keeps track of your real infrastructure in a state file, which acts as a source of truth for your environment)

Terraform configuration files are declarative: you do not need to write step-by-step instructions to create resources because Terraform handles the underlying logic. (Terraform builds a resource graph to determine resource dependencies and creates or modifies non-dependent resources in parallel… max 10 parallel executions)

Terraform supports reusable configuration components called modules that define configurable collections of infrastructure, saving time and encouraging best practices.

Since your configuration is written in a file, you can commit it to a Version Control System (VCS) and use Terraform Cloud to efficiently manage Terraform workflows across teams

Immutable approach to infrastructure

A mutable infrastructure approach is a common and manual way to deliver a piece of infrastructure like a server and every change is simply applied without tracking and with a limited ability to rollback in case of failures.

Immutability introduces a significant evolution in the infrastructure lifecycle, enabling the tracking of every change to ensure a consistent rollback. It’s not magic; rather, it involves employing various strategies and cloud technologies for each change.

The tradeoff of making this system is to work with stateless infrastructure. Keeping the case of the server, it’s mandatory to define and handle data as a separate entity (stateful infrastructure). Data deserve a particular treatment, especially during infrastructure transition, it’s necessary to guarantee its integrity.

Terraform concepts

Terraform makes it possible to:

  • Manage any infrastructure: find providers for many of the platforms and services you already use in the Terraform Registry.
  • Track your infrastructure: generates a plan and prompts you for your approval before modifying your infrastructure
  • Automate changes: configuration files are declarative, meaning that they describe the end state of your infrastructure
  • Standardize configuration: supports reusable configuration components called modules that define configurable collections of infrastructure, saving time and encouraging best practices

Terraform Modules

Modules are containers for multiple resources that are used together.

  • A module consists of a collection of .tf or .tf.json files grouped together in a directory.

tf file is the only extension recognized by Terraform to evaluate the configuration written in HCL (HashiCorp language). It’s possible also to write configurations in JSON putting the code into a tf.json file

  • Every Terraform configuration has at least one module, known as its root module, which consists of the resources defined in the .tf files in the main working directory
  • A Terraform module (usually the root module of a configuration) can call other modules to include their resources in the configuration. A module that has been called by another module is often referred to as a child module.

In addition to modules from the local filesystem, Terraform can load modules from a public or private registry.

Terraform Cloud

Terraform Cloud operates Terraform in a consistent, reliable environment, offering:

Terraform Cloud Overview

Sources

   Send article as PDF   

2 pensieri riguardo “Terraform Study Notes: Terraform and Infrastructure as Code concepts

I commenti sono chiusi.