L
Infrastructure as Code (IaC) • Literally Web ID

Automated Infrastructure Provisioning dengan Terraform dan Ansible untuk Multi-Cloud Enterprise

⏱️ 18 menit baca • 📅 16 Oct 2026 • 👁️ 1 views
Automated Infrastructure Provisioning dengan Terraform dan Ansible untuk Multi-Cloud Enterprise

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern dan sistem infrastruktur enterprise, kecepatan time-to-market serta ketahanan operasional (resilience) bukan lagi sekadar nilai tambah, melainkan syarat mutlak kelangsungan bisnis. Bayangkan sebuah platform e-commerce skala enterprise yang melayani jutaan pengguna global. Ketika terjadi lonjakan traffic mendadak—misalnya saat kampanye flash sale—keterlambatan dalam melakukan provisioning server baru secara manual (spin up instance, instalasi Nginx, konfigurasi PHP-FPM, pengaturan database MySQL/MariaDB, sinkronisasi Redis cluster, hingga penyesuaian DNS dan SSL Let's Encrypt) dapat mengakibatkan kegagalan sistem total atau downtime yang merugikan jutaan dolar.

Secara historis, administrator sistem mengandalkan skrip shell ad-hoc atau konfigurasi manual melalui UI cloud provider (AWS, GCP, Azure). Pendekatan ini meninggalkan celah besar yang dikenal sebagai Configuration Drift—kondisi di mana status infrastruktur aktual menyimpang dari dokumentasi atau spesifikasi awal akibat perubahan manual yang tidak tercatat. Bottleneck ini menyebabkan inkonsistensi lingkungan antara Development, Staging, dan Production, yang berujung pada bug misterius yang hanya muncul di server produksi.

Sebelum vs Sesudah Penerapan

  • Sebelum (Manual & Ad-Hoc):
    • Waktu provisioning server: 2 hingga 4 jam per node.
    • Tingkat human error tinggi (salah ketik konfigurasi Nginx, lupa setting izin file S3, salah port firewall).
    • Tidak ada riwayat perubahan infrastruktur yang terstruktur.
    • Configuration drift merajalela, menyulitkan proses root cause analysis saat insiden.
  • Sesudah (Automated Infrastructure dengan Terraform & Ansible):
    • Waktu provisioning server (Infrastructure as Code + Configuration Management): 3 hingga 5 menit secara otomatis.
    • Reprodusibilitas 100%: Lingkungan produksi di-deploy dari basis kode yang sama.
    • Zero-touch deployment untuk skalabilitas horizontal (High Availability).
    • Audit trail lengkap melalui version control system (Git) untuk setiap perubahan arsitektur.

2. Konsep Inti & Deep Dive Arsitektur

Untuk mencapai otomatisasi end-to-end yang tangguh, kita membagi tanggung jawab fungsional menjadi dua pilar utama: Terraform (untuk Infrastructure Provisioning - mendefinisikan apa yang harus ada seperti VPC, Subnet, EC2 Instance, S3 Bucket, Security Group) dan Ansible (untuk Configuration Management & Application Deployment - mendefinisikan bagaimana sistem dikonfigurasi, seperti instalasi Nginx, konfigurasi PHP 8.3 FPM, pengaturan Supervisor untuk queue workers, hingga tuning Redis).

Alur Kerja Arsitektural (End-to-End Flow)

[ Developer / CI Pipeline ]
           │
           ├──> 1. Terraform Apply (Provisioning Cloud Resources)
           │      ├── AWS VPC, Subnets, Internet Gateway
           │      ├── EC2 Instances (Web/App Nodes)
           │      └── S3 Remote State & DynamoDB Locking
           │
           └──> 2. Ansible Playbook Execution (Configuration & Deployment)
                  ├── Dynamic Inventory (Fetch IPs from AWS)
                  ├── Nginx / PHP-FPM / Redis Installation
                  ├── SSL / WAF / Fail2ban Hardening
                  └── Supervisor Queue Worker Setup

Di balik layar, Terraform berinteraksi dengan Cloud Provider API menggunakan deklaratif HCL (HashiCorp Configuration Language), menyimpan status aktual dalam state file yang diamankan di S3. Setelah instance aktif, Terraform memicu atau menyerahkan eksekusi selanjutnya ke Ansible. Ansible menggunakan dynamic inventory untuk mendeteksi IP instance baru, melakukan SSH (dengan kunci privat yang aman), dan menjalankan serangkaian task idempotén untuk menyiapkan lingkungan web server secara presisi.


3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun pipeline otomatisasi, seringkali muncul perdebatan mengenai batasan tanggung jawab antara Terraform dan Ansible. Tabel di bawah menyajikan analisis komparatif mendalam dari berbagai aspek teknis:

Parameter Komparasi Terraform (Infrastructure Provisioning) Ansible (Configuration Management) Kombinasi Sinergis (Terraform + Ansible)
Fokus Utama Manajemen Sumber Daya Cloud (VM, Network, DB) Manajemen OS, Paket, dan Aplikasi Pengelolaan Siklus Hidup Infrastruktur Menyeluruh
Model Eksekusi Deklaratif (Mencari desired state dari state file) Prosedural/Idempotén (Menjalankan task secara berurutan) Terraform membangun fondasi, Ansible mengisi isinya
Manajemen State Membutuhkan Remote State (S3 + DynamoDB) Stateless (Mengandalkan fakta sistem target) Kombinasi optimal: State cloud aman, state OS dinamis
Latensi & Konsumsi CPU Rendah saat plan/apply (Go binary) Sedang (Membutuhkan modul Python di target node) Efisien jika dieksekusi melalui runner terpusat
Skalabilitas Multi-Cloud Sangat Kuat (Mendukung AWS, GCP, Azure, Cloudflare) Sangat Kuat (Mendukung berbagai distro Linux/Unix) Menyediakan arsitektur multi-cloud yang konsisten

[!TIP] Jangan pernah menggunakan Ansible untuk membuat VPC atau Load Balancer cloud, dan jangan gunakan Terraform untuk menginstal paket aplikasi internal yang sering berubah (seperti source code web PHP/Node.js). Biarkan Terraform menangani infrastruktur statis dan Ansible menangani konfigurasi dinamis.


4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menyelami implementasi kode, pastikan lingkungan kerja (Local Workstation atau CI/CD Runner) memiliki dependensi berikut dengan versi minimum yang disyaratkan:

  • Terraform: Versi >= 1.6.0
  • Ansible: Versi >= 2.15.0
  • AWS CLI: Terkonfigurasi dengan credential yang memiliki hak akses IAM administrator.
  • Python 3.10+ & Boto3: Diperlukan oleh Ansible untuk berinteraksi dengan AWS API (Dynamic Inventory).

Verifikasi Instalasi:

terraform --version
ansible --version
aws --version
python3 -c "import boto3; print(boto3.__version__)"

Pastikan Anda telah menyiapkan variabel lingkungan (Environment Variables) untuk otentikasi AWS:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah implementasi nyata struktur kode lengkap untuk mendeploy arsitektur web high-availability (Nginx + PHP-FPM + MySQL RDS + S3 Storage) menggunakan Terraform dan Ansible.

A. Manajemen State File yang Aman di S3 (Terraform Backend)

Buat file backend.tf untuk mengonfigurasi penyimpanan state jarak jauh di S3 dengan penguncian DynamoDB guna mencegah konflik konkurensi (state locking).

# backend.tf
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "enterprise-terraform-state-bucket-prod"
    key            = "web-infrastructure/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-locks"
  }
}

