L
Infrastructure as Code (IaC) β€’ Literally Web ID

Infrastructure as Code (IaC) Skala Besar dengan Terraform dan Atlantis

⏱️ 15 menit baca β€’ πŸ“… 19 Oct 2026 β€’ πŸ‘οΈ 4 views
Infrastructure as Code (IaC) Skala Besar dengan Terraform dan Atlantis

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, kompleksitas infrastruktur telah melonjak drastis. Sistem enterprise saat ini tidak lagi sekadar menjalankan satu atau dua virtual machine (VM) monolitik. Ekosistem tipikal melibatkan load balancer, instance web server (Nginx/Apache), backend berforma tinggi (Go/Node/PHP-FPM), klaster database ber-high availability (MySQL/MariaDB), penyimpanan objek (S3/MinIO), lapisan cache terdistribusi (Redis), sistem antrean (Supervisor/RabbitMQ), hingga sistem keamanan edge seperti WAF, Cloudflare CDN, dan DNS dengan konfigurasi Record A, MX, SPF, DKIM, DMARC yang ketat.

Sebelum adopsi Infrastructure as Code (IaC), pendekatan tradisional yang mengandalkan ClickOps (mengonfigurasi infrastruktur secara manual melalui dashboard AWS, GCP, atau vSphere) menciptakan kerentanan operasional yang parah. Konfigurasi manual mendatangkan masalah Configuration Driftβ€”kondisi di mana dokumentasi fisik atau digital berbeda dengan kenyataan server yang berjalan. Ketika terjadi disaster recovery, pemulihan memakan waktu berhari-hari karena tidak ada cetak biru yang deterministik.

Dengan menerapkan Terraform untuk definisi infrastruktur dan Atlantis untuk otomatisasi Pull Request berbasis kolaborasi Git, organisasi dapat mengeliminasi human error. Tantangan utamanya adalah bagaimana mengelola State Management agar tetap aman, merancang arsitektur modul Terraform yang reusable untuk berbagai lingkungan (Staging dan Production), serta mengintegrasikan workflow ulasan kode infrastruktur secara aman melalui platform seperti GitHub atau GitLab.

2. Konsep Inti & Deep Dive Arsitektur

Secara konseptual, Terraform bekerja dengan cara membandingkan Desired State (kode HCL Anda) dengan Current State (realitas infrastruktur aktual yang direkam dalam file state) untuk menghasilkan sebuah Execution Plan. Namun, dalam lingkungan tim enterprise, menjalankan Terraform secara lokal di mesin masing-masing insinyur adalah sebuah bencana anti-pattern yang memicu korupsi state dan konflik izin akses cloud.

Di sinilah Atlantis masuk sebagai jembatan orkestrasi berbasis webhook. Atlantis berjalan sebagai daemon server di dalam klaster atau VM yang mendengarkan webhook dari Git repository. Ketika seorang engineer membuka Pull Request yang mengubah file Terraform, Atlantis secara otomatis menjalankan terraform plan dan mengirimkan hasilnya sebagai komentar langsung di PR tersebut. Engineer lain dapat mereview, memberikan persetujuan, dan mengetikkan perintah chat seperti atlantis apply di kolom komentar untuk memicu eksekusi otomatis.

Berikut adalah alur visualisasi arsitektur (ASCII Flow Chart):

Developer (Git Commit & Push)
       β”‚
       β–Ό
GitHub / GitLab Pull Request
       β”‚
       β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€(Webhook)─────────────┐
       β–Ό                                   β–Ό
CI/CD or Security Scan             Atlantis Server
                                           β”‚
                              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                              β–Ό                         β–Ό
                     terraform init            terraform plan
                              β”‚                         β”‚
                              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                           β–Ό
                           Comment Plan Back to PR UI
                                           β”‚
                           [ Peer Review & Approval ]
                                           β”‚
                           Developer types: `atlantis apply`
                                           β”‚
                                           β–Ό
                              terraform apply (Cloud API)
                                           β”‚
                                           β–Ό
                           Encrypted Remote State Storage

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa pendekatan Terraform + Atlantis sangat superior dibanding alternatif lain, mari kita lihat matriks perbandingan mendalam berikut:

