Infrastructure as Code: Managing Servers as Code

What Is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure such as servers, networks, and databases through machine-readable definition files instead of manual configuration. Rather than logging into each server and adjusting settings by hand, you write a file describing the desired state and the tool executes it automatically.

This shift from manual to automated management has fundamentally changed how operations teams work. The same principles developers apply to code such as version control, review, and testing now apply to infrastructure.

Why IaC Is Essential

1. Reproducibility

A single IaC file creates the exact same environment every time. No differences between development, staging, and production. This eliminates the "works on my machine" problem that every developer faces.

2. Version Control

Every infrastructure change is recorded in Git. You know who changed what, when, and why. You can roll back to any previous version within seconds.

3. Speed

Creating a complete environment takes minutes instead of hours or days. Scaling becomes an automatic process requiring no human intervention.

4. Living Documentation

IaC files are the documentation. Instead of outdated documents nobody updates, the files themselves accurately describe the current state of infrastructure.

5. Reduced Human Error

Manual setup is prone to mistakes and oversights. IaC executes the same steps in the same order every time without exception.

Two Fundamental Approaches

Declarative

You describe the desired end state and the tool determines how to reach it.

Example: "I want 3 servers with 4GB RAM on a private network with a Load Balancer in front."

The tool compares current state to desired state and executes only the necessary changes.

Examples: Terraform, Kubernetes manifests, CloudFormation

Imperative

You write execution steps in order and the tool runs them sequentially.

Example: "Create a server, then install Nginx, then copy the config file, then restart the service."

Examples: Ansible playbooks, Shell scripts, Chef recipes

Core Tools

Terraform

Terraform by HashiCorp is the most widely used tool for managing cloud infrastructure. It uses HCL (HashiCorp Configuration Language).

Example of creating a server:

resource "server" "web" {
 name = "web-server-01"
 cpu = 4
 memory = 8192
 disk = 100

 network {
 type = "private"
 ip = "10.0.1.10"
 }
}

Key features:

• Supports hundreds of providers
• State file tracks current infrastructure
• Plan shows changes before applying
• Modules for reusable configurations

Ansible

Ansible by Red Hat manages configurations and executes tasks on servers. It uses YAML and requires no agent installation on target servers.

Example Playbook:

- name: Configure web server
 hosts: webservers
 tasks:
 - name: Install Nginx
 apt:
 name: nginx
 state: present

 - name: Copy configuration
 template:
 src: nginx.conf.j2
 dest: /etc/nginx/nginx.conf

 - name: Start Nginx
 service:
 name: nginx
 state: started
 enabled: yes

Key features:

• Agentless - works over SSH only
• YAML is easy to read and write
• Roles for organizing tasks
• Galaxy for sharing ready-made roles

Pulumi

Pulumi lets you write IaC in real programming languages like Python, TypeScript, and Go. Instead of learning a new language like HCL, you use your preferred language.

import pulumi
from pulumi import Config

server = Server("web-01",
 cpu=4,
 memory=8192,
 disk=100
)

pulumi.export("server_ip", server.ip)

Typical IaC Project Structure

infrastructure/
├── environments/
│ ├── dev/
│ │ └── main.tf
│ ├── staging/
│ │ └── main.tf
│ └── production/
│ └── main.tf
├── modules/
│ ├── network/
│ ├── compute/
│ └── database/
├── ansible/
│ ├── playbooks/
│ ├── roles/
│ └── inventory/
└── README.md

Best Practices

1. Everything in Git

No changes happen outside Git. Every infrastructure modification goes through a Pull Request and review.

2. Separate Environments

Separate files for each environment (dev, staging, production) with different variables. Same code, different values.

3. Modules

Break infrastructure into reusable modules. Networking separate from compute separate from databases.

4. Remote State

Never store State files locally. Use shared remote storage like S3 or GCS with locking to prevent conflicts.

5. Test Before Applying

Always use terraform plan before terraform apply. Review changes carefully. A single mistake could delete a production server.

6. Secrets Outside Code

Passwords and API keys never belong in IaC files. Use Vault, environment variables, or a secrets service.

Getting Started

1. Start small: Do not try to convert your entire infrastructure at once. Begin with one server or one service
2. Learn Terraform first: Most in-demand in the market with the broadest support
3. Add Ansible: For managing what happens inside the server after creation
4. Document continuously: Write clear comments in your files

On CLOUD (cloud.net.sa) VPS servers, you get full root access, allowing you to apply any IaC tool of your choice without restrictions. Start with a development server and experiment before applying automation to production.

---

Get Started

Ready to build your project? Configure your cloud server with the specs your app needs, or view plans and pricing.