Otomasi Infrastruktur Skala Besar Menggunakan Terraform dan Ansible

1. Titik Awal Masalah: Mengapa Arsitektur Lama Sering Ambruk di Produksi

Ingatkah Anda malam ketika server produksi tiba-tiba down tepat saat kampanye flash sale dimulai, dan Anda harus meraba-raba gelapnya konfigurasi server via SSH pukul 02.00 pagi? Dulu, saya sering mengalaminya. Menyalakan instance EC2 secara manual, menginstal Nginx, memasang PHP-FPM, melakukan tuning Redis, lalu mengatur DNS record A dan Cloudflare secara klik-sana-sini adalah resep mujarab untuk stres tingkat tinggi. Pendekatan pets, not cattle ini membuat setiap server memiliki 'kepribadian unik' yang mustahil direplikasi dengan tepat saat bencana melanda.

Di dunia infrastruktur skala besar, memelihara server secara manual adalah dosa besar yang dibayar mahal dengan downtime. Ketika aplikasi backend Node.js atau Go kita butuh melakukan scaling secara horizontal demi melayani jutaan WebSocket connection dan request API, kita tidak boleh lagi bergantung pada jari manusia yang lelah. Kita butuh sebuah standar kebenaran tunggal (single source of truth) yang memastikan setiap baris kode, konfigurasi Nginx, hingga aturan firewall Fail2ban terpasang secara presisi dan konsisten di atas fondasi awan. Di sinilah kombinasi Terraform dan Ansible masuk sebagai penyelamat, mengubah kekacauan manual menjadi simfoni otomasi yang elegan.

Namun, sebelum kita merangkai kode dan menatap terminal, mari kita intip bagaimana sebenarnya mekanisme kolaborasi kedua alat ini bekerja di balik layar, tanpa ada unsur sihir di dalamnya.

2. Di Balik Layar: Bagaimana Sistem Ini Bekerja Tanpa Sihir

Banyak pemula terjebak dalam kebingungan: "Kapan saya harus pakai Terraform, dan kapan saya harus pakai Ansible? Bukankah keduanya sama-sama untuk bikin server?" Pertanyaan bagus. Mari kita bedah menggunakan analogi sederhana: Terraform adalah arsitek dan tukang batu yang membangun fondasi rumah, dinding, dan atapnya. Sementara Ansible adalah desainer interior yang masuk setelah rumah berdiri, mengecat dinding, memasang AC, dan menata perabotan di dalamnya.

Dalam ekosistem kita, Terraform bertindak sebagai Infrastructure as Code (IaC) berbasis deklaratif yang fokus pada Provisioning. Ia berinteraksi langsung dengan Cloud Provider (misal AWS, GCP, atau Cloudflare) untuk menciptakan instance, mengatur VPC, memesan S3 bucket untuk storage aset statis, hingga mengonfigurasi DNS record dan manajemen sertifikat SSL/TLS Let's Encrypt. Setelah instance VM menyala dan siap, giliran Ansible yang mengambil alih kemudi.

Ansible menggunakan pendekatan Configuration Management berbasis push over SSH. Ia masuk ke dalam OS Linux (biasanya Ubuntu LTS atau Debian), mengeksekusi Ansible Playbook untuk menginstal paket-paket penting seperti Supervisor, Postfix untuk SMTP mail relay, Redis untuk caching session backend PHP atau Node.js, hingga memasang konfigurasi Nginx dan reverse proxy Caddy. Keduanya tidak saling tumpang tindih; mereka saling melengkapi layaknya orkestra simfoni yang harmonis. Dan untuk mencapai titik harmonis ini, kita harus menentukan kompromi arsitektural yang tepat sejak hari pertama.

3. Pilihan Pendekatan & Kompromi yang Harus Diambil

Dalam merancang arsitektur otomasi skala besar, tidak ada peluru perak (silver bullet). Anda selalu dihadapkan pada trade-off antara kecepatan eksekusi, kompleksitas pemeliharaan, dan fleksibilitas lingkungan. Pilihan pertama yang harus saya ambil biasanya berkisar pada bagaimana mengelola State Terraform dan struktur direktori Ansible.

Di satu sisi, kita bisa menggabungkan seluruh resource cloud—mulai dari database MySQL/MariaDB RDS, Redis cache cluster, CDN Cloudflare, hingga EC2 instances—dalam satu monolit Terraform raksasa. Keuntungannya? Mudah melihat gambaran besar. Kerugiannya? Ketika ada satu baris salah ketik, state lock bisa mengunci seluruh tim, dan proses terraform plan akan memakan waktu hingga belasan menit hanya untuk memvalidasi resource yang tidak berubah.

