Zero-Downtime Infrastructure Deployment Menggunakan Terraform & Ansible pada AWS

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap aplikasi web modern berskala enterprise, ketersediaan tinggi (high availability) dan keandalan sistem (reliability) bukan lagi sekadar fitur tambahan, melainkan prasyarat mutlak operasional. Bayangkan sebuah platform e-commerce dengan transaksi ribuan per detik; setiap detik downtime tidak hanya mengakibatkan kerugian finansial yang masif, tetapi juga merusak reputasi brand secara permanen. Akar masalah dari kegagalan rilis perangkat lunak di masa lalu sering kali berakar pada metode deployment manual, inkonsistensi konfigurasi antar-lingkungan (environment drift), dan ketergantungan pada server tunggal yang rentan terhadap titik kegagalan tunggal (Single Point of Failure).

Secara historis, administrator sistem melakukan SSH langsung ke server produksi untuk memperbarui kode atau mengubah konfigurasi web server (seperti Nginx, PHP-FPM, atau konfigurasi database MySQL). Pendekatan imperatif ini sangat rapuh. Kesalahan ketik satu baris pada file konfigurasi dapat melumpuhkan seluruh layanan web. Selain itu, seiring bertambahnya infrastruktur dari satu server monolitik menjadi kluster terdistribusi yang melibatkan Cloudflare CDN, AWS S3 untuk penyimpanan objek, Redis untuk caching, serta antrean pesan (message queue) berbasis Supervisor, manajemen manual menjadi mustahil dilakukan secara konsisten.

Perbandingan kondisi Sebelum dan Sesudah penerapan Zero-Downtime Infrastructure:

Dengan memadukan Infrastructure as Code (IaC) menggunakan HashiCorp Terraform dan manajemen konfigurasi otomatis menggunakan Ansible, organisasi dapat mencapai siklus rilis yang dapat diprediksi, dapat diulang (repeatable), dan sepenuhnya transparan.

2. Konsep Inti & Deep Dive Arsitektur

Zero-downtime deployment pada arsitektur web modern membutuhkan perpaduan harmonis antara penyediaan infrastruktur awan dan orkestrasi perangkat lunak lapisan aplikasi. Arsitektur ini dirancang dengan memisahkan status data (database, storage) dari logika komputasi (stateless web servers).

Alur eksekusi dimulai dari Terraform yang bertugas memprovisikan sumber daya AWS secara deklaratif: Virtual Private Cloud (VPC), Subnet Publik/Privat, Internet Gateway, Security Groups, Application Load Balancer (ALB), Auto Scaling Groups, RDS MySQL, serta Elasticache Redis. Setelah infrastruktur dasar terbentuk, Ansible mengambil alih untuk melakukan provisioning perangkat lunak pada instans EC2 yang baru dibuat—memasang Nginx, PHP-FPM, Go binary, Node.js, mengonfigurasi SSL/TLS Let's Encrypt, mengatur Fail2ban, hingga menyetel crontab dan queue worker Supervisor.

Berikut adalah visualisasi arsitektur secara struktural:

[ Cloudflare Edge CDN / WAF ]
              |
              v
   [ AWS Application Load Balancer (ALB) ]
              |
        +-----+-----+
        |           |
        v           v
  [ Green EC2 ]  [ Blue EC2 ]  --> (Immutable Instances)
  (Nginx+Go/PHP) (Nginx+Go/PHP)
        |           |
        +-----+-----+
              |
       +------+------+
       |             |
       v             v
[ AWS RDS MySQL ]  [ AWS ElastiCache Redis ]

Pola Immutable Infrastructure memastikan bahwa instans server tidak pernah dimodifikasi secara langsung (in-place update). Ketika ada perubahan kode atau konfigurasi Ansible, AWS Auto Scaling Group akan membuat instans baru yang bersih (Green), melakukan verifikasi kesehatan (health check), mengalihkan lalu lintas dari ALB secara mulus, lalu mematikan instans lama (Blue).

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memilih strategi deployment yang paling optimal, kita harus mengevaluasi beberapa pendekatan populer berdasarkan metrik sumber daya dan kompleksitas:

