In this blog post we will explore the use of Infrastructure as Code also known as IaC. But before we go into details, let’s make sure we have same understanding of what IaC is.

Definition of IaC

Infrastructure as Code (IaC) is the practice of provisioning and managinging infrastructure through code instead of manual configuration through UI’s. This means we can also use git, linters and industry-standards practices.

There are a many tools that can do IaC but here a short list of the common ones:

  • Ansible, primarily a configuration management first tool but can also be used to create infrastructure.
  • Terraform / Opentofu, infrastructure provisoning tools.
  • Azure Bicep, Automation and provisoning tooling mainly designed specifically for Azure platform
  • AWS CLI, primarily a managemant and automation tool but can also be used to create infrastructure.

Yay

All the tools in the list above can be easily installed on local computers, servers or intergrated into CI/CD pipelines. Terraform / and Opentofu are among the most capable IaC tools, while Azure bicep and AWS CLI are tied to there own specific cloud providers. By defining our IaC, we have a clear understanding of all our components in the cloud or locally. It also makes deploying a new environment or a component much easier,repeatable and consistent.

Nay

You need to know how to write the tool specific language to create the necessary IaC. It can take multiple iterations to find the best setup specific for your environment. Most IaC tools can suffer from configuration drift, where infrastructure is manually changed after deployment. This can create differences between the deployed environment and the codebase. Terraform/OpenTofu handle this better through state management and planning, although statefiles can also become a maintenance challenge if they are corrupted, lost, or improperly managed.

Terraform/Opentofu IaC example

In the example code block below we will create a Azure resource group and a storage account. Most configurable resources needs to go into a group called resource group, in this group we place the storage account.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_storage_account" "example" {
  name                     = "example_storage_name"                     # Name of the storage account
  resource_group_name      = azurerm_resource_group.example.name        # connection to resource group name
  location                 = azurerm_resource_group.example.location    # connection to resource group location
  account_tier             = "Standard"                                 # Azure storage options
  account_replication_type = "LRS"                                      # Azure storage options
}

Conclusion

For solo DevOps engineers,Sysadmin,developers or small environments, IaC can somethimes feel like its overkill. But when more people are deploying infrastructure, IaC becomes extremely valuable because of the consistancy, the ease of repeating items and the insights on all the deployed items.

Troubleshooting IaC can sometimes feel like finding a needle in a haystack but the benifits usually outweigh the drawbacks. Its never been so easy to deploy a full cluster in minutes then clicking through webUI’s.