Parameter Evaluasi ClickOps (Manual Dashboard) CI/CD Tradisional (GitHub Actions / GitLab CI) Terraform + Atlantis (ChatOps PR Workflow)
Reproduksibilitas Buruk (Sangat rentan Configuration Drift) Tinggi (Berbasis kode) Tinggi (Berbasis kode & state terpusat)
Keamanan Kredensial Dibagikan secara manual / rentan bocor Membutuhkan Secret Management kompleks per pipeline Diamankan di server Atlantis/OIDC terpusat
Kolaborasi & Review Tidak ada (Siapa saja bisa mengubah tanpa izin) Memerlukan navigasi UI pipeline yang rumit Alur kerja natural di dalam Pull Request
Locking State Tidak ada (Risiko Race Condition tinggi) Membutuhkan konfigurasi backend lock manual Otomatis mengunci state saat plan/apply berjalan
Kompleksitas Setup Sangat Rendah Sedang Menengah ke Atas
Resource Latency (CPU/RAM) Minimal di lokal Bergantung pada runner cloud Membutuhkan VM dedicated kecil untuk daemon Atlantis

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum membangun pipeline IaC skala besar, pastikan environment Anda memenuhi spesifikasi berikut:

  1. Cloud Provider Account: AWS (IAM User/Role dengan hak AdministratorAccess untuk bootstrapping, atau granular policy minimum privilege).
  2. Version Control System: GitHub Enterprise atau GitLab dengan hak akses Webhook administrator.
  3. Server Atlantis: Minimal 1 vCPU, 2GB RAM (Ubuntu 22.04 LTS atau Docker-compatible host).
  4. Dependency Software:
    • Terraform v1.5+
    • Atlantis CLI
    • Git CLI
    • AWS CLI v2
  5. Domain & DNS: Domain terdaftar (misal: perusahaan.internal) untuk webhook endpoint dan SSL Certificate.

Verifikasi instalasi lokal menggunakan perintah terminal:

terraform version
atlantis version
aws --version

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Struktur Direktori Modular

Buat struktur direktori proyek Terraform yang bersih dan modular:

infrastructure-repo/
β”œβ”€β”€ modules/
β”‚   β”œβ”€β”€ vpc/
β”‚   β”‚   β”œβ”€β”€ main.tf
β”‚   β”‚   β”œβ”€β”€ variables.tf
β”‚   β”‚   └── outputs.tf
β”‚   └── ec2_web/
β”‚       β”œβ”€β”€ main.tf
β”‚       β”œβ”€β”€ variables.tf
β”‚       └── outputs.tf
└── environments/
    β”œβ”€β”€ staging/
    β”‚   β”œβ”€β”€ main.tf
    β”‚   β”œβ”€β”€ variables.tf
    β”‚   └── backend.tf
    └── production/
        β”œβ”€β”€ main.tf
        β”œβ”€β”€ variables.tf
        └── backend.tf

Langkah 2: Menulis Modul VPC (modules/vpc/main.tf)

terraform {
  required_version = ">= 1.5.0"
}

variable "vpc_cidr" {
  type        = string
  description = "CIDR block untuk VPC"
}

variable "environment" {
  type        = string
  description = "Nama environment (staging/production)"
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "vpc-${var.environment}"
    Environment = var.environment
  }
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, 1)
  map_public_ip_on_launch = true

  tags = {
    Name        = "subnet-public-${var.environment}"
    Environment = var.environment
  }
}

output "vpc_id" {
  value = aws_vpc.main.id
}

output "public_subnet_id" {
  value = aws_subnet.public.id
}

Langkah 3: Konfigurasi Environment Production (environments/production/main.tf)

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "corp-terraform-state-bucket-prod"
    key            = "prod/infrastructure/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-lock-table"
    encrypt        = true
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

module "vpc" {
  source      = "../../modules/vpc"
  vpc_cidr    = "10.100.0.0/16"
  environment = "production"
}

Langkah 4: Konfigurasi Atlantis (atlantis.yaml di Root Repository)

version: 3
projects:
  - name: production-infra
    dir: environments/production
    workspace: default
    autoplan:
      when_modified: ["../../modules/**/*.tf", "main.tf", "variables.tf"]
      enabled: true
    workflow: default
workflows:
  default:
    plan:
      steps:
        - init
        - plan
    apply:
      steps:
        - apply

Langkah 5: Menjalankan Server Atlantis via Docker Compose

Simpan file berikut sebagai docker-compose.yml di server pengelola:

version: '3.8'
services:
  atlantis:
    image: runatlantis/atlantis:v0.27.2
    container_name: atlantis
    ports:
      - "4141:4141"
    environment:
      - ATLANTIS_ATLANTIS_URL=https://atlantis.perusahaan.internal
      - ATLANTIS_GH_USER=bot-terraform
      - ATLANTIS_GH_TOKEN=ghp_TokenRahasiaAndaDiSini
      - ATLANTIS_GH_WEBHOOK_SECRET=SecretWebhookRahasia
      - ATLANTIS_REPO_ALLOWLIST=github.com/perusahaan/infrastructure-repo
    restart: unless-stopped

Jalankan dengan perintah:

docker compose up -d