• Analisis Trade-off: Blue-Green deployment membutuhkan sumber daya komputasi ganda selama proses transisi rilis berlangsung. Namun, ini adalah satu-satunya metode yang menjamin roll-back instan jika terjadi kegagalan fatal pada aplikasi web backend (baik yang dibangun menggunakan PHP, Go, maupun Node.js).

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi, pastikan lingkungan kerja lokal atau mesin CI/CD pipeline Anda memiliki dependensi berikut terinstal dengan versi minimal yang didukung:

• Terraform: >= 1.5.0
• Ansible: >= 2.15.0
• AWS CLI: >= 2.13.0 (dikonfigurasi dengan kredensial IAM yang memiliki hak akses administrator atau setara)
• Git: >= 2.40.0

Verifikasi instalasi dengan perintah terminal:

terraform -version
ansible --version
aws sts get-caller-identity

Pastikan Anda telah menyiapkan struktur direktori proyek enterprise berikut:

aws-zero-downtime/
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
│   └── backend.tf
└── ansible/
    ├── inventory.ini
    ├── playbook.yml
    └── roles/
        └── webserver/
            ├── tasks/main.yml
            └── templates/
                └── nginx.conf.j2

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi State Management & Remote Backend Terraform (terraform/backend.tf)>

[!IMPORTANT] Simpan Terraform state di AWS S3 dengan enkripsi aktif dan kunci DynamoDB untuk mencegah state locking conflict saat dikerjakan oleh tim.

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

provider "aws" {
  region = "ap-southeast-1"
  default_tags {
    tags {
      Environment = "Production"
      ManagedBy   = "Terraform"
    }
  }
}

Langkah 2: Definisi Infrastruktur Utama (terraform/main.tf)

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = {
    Name = "prod-vpc"
  }
}

resource "aws_subnet" "public_1" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-southeast-1a"
  map_public_ip_on_launch = true
  tags = {
    Name = "prod-subnet-public-1"
  }
}

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

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

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

  ingress {
    description = "SSH from Bastion / Admin"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }

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

resource "aws_instance" "web_server" {
  ami                    = "ami-0c55b159cbfafe1f0" # 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               = "production-deployer-key"

  tags = {
    Name = "prod-web-node"
  }
}

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

Langkah 3: Eksekusi Provisioning Terraform

Jalankan perintah berikut di dalam direktori terraform/:

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Langkah 4: Konfigurasi Ansible Inventory (ansible/inventory.ini)

Ambil IP publik dari output Terraform dan masukkan ke dalam file inventaris Ansible:

[webservers]
54.255.120.45 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/production-deployer-key.pem

Langkah 5: Ansible Playbook Utama (ansible/playbook.yml)

---
- name: Provision Enterprise Web Server Stack
  hosts: webservers
  become: yes
  roles:
    - webserver

Langkah 6: Ansible Role untuk Nginx, PHP-FPM, dan Redis (ansible/roles/webserver/tasks/main.yml)

---
- name: Update apt cache and install essential packages
  apt:
    update_cache: yes
    cache_valid_time: 3600
    state: present
    name:
      - nginx
      - php8.2-fpm
      - php8.2-mysql
      - php8.2-redis
      - redis-server
      - fail2ban
      - supervisor

- name: Ensure Nginx and PHP-FPM are running and enabled
  systemd:
    name: "{{ item }}"
    state: started
    enabled: yes
  loop:
    - nginx
    - php8.2-fpm
    - redis-server
    - fail2ban

- name: Deploy custom Nginx configuration
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/sites-available/default
    owner: root
    group: root
    mode: '0644'
  notify:
    - Restart Nginx

- name: Configure Fail2ban for SSH protection
  copy:
    dest: /etc/fail2ban/jail.local
    content: |
      [sshd]
      enabled = true
      port = ssh
      filter = sshd
      logpath = /var/log/auth.log
      maxretry = 3
      bantime = 3600
  notify:
    - Restart Fail2ban

handlers:
  - name: Restart Nginx
    service:
      name: nginx
      state: restarted

  - name: Restart Fail2ban
    service:
      name: fail2ban
      state: restarted

Langkah 7: Template Konfigurasi Nginx (ansible/roles/webserver/templates/nginx.conf.j2)

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.php index.html index.htm;

    server_name _;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }

    client_max_body_size 64M;
}