Kompromi terbaik yang saya terapkan di lingkungan enterprise adalah Modularisasi Multi-Environment berbasis Workspace atau Direktori Terisolasi, dipadukan dengan Dynamic Inventory Ansible. Kita memisahkan state file untuk networking, database, dan compute application tier. Terraform membuat infrastruktur dasarnya, lalu mengeluarkan output berupa IP publik server yang secara otomatis dibaca oleh Ansible melalui Dynamic Inventory plugin. Dengan cara ini, jika server web Nginx / PHP-FPM kita mengalami lonjakan trafik dan harus melakukan autoscaling, Terraform memutar node baru, dan Ansible langsung menyuntikkan dependensi keamanan serta konfigurasi sistem tanpa intervensi manual.

[!IMPORTANT] Jangan pernah menyimpan file terraform.tfstate di local disk secara sembarangan jika Anda bekerja dalam tim. Selalu gunakan remote backend seperti AWS S3 dengan DynamoDB untuk state locking guna mencegah race condition antar engineer.

4. Meracik Lingkungan: Persiapan & Prasyarat Lapangan

Sebelum kita menulis baris kode pertama, pastikan perlengkapan tempur di workstation Anda sudah lengkap. Kita tidak ingin di tengah jalan terhenti karena versi CLI yang kedaluwarsa. Standar minimum yang saya gunakan di tim saat ini adalah Terraform v1.6+ dan Ansible v2.15+.

Mari kita siapkan struktur direktori proyek yang bersih dan scalable. Struktur yang berantakan adalah awal dari bencana infrastruktur. Buatlah layout seperti berikut di dalam repository Git Anda:

infra-master/
├── terraform/
│   ├── environments/
│   │   ├── staging/
│   │   └── production/
│   │       ├── main.tf
│   │       ├── variables.tf
│   │       ├── outputs.tf
│   │       └── terraform.tfvars
│   └── modules/
│       ├── vpc/
│       ├── compute/
│       └── dns/
└── ansible/
    ├── inventory/
    │   └── dynamic_aws_ec2.yml
    ├── playbooks/
    │   ├── site.yml
    │   └── roles/
    │       ├── common/
    │       ├── nginx/
    │       ├── php-fpm/
    │       └── redis/
    └── ansible.cfg

Pastikan Anda telah menginstal AWS CLI (atau provider cloud pilihan Anda) dan melakukan autentikasi yang benar. Selain itu, pastikan SSH Key pair sudah terdaftar di cloud provider Anda agar Ansible dapat masuk ke dalam server yang baru saja di-provision oleh Terraform tanpa hambatan otentikasi. Setelah fondasi direktori ini siap, kita bisa langsung melangkah ke jantung implementasi teknisnya.

5. Langkah Implementasi: Membangun Solusi yang Tangguh

Bagian paling mengasyikkan dari pekerjaan kita adalah melihat kode berubah menjadi infrastruktur nyata yang bernapas. Mari kita mulai dari sisi Terraform terlebih dahulu. Kita akan membangun modul compute sederhana yang mendeklarasikan sebuah server web untuk menghosting aplikasi web modern kita.

