Apa itu Terraform? #

Infrastruktur modern terlalu kompleks untuk dikelola secara manual. Setiap kali kamu membuat server, mengatur jaringan, atau mengkonfigurasi database lewat UI cloud provider, kamu meninggalkan proses yang tidak terdokumentasi, sulit diulang, dan rawan error. Terraform hadir untuk menyelesaikan masalah ini — dengan cara mendefinisikan seluruh infrastruktur dalam bentuk kode yang bisa dibaca, diverifikasi, dan dijalankan secara konsisten.

Artikel ini menjelaskan apa itu Terraform, bagaimana cara kerjanya secara deklaratif, elemen-elemen dasar konfigurasinya, dan mengapa tool ini menjadi pilihan utama di industri untuk mengelola infrastruktur cloud. Setelah membaca artikel ini, kamu akan memahami konsep inti yang menjadi fondasi untuk seluruh seri pembelajaran Terraform.

Definisi Terraform #

Terraform adalah tool open-source buatan HashiCorp yang memungkinkan kamu mendefinisikan infrastruktur cloud dalam bentuk kode deklaratif. Kode ini disebut konfigurasi Terraform, ditulis dalam bahasa HCL (HashiCorp Configuration Language), dan bisa dijalankan untuk membuat, mengubah, atau menghapus infrastruktur secara otomatis.

Konsep ini dikenal sebagai Infrastructure as Code (IaC) — memperlakukan infrastruktur seperti kode software: bisa di-version control, di-review, dan di-test. Tapi Terraform bukan sekadar “script untuk bikin server”. Perbedaan fundamentalnya ada di pendekatan deklaratif yang akan kita bahas di bagian berikutnya.

# Contoh konfigurasi Terraform paling sederhana
# Membuat sebuah S3 bucket di AWS

resource "aws_s3_bucket" "contoh" {
  bucket = "nama-bucket-saya"
}

Dengan kode di atas, Terraform tahu bahwa kamu ingin ada sebuah S3 bucket. Terraform yang akan mengurus sisanya — memanggil AWS API, menunggu bucket selesai dibuat, dan mencatat hasilnya dalam state file. Kamu tidak perlu tahu endpoint API mana yang harus dipanggil, bagaimana menangani retry, atau apa parameter wajibnya.

Masalah yang Diselesaikan Terraform #

Sebelum tool seperti Terraform ada, tim infrastructure mengandalkan cara-cara manual yang penuh masalah. Klik-klik di console cloud provider tidak terdokumentasi. Script bash yang ditulis cepat-cepat tidak idempoten dan sulit dipelihara. Konfigurasi di environment dev bisa sangat berbeda dari production tanpa ada yang sadar sampai terjadi insiden.

MASALAH INFRASTRUKTUR MANUAL:
  ✗ Klik-klik di console cloud provider — tidak terdokumentasi
  ✗ Script bash ad-hoc — tidak idempoten, sulit di-maintain
  ✗ Konfigurasi berbeda di setiap environment (dev ≠ staging ≠ prod)
  ✗ Tidak ada audit trail — siapa yang buat apa, kapan?
  ✗ Disaster recovery lambat — harus rebuild manual dari awal

DENGAN TERRAFORM:
  ✓ Infrastruktur terdefinisi dalam file .tf — bisa di-commit ke Git
  ✓ Setiap perubahan bisa di-review sebelum dijalankan
  ✓ Environment dev, staging, dan prod bisa identik
  ✓ Rebuild infrastruktur dari nol hanya butuh satu perintah
  ✓ Riwayat perubahan tersimpan di version control

Bayangkan skenario berikut: tim kamu punya 50 server di production. Suatu hari, region tempat server itu berada mengalami outage. Tanpa Terraform, kamu harus membuat ulang seluruh 50 server secara manual — mengingat tipe instance mana yang dipakai, security group seperti apa, subnet yang benar, dan ratusan konfigurasi lain. Dengan Terraform, cukup jalankan terraform apply di region baru dan infrastruktur yang sama akan dibuat ulang dalam hitungan menit.

Deklaratif vs Imperatif #