provider "aws" {
  region = "us-east-1"
  default_tags {
    tags {
      Environment = "Production"
      ManagedBy   = "Terraform"
      Project     = "EnterpriseWebPlatform"
    }
  }
}

B. Desain Modul Terraform untuk High Availability

Buat file main.tf yang mendefinisikan VPC, Subnet publik/privat, Security Group untuk web server, serta EC2 instance yang bertindak sebagai web node.

# main.tf
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "enterprise-vpc"
  }
}

resource "aws_subnet" "public_1" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "us-east-1a"

  tags = {
    Name = "enterprise-public-subnet-1"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "enterprise-web-sg"
  description = "Allow HTTP, HTTPS, and SSH"
  vpc_id      = aws_vpc.main.id

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

  ingress {
    description = "Allow HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow SSH from corporate VPN"
    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"]
  }

  tags = {
    Name = "enterprise-web-sg"
  }
}

resource "aws_instance" "web_node" {
  ami                    = "ami-0c7217cdde317cfec" # Ubuntu 22.04 LTS
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.public_1.id
  vpc_security_group_ids = [aws_security_group.web_sg.id]
  key_name               = "enterprise-deploy-key"

  root_block_device {
    volume_size           = 50
    volume_type           = "gp3"
    encrypted             = true
    delete_on_termination = false
  }

  tags = {
    Name = "enterprise-web-node-01"
  }
}

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

