Literally Web ID | Automasi Infrastruktur Kubernetes Menggunakan Terraform & ArgoCD

1. Konteks Industri & Analisis Akar Masalah

Di era modern, arsitektur web skala enterprise menuntut waktu aktif 99.99%, kemampuan penskalaan elastis secara instan, dan zero-downtime deployment. Ekosistem aplikasi web tidak lagi berdiri sendiri pada satu server fisik atau VPS sederhana. Ia didukung oleh tumpukan yang kompleks: frontend modern (React/Vue), backend berperforma tinggi (Go/Node.js/PHP-FPM), web server (Nginx/Caddy) sebagai reverse proxy dan terminasi SSL, database terdistribusi (MySQL/PostgreSQL), sistem caching dan message queue (Redis/RabbitMQ), serta perlindungan edge (Cloudflare WAF, DNS, SPF/DKIM/DMARC).

Namun, mengelola infrastruktur pendukung ini secara manual (manual provisioning melalui cloud console atau SSH ke server satu per satu) menciptakan apa yang disebut sebagai "Configuration Drift"—perbedaan tak terlihat antara dokumentasi, environment staging, dan environment production. Hal ini memicu bottleneck operasional yang parah:

Bottleneck Skalabilitas: Penambahan node kluster Kubernetes atau konfigurasi ulang record DNS dan bucket S3 membutuhkan waktu berjam-jam bahkan berhari-hari.
Human Error: Kesalahan pengetikan pada file konfigurasi Nginx, miskonfigurasi secret database, atau keterlambatan pembaruan sertifikat SSL Let's Encrypt sering menyebabkan downtime fatal.
Auditability Rendah: Sulit melacak siapa yang mengubah parameter kernel, mengubah aturan firewall, atau memperbarui image aplikasi di backend.

Sebelum vs Sesudah Penerapan GitOps (Terraform + ArgoCD)

| Parameter | Sebelum (Manual & Imperatif) | Sesudah (Declarative GitOps - Terraform & ArgoCD) | | :--- | :--- | :--- |: | Provisioning Infrastruktur | Klik console AWS/GCP, manual setup VPS, instalasi Nginx/Docker manual. | Ditulis dalam kode Terraform, dieksekusi via pipeline otomatis (terraform apply). | | Deployment Aplikasi | SSH ke server, git pull, composer/npm install, restart PHP-FPM/Node. | Commit ke Git repository, ArgoCD otomatis melakukan sinkronisasi ke kluster. | | Manajemen Secret | File .env plaintext di server atau dibagikan via chat tidak aman. | HashiCorp Vault terintegrasi dengan External Secrets Operator di Kubernetes. | | Recovery Time (DR) | Berhari-hari membangun ulang server dan memulihkan konfigurasi web server. | Hitungan menit dengan menjalankan ulang state Terraform dan pemulihan kluster ArgoCD dari Git. |

2. Konsep Inti & Deep Dive Arsitektur

Pendekatan modern dalam mengelola infrastruktur web berfokus pada dua pilar utama: Infrastructure as Code (IaC) menggunakan HashiCorp Terraform dan GitOps Continuous Delivery menggunakan ArgoCD.

Alur Eksekusi Data (Data Flow Architecture)

+-------------------------------------------------------------------------+
|                         Developer / Engineer                            +
+-------------------------------------------------------------------------+
          |                                           |
          | (1. Push IaC Code)                        | (2. Push K8s Manifests)
          v                                           v
+-----------------------+                   +-----------------------------+
| Terraform Repository  |                   |    Application Repository   +
+-----------------------+                   +-----------------------------+
          |                                           |
          | (Terraform Cloud / CI Pipeline)           | (Monitors Repo)
          v                                           v
