Infrastructure as code: getting started

Why Manual Server Configuration Is Still a Serious Problem?

If you've ever set up a server manually, step by step, you're probably familiar with this scenario: first, you get a VPS, SSH into it, install Nginx, configure PHP, create a database, and after a few hours of work, the server is up. Everything goes well until the day the server fails, and you have to repeat the entire process — this time with the question, "What exactly did I configure last time?"

Manual configuration has several fundamental problems: lack of reproducibility (no two servers are configured exactly alike), human error (one wrong command can compromise all security), and no documentation (the only source of truth is your memory). This is where Infrastructure as Code (IaC) comes in and solves exactly these problems.

Infrastructure as Code means defining all infrastructure components — from servers and networks to installed software — as version-controlled text files. Instead of going to the data center management console and clicking buttons, you write and execute a main.tf file. The result? Infrastructure that, like software code, can be reviewed, tested, and reproduced.

The Real Problem: "It Works on My Server" Is No Longer Enough

Suppose you have a web application running on a virtual server. One day you notice that the PHP version on the server is 7.4, but on your development system it's 8.2. Or you discover that the firewall is open on the main server but closed on the backup server. This "Configuration Drift" is exactly what causes mysterious bugs and security vulnerabilities.

With Infrastructure as Code, your infrastructure becomes a "state machine." You define the desired state in code, and the IaC tool is responsible for bringing the system to that state. If someone manually changes something, it will either be detected and corrected on the next run, or at least reported as drift.

Three Generations of IaC Tools You Should Know

IaC tools can be divided into three general categories:

• Provisioning Tools (Infrastructure Creation): Such as Terraform and Pulumi, which create servers, networks, and cloud resources. These tools manage the "physical infrastructure."
• Configuration Management Tools (Software Setup): Such as Ansible, Puppet, and Chef, which run on existing servers and install and configure software.
• Immutable Infrastructure Tools: Such as Packer, which create ready-made server images (like AMI). In this approach, a server is never updated; instead, it is replaced with a new version.

In practice, most teams use a combination of Terraform (for provisioning) and Ansible (for configuration). In the following, our focus is on Terraform because it's the most popular and, at the same time, the simplest starting point for Infrastructure as Code.

Getting Started with Terraform: A Real-World Example

Suppose you want to set up a virtual server (VPS) in a data center. With the traditional method, you log into the panel, create a server, set up an SSH key, and then manually install software. With Terraform, this entire process becomes a text file.

Installing Terraform and Initial Structure

First, install Terraform. On Ubuntu/Debian:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Then create a project directory and create your first file:

mkdir my-infra && cd my-infra
nano main.tf

In this file, first, we define the provider. If you're working with an Iranian service provider, you'll likely use an OpenStack-compatible API or a dedicated provider. For a simple example, let's assume we're using the standard AWS provider:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "me-south-1"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "MyFirstIaCServer"
  }
}

Now run the three main commands:

1. terraform init — to download provider plugins
2. terraform plan — to see the changes that will be applied (without applying)
3. terraform apply — to actually create the server

The output of terraform plan shows you exactly what will be created. This "preview" is one of the biggest advantages of IaC: before any change, you know what will happen.

Managing State: The Heart of IaC

Terraform maintains a file called terraform.tfstate that records the current state of your infrastructure. This file is critical; if it's lost, Terraform won't know what's been created and what hasn't. In team projects, this file should be stored in a secure, shared location (like S3 or GitLab). Never commit it to Git — unless you're using an encrypted backend.

A common mistake: forgetting to run terraform plan before apply. Always run plan, especially in production environments. A wrong change in code can destroy the entire infrastructure.

Practical Tips to Avoid Common Mistakes

Infrastructure as Code can become problematic if not used correctly. Here are some common mistakes and their solutions:

Mistake 1: Using Credentials in Code

Never write API keys or passwords directly in .tf files. These files are usually stored in Git, and anyone with repository access can see them. Instead, use environment variables or tools like Vault:

provider "aws" {
  region     = "me-south-1"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

And define the values in a terraform.tfvars file (which is in .gitignore) or as environment variables.

Mistake 2: Ignoring State Locking in Team Work

If two people run terraform apply simultaneously, the state can become corrupted. Tools like Terraform Cloud or S3-based backends with locking solve this problem. In small teams, at least establish a rule: only one person performs apply operations at any given time.

Mistake 3: Not Testing Infrastructure Code

IaC code should be tested just like software code. Include tools like terraform validate and terraform fmt in your CI/CD pipeline. For more advanced testing, use terraform-compliance or kitchen-terraform.

Infrastructure as Code in the Real World: The Complete Lifecycle

Now that you know the basics, let's review a complete scenario. Suppose you have a Node.js application that needs to run on a server. With Infrastructure as Code, the workflow looks like this:

1. Define Infrastructure: In main.tf, you define a server, a security group (firewall), and an Elastic IP.
2. Configure Software: With Ansible or a user_data script, you install Node.js and PM2.
3. Apply Changes: You run terraform apply. The server is created, software is installed, and the application comes up.
4. Update: If you have a new version of the application, you change the code and apply again. Terraform only applies the necessary changes.
5. Destroy: If you no longer need the server, you run terraform destroy and everything is cleaned up — without anything being missed.

This cycle is exactly what large companies call "GitOps": your infrastructure lives in Git, every change is applied through a Pull Request, and no one has direct access to the server.

When Should You Move to IaC?

If you only have one server and manage it for a personal project, Infrastructure as Code might seem "overkill." But as soon as:

• You have more than two servers,
• You need to reproduce staging and production environments,
• Your team has more than one person,
• Or you need automated infrastructure documentation,

…Infrastructure as Code is no longer a choice; it's a necessity. The initial learning cost (about a week working with Terraform) is negligible compared to the hours you save on every deployment.

If you're looking for infrastructure compatible with API and IaC tools, ServerNet's cloud services allow resource management through programming interfaces, which can be a good starting point for implementing this approach.

Summary: Your Next Step

Infrastructure as Code is not just a tool; it's a mindset shift. Instead of viewing servers as "disposable objects" built by hand, see them as "code" that can be reviewed, tested, and reproduced. Start with a small project: build a test server with Terraform, work with it for a few days, and see how much easier it is than the old method.

To get started, do these three things:

1. Install Terraform and create a test server.
2. Put your .tf files in a Git repository.
3. Write a simple Ansible script that installs Nginx on that same server.

After this exercise, you'll understand why Infrastructure as Code has become one of the most important DevOps skills. There's no longer any excuse for manual configuration — unless you love repeating repetitive tasks.