Terraform menggunakan pendekatan deklaratif — kamu mendefinisikan apa yang kamu inginkan, bukan bagaimana cara mencapainya. Ini adalah perbedaan paling penting yang harus dipahami sejak awal.

Pendekatan imperatif (seperti script bash atau bahasa pemrograman umum) mengharuskan kamu menulis langkah-langkah secara berurutan: buat VPC dulu, lalu buat subnet, lalu buat security group, lalu buat instance. Urutan harus benar, dan kalau ada error di tengah, kamu harus handle rollback sendiri.

Pendekatan deklaratif membalik model ini. Kamu hanya menyatakan kondisi akhir yang diinginkan, dan Terraform yang menentukan langkah-langkah apa saja yang diperlukan untuk mencapai kondisi itu.

// ANTI-PATTERN: pendekatan imperatif — kamu harus tahu urutan dan cara
// export VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query 'Vpc.VpcId' --output text)
// aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.1.0/24
// aws ec2 run-instances --image-id ami-xxx --subnet-id $SUBNET_ID ...

// BENAR: pendekatan deklaratif — cukup definisikan apa yang diinginkan
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

Perhatikan bahwa pada kode deklaratif di atas, kamu tidak perlu menulis create-vpc atau create-subnet. Kamu hanya mendefinisikan bahwa “VPC dengan CIDR 10.0.0.0/16 harus ada” dan “subnet dengan CIDR 10.0.1.0/24 harus ada di dalam VPC tersebut”. Terraform akan menentukan sendiri bahwa VPC harus dibuat duluan karena subnet bergantung padanya.

Cara Kerja Terraform #

Terraform bekerja dalam tiga langkah utama yang membentuk siklus kerjanya. Memahami siklus ini sangat penting karena setiap operasi Terraform — baik membuat resource baru, mengubah yang sudah ada, atau menghapus yang tidak diperlukan — selalu melewati alur yang sama.

flowchart TD
    A["📝 Kamu menulis konfigurasi (.tf)"] --> B["terraform init"]
    B --> C["terraform plan"]
    C --> D{"Setujui\nperubahan?"}
    D -- Ya --> E["terraform apply"]
    D -- Tidak --> A
    E --> F["State tersimpan"]
    F --> A

    style A fill:#e8f5e9,stroke:#2e7d32
    style C fill:#e3f2fd,stroke:#1565c0
    style E fill:#fff3e0,stroke:#e65100
    style F fill:#f3e5f5,stroke:#6a1b9a

Langkah 1: Write — Tulis Konfigurasi #

Kamu menulis file .tf yang mendefinisikan resource yang diinginkan. File ini bisa satu atau ratusan — Terraform akan membaca semuanya dalam satu direktori kerja.

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

Langkah 2: Plan — Lihat Rencana Perubahan #