+-----------------------+                   +-----------------------------+
| Cloud Infrastructure  |                   |           ArgoCD            |
| (AWS VPC, EKS, RDS)   |                   +-----------------------------+
+-----------------------+                                  |
          |                                                | (3. Sync & Apply)
          +------------------------+-----------------------+
                                   |
                                   v
                     +--------------------------+
                     |   Kubernetes Production  | 
                     |   (Pods, Services, Ingress)|
                     +--------------------------+

Terraform Layer: Bertugas memprovisikan pondasi fisik dan logis di cloud provider (seperti AWS EKS, VPC, Subnet, Load Balancer, S3 Bucket untuk storage aset statis, dan database RDS). Terraform membaca file .tf deklaratif, mencocokkannya dengan state file, dan melakukan api calls ke penyedia cloud.
ArgoCD Layer: Berjalan di dalam kluster Kubernetes yang telah diprovisikan oleh Terraform. ArgoCD terus-menerus memantau Git repository tempat manifest Kubernetes (Deployment, Service, Ingress, HPA) disimpan. Ketika ada perubahan (commit baru), ArgoCD memaksa desired state di Git agar sama persis dengan live state di dalam kluster Kubernetes.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun sistem otomatisasi, arsitek sering dihadapkan pada pilihan alat (tools). Berikut adalah analisis mendalam perbandingan pendekatan:

Aspek Komparasi	Terraform vs Pulumi	ArgoCD vs FluxCD	HashiCorp Vault vs Kubernetes Secret (Native)
Bahasa Pemrograman	HCL (HashiCorp Configuration Language) vs Python/TypeScript/Go.	GitOps Engine (Declarative Manifests/Helm).	API-driven Secrets Management Engine.
Kurva Belajar	Rendah-Sedang (HCL sangat spesifik, mudah dibaca).	Sedang (Membutuhkan pemahaman konsep Kubernetes CRD).	Tinggi (Memerlukan pemahaman policies, tokens, dan auth methods).
State Management	Membutuhkan remote backend (S3 + DynamoDB untuk locking).	Tidak butuh state terpisah, sumber kebenaran tunggal adalah Git.	Menggunakan enkripsi transit/at-rest yang sangat ketat.
Resource Overhead	Tidak berjalan di runtime kluster (dijalankan saat CI/CD).	Menkonsumsi resource kluster (sekitar 500m CPU, 1GB RAM untuk prod).	Menkonsumsi resource kluster dan membutuhkan high-availability storage.
Trade-off	HCL kurang fleksibel dibanding bahasa umum (TypeScript).	FluxCD lebih ringan (controller-based), ArgoCD memiliki UI dashboard yang superior.	Kompleksitas operasional tinggi untuk pemeliharaan cluster Vault.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi, pastikan Anda telah menyiapkan lingkungan kerja (workstation atau CI/CD runner) dengan spesifikasi dan dependensi berikut:

Sistem Operasi: Ubuntu 22.04 LTS / macOS Ventura+ / WSL2.
Hak Akses: Akun administrator Cloud Provider (AWS/GCP/Azure) dengan hak akses IAM penuh untuk membuat VPC, EKS, dan IAM Roles.
Tools CLI yang Diperlukan:
- terraform (v1.5+)
- kubectl (v1.27+)
- helm (v3.12+)
- awscli (v2+)
- argocd CLI

Verifikasi instalasi dengan menjalankan perintah berikut di terminal:

terraform version
kubectl version --client
helm version
aws --version

5. Panduan Implementasi Langkah demi Langkah

Tahap 1: Provisioning Kluster Kubernetes dengan Terraform

Buat direktori proyek bernama terraform-k8s dan buat file main.tf. File ini akan mengatur pembuatan VPC, Subnet, dan kluster Amazon EKS.

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.23"
    }
  }
  backend "s3" {
    bucket         = "my-enterprise-tf-state-bucket"
    key            = "eks/production/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
  }
}

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

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"

  name = "production-web-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway   = true
  single_nat_gateway   = false
  enable_dns_hostnames = true

  tags = {
    Environment = "production"
    Terraform   = "true"
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "19.15.3"

  cluster_name    = "production-web-cluster"
  cluster_version = "1.27"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 10
      desired_size = 3

      instance_types = ["t4g.xlarge"]
      capacity_type  = "ON_DEMAND"

      labels = {
        Environment = "production"
        Workload    = "web-backend"
      }
    }
  }

  enable_irsa = true
}