Berikut adalah contoh file main.tf di dalam direktori terraform/environments/production/ untuk memprovisi instance EC2 lengkap dengan tag yang rapi:

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "company-infra-state-bucket"
    key            = "production/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-lock-table"
  }
}

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

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0" # Ubuntu 22.04 LTS
  instance_type = "t3.medium"
  key_name      = "production-deployer-key"

  vpc_security_group_ids = [aws_security_group.web_sg.id]

  tags = {
    Name        = "Prod-WebServer-01"
    Environment = "production"
    ManagedBy   = "Terraform"
    Role        = "web"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "production-web-sg"
  description = "Allow HTTP, HTTPS, and SSH"

  ingress {
    description = "TLS from Cloudflare/World"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP from World"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH from Bastion/Office"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.50/32"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

output "web_instance_ip" {
  value       = aws_instance.web_server.public_ip
  description = "Public IP address of the web server for Ansible inventory"
}

Setelah jalankan terraform apply dan instance menyala, output IP publik tersebut akan langsung kitaumpankan ke Ansible. Mari kita buat Ansible Playbook (ansible/playbooks/site.yml) untuk mengonfigurasi server web tersebut agar langsung siap menjalankan aplikasi web berkinerja tinggi:

---
- name: Provision and Configure Production Web Server
  hosts: webservers
  become: yes
  vars:
    app_user: "www-data"
  roles:
    - common
    - nginx
    - php-fpm
    - redis
    - security

Di dalam folder roles/nginx/tasks/main.yml, kita mendefinisikan instalasi Nginx dan penyalinan virtual host yang dioptimalkan untuk performa tinggi:

---
- name: Install Nginx Web Server
  apt:
    name: nginx
    state: present
    update_cache: yes

- name: Ensure Nginx is running and enabled on boot
  service:
    name: nginx
    state: started
    enabled: yes

- name: Upload Optimized Nginx Site Configuration
  template:
    src: default.conf.j2
    dest: /etc/nginx/sites-available/default
    owner: root
    group: root
    mode: '0644'
  notify: Restart Nginx

- name: Enable Virtual Host
  file:
    src: /etc/nginx/sites-available/default
    dest: /etc/nginx/sites-enabled/default
    state: link
  notify: Restart Nginx

[!TIP] Gunakan handler notify di Ansible untuk menghindari restart service yang berulang-ulang di setiap task. Service hanya akan di-restart sekali di akhir eksekusi jika ada file konfigurasi yang benar-benar berubah.

Namun, di balik kemulusan skrip di atas, ada beberapa baris kode krusial yang sering kali menjadi jebakan maut jika ditulis secara asal-asalan.

6. Membedah Baris Kode Krusial yang Kerap Menjebak

Mari kita bedah sebuah konfigurasi template Nginx (default.conf.j2) yang sering menjadi titik kegagalan performa ketika menangani ribuan request HTTP per detik. Perhatikan blok pengaturan fastcgi timeout dan buffering berikut ini:

server {
    listen 80;
    server_name example.com;
    root /var/www/html/public;

    index index.php index.html index.htm;

    # Jebakan klasik: Buffer terlalu kecil menyebabkan upstream sent headers bertumpuk
    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        
        # Parameter krusial untuk mencegah gateway timeout pada backend berat
        fastcgi_read_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_connect_timeout 60;
        
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }

    location ~ /\.ht {
        deny all;
    }
}

Kesalahan fatal yang sering dilakukan engineer pemula adalah melupakan pengaturan fastcgi_buffer_size dan fastcgi_buffers. Ketika aplikasi PHP backend menghasilkan output HTML atau JSON berukuran besar, Nginx default akan melempar error 502 Bad Gateway karena buffer terlampau cepat penuh. Dengan menyertakan parameter tuning ini secara otomatis via Ansible, kita menyelamatkan aplikasi dari kegagalan senyap di tengah produksi.

Lantas, bagaimana sistem kita bereaksi ketika ribuan pengguna mulai menyerbu secara bersamaan?

7. Bertahan di Bawah Tekanan: Skenario Traffic Nyata

Ujian sejati dari sebuah infrastruktur otomatis bukan pada saat pertama kali dinyalakan, melainkan pada detik-detik ketika lonjakan trafik tak terduga (spike traffic) menghantam sistem Anda. Bayangkan platform e-commerce klien kami mendadak diserbu 50.000 concurrent users karena viral di media sosial.

Karena kita menggunakan Terraform untuk memprovisi Load Balancer (AWS ALB) di depan sekumpulan instance EC2, serta memisahkan database ke dalam instance RDS MariaDB berkapasitas tinggi dengan Redis cluster untuk session caching, arsitektur kita bernapas secara dinamis. Terraform memastikan Auto Scaling Group (ASG) siap menambah kapasitas node compute secara otomatis berdasarkan metrik CPU utilization (>75%).

Di saat yang sama, Ansible memainkan peran krusial dalam memastikan bahwa setiap instance baru yang dipintal oleh ASG langsung membawa profil keamanan yang seragam. Fail2ban langsung aktif memblokir percobaan brute-force pada port SSH, UFW firewall hanya membuka port 80 dan 443 dari Cloudflare edge, dan modul Postfix lokal dikonfigurasi sebagai relay untuk mengirimkan email transaksional pelanggan tanpa risiko masuk folder spam (dengan SPF, DKIM, dan DMRC records yang sebelumnya telah di-set secara otomatis oleh Terraform pada AWS Route53).

Namun, perjalanan menuju kesempurnaan otomasi tidak pernah mulus tanpa beberapa luka bakar akibat salah langkah di masa lalu.

8. Jebakan Klasik & Cara Menghindarinya Sebelum Meledak

Pengalaman adalah nama yang diberikan orang untuk kesalahan-kesalahan mereka. Selama bertahun-tahun membangun infrastruktur berskala besar, saya telah mengumpulkan daftar "dosa besar" yang sebaiknya Anda hindari sejak hari pertama:

[!WARNING] Jangan pernah mencampur state development dan production ke dalam satu file state Terraform! Isolasi state adalah harga mati. Satu kecerobohan dengan perintah terraform destroy pada workspace yang salah dapat melenyapkan seluruh data pelanggan dalam hitungan detik.

Jebakan kedua yang sering menjebak tim adalah Hardcoding Secrets di dalam Ansible Playbook. Menyimpan password database MySQL, secret key API Cloudflare, atau private SSH key langsung di dalam file YAML playbook adalah tiket ekspres menuju data breach. Selalu gunakan Ansible Vault untuk mengenkripsi data sensitif, atau integrasikan Terraform dengan AWS Secrets Manager / HashiCorp Vault agar nilai rahasia disuntikkan secara aman saat runtime.

Jebakan ketiga: Mengabaikan idempotensi di Ansible. Pastikan setiap task Ansible yang Anda tulis bersifat idempotent—artinya, jika playbook dijalankan 10 kali berturut-turut pada server yang sama, tidak akan ada perubahan destruktif yang terjadi setelah eksekusi pertama. Hindari penggunaan modul shell atau command mentah jika masih ada modul natif Ansible yang bisa digunakan.

Setelah semua jebakan dihindari dan kode tertulis rapi, saatnya kita melakukan uji nyali untuk membuktikan ketangguhannya.

9. Uji Nyali: Mengukur Performa di Titik Batas

Sebelum merilis sistem ke hadapan publik, seorang arsitek sejati tidak akan berkata "Insya Allah aman". Kami membuktikannya dengan data empiris melalui Stress Testing. Di lingkungan staging, kami menggunakan tool seperti k6 atau Apache Bench (ab) untuk menghujani endpoint aplikasi web kita dengan ribuan virtual users.

Kita jalankan skenario pengujian beban tinggi:

# Menjalankan uji beban k6 pada endpoint API utama
k6 run --vus 1000 --duration 60s load-test-script.js

Melalui pengujian ini, kita memantau metrik krusial: Berapa rata-rata latensi respons Nginx? Apakah penggunaan memori Redis stabil atau mengalami memory leak? Bagaimana respons pool PHP-FPM saat menghadapi antrean request yang menumpuk? Jika ditemukan bottleneck—misalnya koneksi ke database MariaDB mencapai batas maksimal—kita tinggal menyesuaikan parameter max_connections melalui Ansible Playbook dan memperbarui kapasitas instance RDS lewat Terraform secara cepat dan terukur.

Semua persiapan telah matang, pengujian telah dilewati. Kini saatnya meninjau catatan terakhir sebelum tombol rilis ditekan.

10. Catatan Lapangan & Checklist Sebelum Rilis

Sebagai penutup dari panduan komprehensif ini, mari kita rangkum seluruh perjalanan arsitektur kita ke dalam sebuah checklist operasional lapangan yang wajib Anda centang sebelum melakukan deployment perdana ke lingkungan produksi:

• State Isolation: Pastikan remote backend Terraform terenkripsi di S3 dengan DynamoDB locking yang aktif.
• Idempotency Check: Jalankan Ansible Playbook dua kali berturut-turut pada server uji dan pastikan tidak ada perubahan (changed=0 pada eksekusi kedua).
• Secrets Management: Pastikan tidak ada password atau API token hardcoded; gunakan Ansible Vault atau Secret Manager.
• Security Hardening: Pastikan UFW/Fail2ban aktif, SSH key-based authentication diwajibkan, dan port yang tidak perlu tertutup rapat.
• DNS & Edge Caching: Verifikasi record A, MX, SPF, DKIM, DMARC, serta aturan cache Cloudflare sudah terkonfigurasi dengan benar.
• Monitoring & Logging: Pastikan agen log (seperti Datadog, Prometheus, atau ELK stack) terpasang otomatis via Ansible di setiap node baru.

Inilah esensi sejati dari otomasi infrastruktur skala besar: tidur dengan tenang di malam hari, bukan karena tidak ada masalah yang terjadi, tapi karena kita tahu sistem kita memiliki kemampuan untuk bangkit, memperbaiki, dan menskalakan dirinya sendiri secara otomatis.