C. Konfigurasi Konvergen dengan Ansible Playbooks

Buat file dynamic inventory aws_ec2.yml untuk otomatis mendeteksi instance yang baru dibuat oleh Terraform:

# aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: Production
  instance-state-name: running
hostnames:
  - ip-address
keyed_groups:
  - key: tags.Environment
    prefix: env

Buat Ansible Playbook utama (site.yml) untuk mengonfigurasi Nginx, PHP-FPM 8.3, Fail2ban, dan Supervisor:

# site.yml
---
- name: Configure Enterprise Web Stack
  hosts: all
  become: true
  vars:
    php_version: "8.3"
  tasks:
    - name: Update apt cache and upgrade packages
      apt:
        update_cache: yes
        upgrade: safe

    - name: Add Ondrej PHP PPA for modern PHP versions
      apt_repository:
        repo: ppa:ondrej/php
        state: present

    - name: Install Nginx, PHP-FPM, Redis, and Security tools
      apt:
        name:
          - nginx
          - php{{ php_version }}-fpm
          - php{{ php_version }}-mysql
          - php{{ php_version }}-redis
          - php{{ php_version }}-mbstring
          - php{{ php_version }}-xml
          - php{{ php_version }}-curl
          - fail2ban
          - supervisor
        state: present
        update_cache: yes

    - name: Configure Nginx virtual host for enterprise application
      copy:
        dest: "/etc/nginx/sites-available/enterprise.conf"
        content: |
          server {
              listen 80;
              server_name enterprise.local;
              root /var/www/html/public;

              index index.php index.html index.htm;

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

              location ~ \.php$ {
                  include snippets/fastcgi-php.conf;
                  fastcgi_pass unix:/var/run/php/php{{ php_version }}-fpm.sock;
              }

              location ~* \.(jpg|jpeg|png|gif|css|js|ico|svg)$ {
                  expires 30d;
                  add_header Cache-Control "public, no-transform";
              }

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

    - name: Enable Nginx site configuration
      file:
        src: /etc/nginx/sites-available/enterprise.conf
        dest: /etc/nginx/sites-enabled/enterprise.conf
        state: link

    - name: Remove default Nginx site
      file:
        path: /etc/nginx/sites-enabled/default
        state: absent

    - name: Ensure Nginx and PHP-FPM are started and enabled
      service:
        name: "{{ item }}"
        state: started
        enabled: yes
      loop:
        - nginx
        - php{{ php_version }}-fpm
        - fail2ban
        - supervisor

6. Bedah Kode & Penjelasan Detail Baris Kunci

  • backend "s3" pada Terraform: Memindahkan state lokal ke penyimpanan awan terpusat. Parameter dynamodb_table memastikan bahwa jika dua insinyur menjalankan terraform apply secara bersamaan, operasi kedua akan ditolak hingga operasi pertama selesai, mencegah korupsi state.
  • map_public_ip_on_launch = true: Mengotomatiskan pemberian IP publik pada subnet publik sehingga instance dapat langsung diakses melalui SSH oleh Ansible tanpa perlu intervensi manual Elastic IP.
  • apt_repository: ppa:ondrej/php: Memungkinkan sistem Ubuntu standar untuk menginstal versi PHP terbaru (8.3) yang membawa peningkatan performa signifikan dalam hal eksekusi opcode dan manajemen memori.
  • try_files $uri $uri/ /index.php?$query_string; pada Nginx: Pengaturan krusial untuk framework modern berbasis front controller (seperti Laravel atau custom MVC Go/PHP) agar seluruh routing request diarahkan ke index.php secara bersih.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada lingkungan produksi skala besar, sebuah single EC2 instance tidak akan mencukupi. Kita menerapkan Auto Scaling Group (ASG) di Terraform yang diintegrasikan dengan Application Load Balancer (ALB).

Ketika traffic meningkat (misalnya mencapai 80% utilisasi CPU rata-rata selama 3 menit), ASG secara otomatis meluncurkan instance EC2 baru. Untuk memastikan instance baru tersebut siap melayani traffic dengan konfigurasi yang identik, kita menggunakan UserData atau AWS Systems Manager (SSM) Run Command yang memicu Ansible playbook secara otomatis saat instance booting pertama kali (Day-2 Automation). Penyimpanan file media dipindahkan ke AWS S3, dan sesi pengguna disimpan di Redis Cluster terpusat, memastikan arsitektur sepenuhnya stateless dan horizontal scalable.


8. Common Pitfalls, Anti-Patterns & Solusi

  1. Anti-Pattern: Menyimpan kredensial AWS Secret atau Password Database dalam plain text di dalam file Terraform atau Ansible Playbook.
    • Solusi: Gunakan Terraform sensitive = true variables, Ansible Vault untuk mengenkripsi variabel sensitif, atau integrasikan dengan HashiCorp Vault / AWS Secrets Manager.
  2. Anti-Pattern: Mengabaikan State Locking di Terraform.
    • Solusi: Selalu gunakan backend S3 dengan DynamoDB locking di lingkungan tim.
  3. Anti-Pattern: Menulis Ansible Task yang tidak idempotén (misalnya menggunakan modul shell yang menjalankan perintah tanpa memeriksa status eksisting).
    • Solusi: Selalu utamakan modul bawaan Ansible yang dirancang secara inheren bersifat idempotén (seperti apt, copy, service, file).

9. Benchmark, Metrik Kinerja & Tuning Performa

Setelah infrastruktur di-deploy dan dikonfigurasi, lakukan pengujian beban menggunakan k6 atau wrk untuk memastikan Nginx dan PHP-FPM mampu menangani konkurensi tinggi.

Skrip Pengujian k6 (load-test.js):

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

export const options = {
  stages: [
    { duration: '1m', target: 100 }, // Ramp-up ke 100 VU
    { duration: '3m', target: 500 }, // Pertahankan 500 VU
    { duration: '1m', target: 0 },   // Ramp-down
  ],
};

export default function () {
  const res = http.get('http://enterprise.local/');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Tuning Parameter Lanjutan (/etc/php/8.3/fpm/pool.d/www.conf):

Untuk memaksimalkan throughput web server:

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500

Tuning ini mencegah kehabisan memori RAM pada instance t3.medium saat menghadapi lonjakan request HTTP secara simultan.


10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan infrastruktur ini ke lingkungan produksi live, verifikasi checklist berikut:

  • State file Terraform tersimpan di S3 terenkripsi dengan DynamoDB locking aktif.
  • Seluruh variabel sensitif telah dienkripsi menggunakan Ansible Vault.
  • Security Group hanya membuka port yang diperlukan (80, 443, dan SSH terbatas).
  • Fail2ban aktif dan dikonfigurasi untuk melindungi SSH dan Nginx dari serangan brute-force.
  • Pemantauan log (Log rotation & centralization) telah disiapkan.
  • Backup otomatis database dan volume EBS dikonfigurasi secara berkala.

Dengan memadukan kekuatan deklaratif Terraform untuk manajemen infrastruktur cloud dan presisi konvergen Ansible untuk konfigurasi sistem, tim engineering Anda kini memiliki fondasi DevOps kelas enterprise yang andal, aman, dan siap diskalakan tanpa batas.

🏷️ Tags: #Devops #Terraform #Ansible #Infrastructure As Code #Cloud Architecture