Jalankan playbook Ansible:

ansible-playbook -i inventory.ini playbook.yml

6. Bedah Kode & Penjelasan Detail Baris Kunci

1. Terraform S3 Backend (backend.tf): Parameter encrypt = true memastikan bahwa state Terraform yang berisi plain-text credentials dan mapping sumber daya AWS dienkripsi menggunakan AWS KMS secara at-rest. dynamodb_table mengaktifkan penguncian terdistribusi agar dua engineer tidak melakukan terraform apply secara bersamaan.
2. Nginx FastCGI Pass (nginx.conf.j2): Baris fastcgi_pass unix:/run/php/php8.2-fpm.sock; menghubungkan web server Nginx langsung dengan proses PHP-FPM melalui Unix Domain Socket. Ini jauh lebih cepat dibandingkan komunikasi berbasis TCP loopback (127.0.0.1:9000) karena memangkas overhead protokol jaringan sistem operasi.
3. Ansible Idempotency (tasks/main.yml): Penggunaan modul standar Ansible (apt, systemd, template) bersifat idempotent. Artinya, jika konfigurasi server sudah sesuai dengan definisi playbook, Ansible tidak akan melakukan perubahan apa pun saat dijalankan ulang, sehingga aman untuk automasi berkelanjutan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam skenario high-concurrency (misalnya menangani flash sale dengan 100.000 request per second), arsitektur di atas harus dikembangkan dengan menambahkan AWS Auto Scaling Group (ASG) yang diintegrasikan dengan Application Load Balancer (ALB).

• Pemisahan Sesi: Sesi PHP atau Node.js tidak boleh disimpan di memori lokal server web (stateless architecture). Sesi harus dialihkan ke kluster AWS ElastiCache Redis.
• Database Scaling: Koneksi database MySQL menggunakan AWS RDS dengan Multi-AZ deployment untuk failover otomatis apabila Availability Zone primer mengalami gangguan.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Jangan pernah melakukan hardcode secret keys, password database, atau API token di dalam file skrip Terraform atau Ansible.

• Anti-Pattern 1: Menyimpan Secret di Git. Solusi: Gunakan AWS Secrets Manager atau HashiCorp Vault, lalu ambil nilai rahasia tersebut secara dinamis saat Ansible berjalan.
• Anti-Pattern 2: Mengabaikan Health Check Target Group ALB. Solusi: Pastikan endpoint /health.php atau /healthz pada aplikasi web merespons dengan status HTTP 200 OK hanya jika koneksi ke MySQL dan Redis bernilai sehat (healthy).

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan infrastruktur, gunakan tool benchmark k6 atau wrk. Contoh skrip pengujian menggunakan wrk untuk 10 koneksi selama 30 detik:

wrk -t12 -c400 -d30s http://54.255.120.45/

Tuning Performa Sistem Operasi Linux (/etc/sysctl.conf):

# Tingkatkan batas maksimal file descriptor untuk Nginx
fs.file-max = 2097152

# Optimasi TCP backlog untuk menangani lonjakan koneksi
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Reuse koneksi TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

Terapkan perubahan kernel di atas dengan menjalankan perintah sudo sysctl -p.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis infrastruktur ini ke lingkungan produksi yang sesungguhnya, pastikan Anda telah melalui checklist berikut:

• Terraform state terenkripsi di S3 dengan DynamoDB Lock aktif.
• Semua kredensial sensitif dikelola via AWS Secrets Manager / Environment Variables.
• Aturan Firewall (Security Groups & Fail2ban) dikonfigurasi seketat mungkin (Principle of Least Privilege).
• SSL/TLS Certificate aktif dan terkonfigurasi redirect HTTP ke HTTPS.
• Load Balancer Health Check teruji menangani kegagalan instans web.
• Backup otomatis database RDS dijadwalkan secara rutin.

Dengan memadukan ketepatan deklaratif Terraform dan fleksibilitas otomatisasi Ansible, organisasi Anda kini memiliki fondasi infrastruktur web tingkat enterprise yang tangguh, aman, dan siap mencapai ketersediaan 99.99% tanpa downtime.