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:
- Cloud Provider Account: AWS (IAM User/Role dengan hak AdministratorAccess untuk bootstrapping, atau granular policy minimum privilege).
- Version Control System: GitHub Enterprise atau GitLab dengan hak akses Webhook administrator.
- Server Atlantis: Minimal 1 vCPU, 2GB RAM (Ubuntu 22.04 LTS atau Docker-compatible host).
- Dependency Software:
- Terraform v1.5+
- Atlantis CLI
- Git CLI
- AWS CLI v2
- 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. Penggunaandynamodb_tablemencegah 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 memicuterraform planpada seluruh lingkungan yang menggunakan modul tersebut.
[!WARNING] Jangan pernah menyimpan
ATLANTIS_GH_TOKENatau 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.
- Engineer membuat branch baru:
git checkout -b feature/scale-web-cluster. - Mengubah parameter
instance_countdari3menjadi12pada modul EC2 / Auto Scaling Group. - Mengirimkan PR ke repository utama.
- Atlantis secara otomatis merespons PR dengan memberikan laporan
terraform planyang menunjukkan bahwa 9 instance EC2 baru akan ditambahkan. - Lead Architect memverifikasi bahwa perubahan tersebut aman, lalu memberikan komentar:
atlantis apply. - 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.tfstatedi 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=30pada 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 validatedantflint. - 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.