6. Bedah Kode & Penjelasan Detail Baris Kunci

  • backend "s3" { ... }: Baris ini krusial dalam menyimpan file state secara terpusat dan aman. Penggunaan dynamodb_table mencegah concurrent modification jika dua engineer mencoba melakukan apply secara bersamaan.
  • cidrsubnet(var.vpc_cidr, 8, 1): Fungsi bawaan Terraform untuk memecah blok CIDR utama secara matematis menjadi subnet yang lebih kecil, mengurangi potensi kesalahan alokasi IP manual.
  • autoplan.when_modified: Pada konfigurasi Atlantis, parameter ini memastikan bahwa jika ada perubahan yang dilakukan pada level modul (../../modules/**/*.tf), Atlantis akan otomatis memicu terraform plan pada seluruh lingkungan yang menggunakan modul tersebut.

[!WARNING] Jangan pernah menyimpan ATLANTIS_GH_TOKEN atau Secret Key AWS secara hardcode di dalam file konfigurasi publik. Selalu gunakan environment variable yang dienkripsi menggunakan manajer rahasia seperti HashiCorp Vault atau AWS Secrets Manager.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Bayangkan sebuah perusahaan e-commerce menghadapi lonjakan traffic hingga 500.000 req/min saat Flash Sale. Infrastruktur web statis dan database backend harus diskalakan secara otomatis. Dengan arsitektur Terraform + Atlantis, tim infrastructure tidak perlu merombak server satu per satu.

  1. Engineer membuat branch baru: git checkout -b feature/scale-web-cluster.
  2. Mengubah parameter instance_count dari 3 menjadi 12 pada modul EC2 / Auto Scaling Group.
  3. Mengirimkan PR ke repository utama.
  4. Atlantis secara otomatis merespons PR dengan memberikan laporan terraform plan yang menunjukkan bahwa 9 instance EC2 baru akan ditambahkan.
  5. Lead Architect memverifikasi bahwa perubahan tersebut aman, lalu memberikan komentar: atlantis apply.
  6. Klaster web mengembang secara otomatis dalam hitungan menit tanpa downtime, menjaga kestabilan Nginx, PHP-FPM, dan koneksi Redis pool.

8. Common Pitfalls, Anti-Patterns & Solusi

  • Anti-Pattern 1: Mengabaikan State Locking. Menggunakan backend lokal (terraform.tfstate di mesin lokal) dalam tim akan menyebabkan State Corruption saat dua orang melakukan push bersamaan. Solusi: Wajibkan penggunaan S3 Backend dengan DynamoDB State Locking.
  • Anti-Pattern 2: Hardcoding Nilai Konfigurasi. Memasukkan IP address atau password langsung ke dalam file .tf. Solusi: Gunakan variabel (variables.tf) dan Terraform Sensitive Variables untuk data rahasia.
  • Anti-Pattern 3: Terlalu Banyak Resource dalam Satu State File. Menggabungkan seluruh infrastruktur perusahaan (VPC, Database, Kubernetes, DNS Cloudflare) ke dalam satu file state raksasa. Solusi: Pecah state berdasarkan domain atau environment (prinsip Blast Radius Reduction).

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa pipeline IaC dapat diukur melalui metrik:

  • Plan Execution Time: Waktu yang dibutuhkan Atlantis untuk merender terraform plan. Untuk modul besar, durasi ideal berada di bawah 45 detik.
  • API Rate Limiting: Hindari throttling dari Cloud Provider (misal AWS API Rate Limit) dengan mengatur parameter -parallelism=30 pada saat apply jika diperlukan.

Gunakan tool benchmark seperti k6 untuk menguji performa endpoint web yang baru di-deploy oleh Terraform:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://perusahaan.internal/healthcheck');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis sistem IaC berbasis Terraform dan Atlantis ke lingkungan production, pastikan Anda telah mencentang daftar berikut:

  • Remote Backend dengan S3 & DynamoDB Locking aktif dan diuji coba.
  • Atlantis Webhook terenkripsi menggunakan Secret Token yang kuat.
  • Semua modul Terraform telah divalidasi menggunakan terraform validate dan tflint.
  • Kebijakan Least Privilege diterapkan pada akun IAM/Cloud Provider yang digunakan Atlantis.
  • Prosedur Rollback dan Disaster Recovery State telah didokumentasikan dengan jelas.

Dengan mengombinasikan kekuatan deterministik Terraform dan kolaborasi berbasis ChatOps dari Atlantis, organisasi Anda tidak hanya mencapai otomatisasi penuh, tetapi juga membangun budaya transparansi dan keamanan infrastruktur tingkat enterprise.

🏷️ Tags: #Nginx #High Concurrency #Performance #Sysadmin #Web Server