Perintah terraform plan membandingkan konfigurasi yang kamu tulis dengan kondisi infrastruktur yang tercatat di state file. Hasilnya adalah rencana perubahan yang menunjukkan persis apa yang akan ditambah, diubah, atau dihapus.

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0abcdef1234567890"
      + instance_type = "t3.micro"
      + tags          = {
          + "Name" = "web-server"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Output ini adalah salah satu fitur terkuat Terraform — kamu bisa melihat persis apa yang akan terjadi sebelum perubahan benar-benar dilakukan. Tidak ada kejutan, tidak ada “ternyata menghapus database production”.

Langkah 3: Apply — Jalankan Perubahan #

Setelah kamu meninjau plan dan yakin semuanya benar, terraform apply akan menjalankan perubahan yang sudah direncanakan. Terraform memanggil API provider yang sesuai, membuat resource yang diminta, dan menyimpan hasilnya ke state file.

Alur ini konsisten di semua provider dan semua skala — baik kamu mengelola satu resource maupun seribu resource. Tidak peduli apakah targetnya AWS, GCP, Azure, atau GitHub — siklusnya selalu sama: write, plan, apply.

HCL — Bahasa Konfigurasi Terraform #

Konfigurasi Terraform ditulis dalam HCL (HashiCorp Configuration Language). HCL dirancang agar mudah dibaca manusia sekaligus mudah diproses mesin. Tidak seperti YAML atau JSON yang generik, HCL dibuat khusus untuk konfigurasi infrastruktur dengan syntax yang ekspresif dan aman.

Setiap blok dalam HCL memiliki tujuan yang jelas. Ada tiga blok dasar yang akan kamu temui di hampir semua konfigurasi Terraform:

# 1. Blok terraform — konfigurasi global dan versi provider
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# 2. Blok provider — koneksi ke layanan eksternal
provider "aws" {
  region = "ap-southeast-1"
}

# 3. Blok resource — infrastruktur yang ingin kamu kelola
resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Blok terraform berisi konfigurasi tentang Terraform itu sendiri — provider apa yang digunakan, versi minimal yang diperlukan, dan backend untuk menyimpan state. Blok provider mengkonfigurasi koneksi ke layanan eksternal — region, credential, dan opsi khusus provider. Blok resource mendefinisikan infrastruktur aktual yang ingin kamu buat dan kelola.

HCL juga mendukung komentar satu baris dengan # atau //, dan komentar multi-baris dengan /* ... */. Untuk konfigurasi Terraform, konvensi umumnya menggunakan #.

State — Memori Terraform #

Setelah terraform apply berhasil, Terraform menyimpan kondisi infrastruktur dalam sebuah file bernama terraform.tfstate. File ini berisi pemetaan antara konfigurasi di kode kamu dan resource aktual di cloud provider.

State adalah alasan Terraform bisa tahu apa yang perlu diubah saat kamu memodifikasi konfigurasi. Tanpa state, Terraform tidak punya cara untuk mengetahui resource mana yang sudah ada, apa parameter yang digunakan saat pembuatan, atau ID resource di cloud provider.

{
  "resources": [
    {
      "type": "aws_instance",
      "name": "web_server",
      "attributes": {
        "id": "i-0abc123def456789",
        "ami": "ami-0abcdef1234567890",
        "instance_type": "t3.micro",
        "public_ip": "54.239.28.85"
      }
    }
  ]
}

Contoh di atas menunjukkan isi state secara sederhana. Ketika kamu mengubah instance_type dari t3.micro ke t3.medium, Terraform membaca state, melihat bahwa instance i-0abc123def456789 sudah ada dengan tipe t3.micro, dan menyimpulkan bahwa perubahan yang diperlukan adalah modify — bukan delete dan create baru.

Konsep state ini akan dibahas lebih mendalam di artikel State pada section Concept.

Multi-Provider — Satu Tool untuk Semua Cloud #

Salah satu keunggulan Terraform dibanding tool sejenis adalah kemampuannya bekerja dengan ratusan provider berbeda dari satu konfigurasi yang sama. Provider bukan hanya cloud provider — apapun yang punya API bisa punya provider Terraform.

# Terraform bisa mengelola resource dari berbagai provider
# dalam satu workspace yang sama

# Resource di AWS
resource "aws_s3_bucket" "storage" {
  bucket = "app-storage-prod"
}

# DNS di Cloudflare — merujuk IP dari instance AWS
resource "cloudflare_record" "dns" {
  zone_id = var.cloudflare_zone_id
  name    = "app"
  value   = aws_instance.web.public_ip
  type    = "A"
}

# Repository di GitHub
resource "github_repository" "app" {
  name        = "my-app"
  description = "Repository aplikasi utama"
  visibility  = "private"
}

Perhatikan bagaimana cloudflare_record.dns merujuk ke aws_instance.web.public_ip secara langsung. Terraform memahami dependency antar provider dan akan membuat resource dalam urutan yang benar — AWS instance duluan, baru DNS record yang merujuk IP-nya. Inilah kekuatan deklarasi: kamu cukup bilang “DNS ini menunjuk ke IP server itu”, dan Terraform yang menentukan urutan eksekusinya.

Provider tersedia untuk AWS, GCP, Azure, Kubernetes, Cloudflare, GitHub, Datadog, PagerDuty, dan ratusan layanan lainnya. Kamu bisa menemukan daftar lengkapnya di Terraform Registry.

Terraform vs Tool Lainnya #

Terraform bukan satu-satunya IaC tool di pasaran. Ada beberapa alternatif yang masing-masing punya pendekatan berbeda. Memahami posisi Terraform di antara alternatif ini membantu kamu tahu kapan Terraform adalah pilihan yang tepat.

flowchart LR
    subgraph IaC["Infrastructure as Code"]
        direction TB
        D["Declarative"]
        I["Imperative"]
    end

    D --> T["Terraform"]
    D --> P["Pulumi"]
    I --> A["Ansible"]
    I --> CF["CloudFormation"]

    T -- "Multi-cloud, HCL" --> R1["Cocok untuk: multi-cloud, infrastruktur"]
    P -- "Multi-cloud, bahasa umum" --> R2["Cocok untuk: developer yang ingin bahasa pemrograman"]
    A -- "Agentless, YAML" --> R3["Cocok untuk: provisioning + config management"]
    CF -- "AWS only, JSON/YAML" --> R4["Cocok untuk: AWS-only, tight integration"]

    style T fill:#e8f5e9,stroke:#2e7d32
    style D fill:#e3f2fd,stroke:#1565c0
    style I fill:#fff3e0,stroke:#e65100

Terraform unggul di skenario multi-cloud dan multi-provider. Jika infrastruktur kamu hanya di AWS dan tidak akan pernah pindah, CloudFormation bisa jadi alternatif yang lebih sederhana. Jika kamu butuh provisioning sekaligus konfigurasi server (install package, edit config file), Ansible lebih tepat. Untuk penjelasan lengkap tentang alternatif dan kapan masing-masing digunakan, lihat artikel Alternatives.

Kapan Terraform Digunakan #

Terraform bukan solusi universal — ada situasi di mana tool ini sangat tepat, dan ada situasi di mana ada pilihan yang lebih baik. Memahami konteks penggunaannya membantu kamu menghindari over-engineering atau memilih tool yang salah.

SANGAT COCOK:
  ✓ Multi-cloud infrastructure (AWS + GCP + Azure sekaligus)
  ✓ Infrastructure yang perlu direplikasi (dev = staging = prod)
  ✓ Tim yang butuh review proses perubahan infrastruktur (GitOps)
  ✓ Disaster recovery — rebuild infrastruktur dari nol dengan cepat
  ✓ Compliance — audit trail setiap perubahan infrastruktur

PERTIMBANGKAN ALTERNATIF:
  ✗ Konfigurasi di dalam server (install nginx, edit /etc/hosts) → pakai Ansible/Chef
  ✗ Hanya AWS dan tidak akan multi-cloud → CloudFormation bisa lebih sederhana
  ✗ Infrastruktur sangat sederhana (1-2 resource) → console mungkin lebih cepat
  ✗ Aplikasi serverless murni → SAM atau SST bisa lebih cocok

Untuk penjelasan lebih mendalam tentang kapan harus dan tidak harus menggunakan Terraform, baca artikel When to Use Terraform.

Ringkasan #

• Terraform adalah IaC tool — infrastruktur didefinisikan sebagai kode HCL, bukan diklik manual di console.
• Bekerja secara deklaratif — kamu mendefinisikan apa yang diinginkan, Terraform yang menentukan bagaimana mencapainya. Ini berbeda dari pendekatan imperatif di mana kamu menulis langkah-langkah secara berurutan.
• Siklus kerja: write → plan → apply — setiap perubahan bisa dilihat dan disetujui sebelum dijalankan, menghindari kejutan di production.
• State sebagai memori Terraform — file state mencatat pemetaan antara konfigurasi kode dan resource aktual di cloud, memungkinkan perubahan incremental yang akurat.
• Multi-provider — satu tool untuk mengelola AWS, GCP, Azure, Kubernetes, dan ratusan layanan lain secara bersamaan, dengan dependency antar provider yang otomatis ditangani.
• Cocok untuk semua skala — dari satu server sederhana hingga infrastruktur multi-region yang kompleks, dengan siklus kerja yang tetap sama.

← Sebelumnya: Pengenalan   Berikutnya: Infrastruktur Manual →