output "cluster_endpoint" {
  value = module.eks.cluster_endpoint
}

output "cluster_name" {
  value = module.eks.cluster_name
}

Inisialisasi dan terapkan konfigurasi Terraform:

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Tahap 2: Konfigurasi Akses Kluster dan Instalasi ArgoCD

Setelah kluster EKS aktif, perbarui konfigurasi kubectl lokal Anda:

aws eks update-kubeconfig --region ap-southeast-1 --name production-web-cluster

Buat namespace khusus untuk ArgoCD dan instal menggunakan manifes resmi Helm:

kubectl create namespace argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argocd argo/argo-cd \
  --namespace argocd \
  --set server.service.type=LoadBalancer

Ambil password awal untuk login ke ArgoCD UI:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

Tahap 3: Implementasi GitOps Pipeline menggunakan ArgoCD Application Manifest

Buat file manifest bernama argocd-app.yaml yang mendefinisikan aplikasi web enterprise (menggunakan backend Node.js/Go dan Nginx reverse proxy) yang akan disinkronkan secara otomatis dari Git repository.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-web-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/enterprise-org/k8s-manifests.git'
    targetRevision: HEAD
    path: manifests/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: web-production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Terapkan manifes ArgoCD Application ke kluster:

kubectl apply -f argocd-app.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

backend "s3" pada Terraform (main.tf): Baris ini krusial untuk kolaborasi tim. Menyimpan state Terraform di S3 dengan penguncian DynamoDB mencegah dua engineer menjalankan terraform apply secara bersamaan yang dapat merusak struktur state cloud.
enable_irsa = true (AWS EKS Module): Mengaktifkan IAM Roles for Service Accounts. Ini memungkinkan pod Kubernetes (seperti aplikasi Node.js atau PHP yang terhubung ke AWS S3 untuk upload file media) mengasumsikan peran IAM AWS secara aman tanpa harus menyimpan AWS Access Key di dalam environment variable.
syncPolicy.automated.prune: true & selfHeal: true (ArgoCD): Konfigurasi ini memastikan prinsip Single Source of Truth. Jika ada seseorang yang secara tidak sengaja mengubah konfigurasi secara manual di kluster menggunakan kubectl edit, ArgoCD akan otomatis mendeteksi perbedaan (drift) dan mengembalikannya ke kondisi yang tercatat di Git repository.

[!WARNING] Jangan pernah menonaktifkan fitur prune pada lingkungan produksi tanpa alasan operasional yang mendesak. Tanpa prune, sumber daya Kubernetes yang dihapus dari Git repository akan tetap berjalan di kluster, menyebabkan inkonsistensi sistem dan potensi kebocoran sumber daya.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Menghadapi Flash Sale / High Concurrency Traffic (100.000 Request/detik)

Dalam skenario aplikasi e-commerce enterprise dengan lonjakan trafik ekstrem, arsitektur web harus dirancang dengan ketahanan tinggi:

Frontend & Edge Caching: Cloudflare CDN menangani 80% static request (HTML, CSS, gambar produk yang disimpan di S3). Permintaan dinamis diteruskan ke AWS Application Load Balancer (ALB).
Kubernetes Ingress & Rate Limiting: Nginx Ingress Controller dikonfigurasi dengan pembatasan rate limit (limit_req) untuk mencegah serangan DDoS layer 7.
Horizontal Pod Autoscaler (HPA): Pod backend Node.js dikonfigurasi untuk menskalakan jumlah instance secara otomatis berdasarkan konsumsi CPU (di atas 70%) atau custom metric antrian Redis.

Berikut adalah contoh konfigurasi HPA Kubernetes untuk aplikasi web produksi:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-backend-hpa
  namespace: web-production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-backend
  minReplicas: 5
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

8. Common Pitfalls, Anti-Patterns & Solusi

Anti-Pattern: Menyimpan Secrets secara Plaintext di Git Repository
- Masalah: Menyimpan file .env atau konfigurasi database password langsung ke Git repository berisiko tinggi terhadap kebocoran data.
- Solusi: Gunakan External Secrets Operator yang terintegrasi dengan HashiCorp Vault atau AWS Secrets Manager. ArgoCD hanya membaca manifes referensi secret, sementara nilai asli diambil secara aman di dalam kluster.
Pitfalls: Menggunakan Tag latest pada Docker Image
- Masalah: Menggunakan tag latest membuat ArgoCD dan Kubernetes kesulitan melacak versi spesifik yang berjalan, menyulitkan proses rollback saat terjadi kegagalan deployment.
- Solusi: Gunakan immutable semantic versioning atau Git commit SHA sebagai tag Docker image (misal: v1.4.2 atau git-a1b2c3d).
Pitfalls: Tidak Mengatur Resource Requests dan Limits pada Pod
- Masalah: Pod dapat menghabiskan seluruh memori pada worker node, menyebabkan kernel Linux mematikan proses lain (OOM Killer) dan membuat node kluster crash.
- Solusi: Selalu tentukan parameter resources.requests dan resources.limits untuk CPU dan Memory pada setiap kontainer.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan sistem siap menghadapi beban produksi, lakukan pengujian beban (load testing) menggunakan tool seperti k6 atau wrk. Berikut adalah skrip pengujian k6 untuk menguji endpoint API web backend:

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

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Ramp-up ke 100 users
    { duration: '5m', target: 500 }, // Pertahankan 500 users
    { duration: '2m', target: 1000 },// Lonjakan beban hingga 1000 users
    { duration: '1m', target: 0 },   // Cool-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<200'], // 95% request harus selesai di bawah 200ms
    http_req_failed: ['rate<0.01'],  // Error rate di bawah 1%
  },
};

export default function () {
  const res = http.get('https://api.production-domain.com/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Parameter Tuning Kernel Linux (sysctl) untuk Node Kluster

Untuk menangani koneksi TCP konkuren yang tinggi pada Nginx/In-gress Controller, lakukan tuning pada parameter kernel node worker:

# /etc/sysctl.d/99-kubernetes-node-tuning.conf
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 10000

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan sistem ke production, pastikan Anda telah melewati checklist validasi berikut:

State Security: Remote state Terraform dienkripsi dan dibatasi aksesnya menggunakan IAM Policy ketat.
GitOps Access Control: ArgoCD dikonfigurasi dengan autentikasi SSO (OIDC/SAML) dan pembatasan izin berbasis peran (RBAC).
Secret Management: Tidak ada password atau API key dalam bentuk plaintext di dalam repository Git.
Resource Allocation: Semua deployment Kubernetes memiliki parameter requests dan limits yang terdefinisi dengan jelas.
Observability & Monitoring: Prometheus dan Grafana terpasang untuk memantau metrik kluster, penggunaan CPU/Memory, dan latensi HTTP.
Disaster Recovery: Prosedur backup dan pemulihan state Terraform serta data database teruji secara berkala.

Dengan mengintegrasikan Terraform untuk provisioning infrastruktur dan ArgoCD untuk manajemen aplikasi berbasis GitOps, organisasi Anda mencapai tingkat otomatisasi, keandalan, dan skalabilitas tingkat enterprise yang konsisten di seluruh siklus hidup pengembangan perangkat lunak.

Automasi Infrastruktur Kubernetes Menggunakan Terraform & ArgoCD