Panduan Lengkap: Automasi Infrastruktur Kubernetes Menggunakan Terraform dan ArgoCD

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, pengelolaan infrastruktur dan deployment aplikasi mengalami pergeseran paradigma yang drastis. Era di mana seorang System Administrator melakukan SSH ke server virtual secara manual untuk memperbarui file konfigurasi Nginx, mengubah rule PHP-FPM, atau men-deploy ulang kode sumber aplikasi telah usang. Pendekatan manual ini menyimpan celah kesalahan manusia (human error), inkonsistensi environment antara staging dan production, serta lambatnya waktu pemulihan saat terjadi kegagalan sistem (Disaster Recovery).

Masalah utama yang sering dihadapi oleh tim Web Engineering, DevOps, dan Cloud Architect adalah Configuration Drift—kondisi di mana keadaan aktual infrastruktur di cloud menyimpang dari dokumentasi atau rancangan awalnya akibat perubahan ad-hoc yang tidak tercatat. Selain itu, proses manajemen state aplikasi web skala besar yang melibatkan komponen kompleks seperti database MySQL/MariaDB terdistribusi, caching Redis, worker background menggunakan Supervisor, hingga edge caching berbasis Cloudflare sering kali menjadi sangat rapuh jika tidak distandarisasi.

Sebelum penerapan automasi penuh menggunakan Infrastructure as Code (IaC) dan GitOps:

• Inkonsistensi Environment: Server development menggunakan versi PHP 8.1 dengan ekstensi berbeda dibanding production (PHP 8.2), menyebabkan bug misterius saat rilis.
• Bottleneck Deployment: Rilis fitur baru memerlukan koordinasi manual yang panjang antara tim developer, network engineer, dan sysadmin.
• Audit Trail yang Buruk: Sulit melacak siapa yang mengubah rule WAF (Web Application Firewall) atau mengubah alokasi resource Redis pada pukul 03.00 pagi.

Sesudah penerapan automasi berbasis Terraform dan ArgoCD:

• Deklaratif & Immutable: Seluruh infrastruktur (VPC, Node Pool Kubernetes, DNS Records, S3 Bucket) didefinisikan dalam kode Terraform.
• Continuous Delivery Otomatis: Perubahan pada manifest Kubernetes di Git repository secara otomatis disinkronkan ke klaster oleh ArgoCD tanpa intervensi manual.
• Reproducibility Sempurna: Pembuatan klaster produksi baru dari nol dapat diselesaikan dalam hitungan menit secara konsisten.

[!IMPORTANT] GitOps bukan sekadar tren teknologi, melainkan fondasi keamanan operasional di mana Git menjadi satu-satunya sumber kebenaran (Single Source of Truth) untuk seluruh sistem.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur GitOps modern menggabungkan dua pilar utama: Provisioning Infrastruktur (Terraform) dan Continuous Delivery Berbasis Pull (ArgoCD). Alur kerja dimulai dari developer atau infrastructure engineer yang melakukan commit dan pull request pada repository Git.

+--------------------------------------------------------------------------+
|                              GIT REPOSITORY                              |
|  +---------------------------+     +----------------------------------+  |  
|  |    Terraform Manifests    |     |   Kubernetes / Helm Manifests    |  |  
|  +-------------+-------------+     +----------------+-----------------+  |  
+----------------|------------------------------------|--------------------+ 
                 | (terraform apply)                  | (Poll / Sync)
+----------------v-------------+     +----------------v-----------------+  |  
|     Cloud Infrastructure     |     |           ArgoCD Engine          |  |  
|  (AWS EKS, VPC, RDS, S3)     |     |   (Kubernetes GitOps Controller) |  |  
+------------------------------+     +----------------+-----------------+  |  
                                                      | (Apply Manifests)
                                     +----------------v-----------------+  |  
                                     |       Production Kubernetes      |  |  
                                     |  (Nginx Ingress, PHP-FPM, Redis) |  |  
                                     +----------------------------------+  |
+--------------------------------------------------------------------------+

Alur Eksekusi Under the Hood:

1. Terraform Phase: Engineer menjalankan terraform apply. Terraform berkomunikasi dengan Cloud Provider API (AWS, GCP, atau Azure) untuk membangun Virtual Private Cloud (VPC), subnet, node cluster Kubernetes (EKS/GKE), hingga provision resource pendukung seperti database MySQL dan bucket S3 untuk penyimpanan asset statis website.
2. ArgoCD Phase: ArgoCD berjalan di dalam klaster Kubernetes yang baru dibuat. Ia memantau repository Git yang berisi manifest aplikasi (Deployment, Service, Ingress, Helm Chart). Jika mendeteksi perbedaan (drift) antara state di Git dan state aktual di klaster Kubernetes, ArgoCD secara otomatis menarik (pull) perubahan tersebut dan menerapkannya.
3. Web Traffic Routing: Traffic pengguna publik masuk melalui Cloudflare CDN, melewati WAF, menuju Load Balancer Cloud provider, masuk ke Nginx Ingress Controller di Kubernetes, diteruskan ke backend web (Node.js/Go/PHP-FPM), yang berinteraksi dengan Redis cache dan database MySQL.

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa kombinasi Terraform dan ArgoCD menjadi standar industri saat ini, mari kita bandingkan dengan pendekatan tradisional.

[!TIP] Gunakan Terraform khusus untuk infrastruktur dasar (lifecycles panjang seperti VPC, Database, Cluster K8s), dan gunakan ArgoCD untuk workload aplikasi (lifecycles pendek seperti Deployment web app, konfigurasi Ingress, CronJob backend).

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengeksekusi kode konfigurasi, pastikan environment lokal maupun CI/CD runner Anda memiliki toolchain berikut dengan versi minimum yang didukung:

• Terraform: Versi >= 1.5.0
• Kubectl: Versi >= 1.28.0
• Helm: Versi >= 3.12.0
• AWS CLI / GCP CLI: Terkonfigurasi dengan hak akses (IAM Role) yang memadai.

Verifikasi instalasi dengan perintah terminal:

terraform -version
kubectl version --client
helm version

Pastikan Anda memiliki variabel environment cloud yang diexport pada terminal:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_REGION="ap-southeast-1"

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Provisioning Infrastruktur dengan Terraform

Buat direktori terraform/ dan buat file main.tf untuk mendefinisikan infrastruktur dasar AWS EKS dan VPC.

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.23"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

variable "aws_region" {
  type    = string
  default = "ap-southeast-1"
}

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

  name = "production-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"
    ManagedBy   = "Terraform"
  }
}

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

  cluster_name    = "production-cluster"
  cluster_version = "1.28"

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

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

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

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

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

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

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

Inisialisasi dan terapkan konfigurasi Terraform:

cd terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan

Langkah 2: Instalasi ArgoCD ke dalam Klaster Kubernetes

Setelah klaster EKS aktif, konfigurasikan kubectl agar terhubung ke klaster baru:

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

Buat namespace khusus untuk ArgoCD dan lakukan instalasi menggunakan manifest resmi:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Ambil password awal administrator ArgoCD:

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

Port-forward untuk mengakses UI ArgoCD secara lokal:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Langkah 3: Konfigurasi Continuous Delivery dengan ArgoCD Application Manifest

Buat file manifest argocd-app.yaml untuk mendaftarkan repository aplikasi web perusahaan Anda ke ArgoCD.

kind: Application
metadata:
  name: production-web-application
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/company/k8s-gitops-manifests.git'
    targetRevision: HEAD
    path: charts/web-app
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Terapkan aplikasi ke ArgoCD:

kubectl apply -f argocd-app.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dari skrip di atas untuk memastikan pemahaman arsitektural yang mendalam:

1. enable_nat_gateway = true dan single_nat_gateway = false (Terraform VPC Module):
   • Fungsi: Mengonfigurasi NAT Gateway di setiap Availability Zone (AZ). Pendekatan multi-nat (single_nat = false) sangat krusial untuk lingkungan produksi web aplikasi karena mencegah single point of failure. Jika satu AZ down, traffic dari private subnet di AZ lain tetap dapat mengakses internet (misalnya untuk menarik update image Docker atau query API eksternal) tanpa terganggu.
2. capacity_type = "ON_DEMAND" (EKS Node Groups):
   • Fungsi: Menjamin resource CPU dan RAM selalu tersedia tanpa risiko node reclamation seperti pada Spot Instances. Untuk database worker atau web server dengan tingkat konkurensi tinggi, On-Demand memberikan kestabilan latensi jaringan.
3. syncPolicy.automated.prune: true & selfHeal: true (ArgoCD Application):
   • Fungsi:
     • prune: true memastikan bahwa jika sebuah resource dihapus dari repository Git (misalnya file deployment lama), ArgoCD akan otomatis menghapusnya dari klaster produksi.
     • selfHeal: true secara otomatis mengembalikan konfigurasi klaster jika ada administrator yang secara iseng mengubah pod atau service secara manual menggunakan perintah kubectl edit langsung di server.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: Menghadapi Flash Sale E-Commerce dengan 50.000 Concurrent Requests

Sebuah platform e-commerce berbasis Node.js dan PHP-FPM mengalami lonjakan traffic masif saat acara Flash Sale. Dalam skenario ini, konfigurasi infrastruktur harus dioptimalkan:

1. Horizontal Pod Autoscaler (HPA) di ArgoCD Helm Chart:

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: web-backend-hpa
     namespace: 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
   

2. Redis Cluster & Session Sharing: Backend web dikonfigurasi agar tidak menyimpan sesi pengguna di memori lokal pod, melainkan terhubung ke Redis Cluster terkelola untuk memastikan stateless architecture sehingga pod dapat melakukan scaling naik (scale-up) atau turun (scale-down) secara instan tanpa memutus sesi pengguna.
3. Ingress Controller Tuning: Nginx Ingress Controller di-tune agar mampu menangani keep-alive connections yang tinggi dan mencegah socket exhaustion:

   data:
     keep-alive: "120"
     worker-processes: "auto"
     max-worker-connections: "65536"
   

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menyimpan Kredensial Sensitif Plain Text di Git.
  • Masalah: Menyimpan password database MySQL atau API Key Cloudflare secara terbuka di repository manifest ArgoCD.
  • Solusi: Gunakan enkripsi tingkat lanjut seperti External Secrets Operator yang mengambil data rahasia dari AWS Secrets Manager atau HashiCorp Vault, atau gunakan SOPS (Secrets OPerationS) dengan GPG/KMS.
• Anti-Pattern 2: Menggunakan image:latest pada Deployment Produksi.
  • Masalah: Menyebabkan inkonsistensi versi kode antar pod jika terjadi rolling restart.
  • Solusi: Selalu gunakan tag versi semantik spesifik (v1.4.2) atau SHA digest image container di dalam manifest GitOps.
• Pitfall 3: Mengabaikan Resource Limits pada Pod.
  • Masalah: Satu pod mengalami memory leak dan menghabiskan seluruh RAM node Kubernetes, menyebabkan Node Eviction dan pod web aplikasi lain ikut mati.
  • Solusi: Selalu tetapkan batasan resources.requests dan resources.limits pada setiap deployment Helm Chart.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa klaster dan aplikasi web wajib dilakukan sebelum merilis sistem ke publik. Kita dapat menggunakan tool k6 untuk melakukan simulasi beban HTTP.

Buat file script load test load-test.js:

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

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Ramp-up ke 100 VU
    { duration: '5m', target: 500 }, // Tahan di 500 VU
    { duration: '2m', target: 0 },   // Ramp-down ke 0
  ],
};

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

Jalankan pengujian:

k6 run load-test.js

Analisis Hasil & Tuning Lanjutan:

• Jika persentase error meningkat saat 500 Virtual Users (VU), periksa metrik CPU menggunakan Prometheus/Grafana.
• Jika CPU node mencapai 85%, sesuaikan parameter Terraform untuk menambah ukuran instance node (misalnya dari t3.xlarge ke c6i.2xlarge yang dioptimalkan untuk komputasi berat).
• Pastikan Cloudflare Edge Caching diaktifkan untuk static asset (CSS, JS, Gambar) guna mengurangi beban langsung ke Nginx Ingress Kubernetes hingga 70%.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan arsitektur GitOps Terraform dan ArgoCD ke lingkungan production, pastikan Anda telah memverifikasi daftar periksa berikut:

• State Terraform disimpan di remote backend yang aman (AWS S3 + DynamoDB State Locking dengan enkripsi AES-256).
• Akses ArgoCD dilindungi dengan autentikasi SSO (OAuth2/SAML) dan Multi-Factor Authentication (MFA).
• Kebijakan RBAC (Role-Based Access Control) di Kubernetes dikonfigurasi secara ketat (Principle of Least Privilege).
• Monitoring dan Alerting (Prometheus, Grafana, Alertmanager) aktif memantau penggunaan CPU, RAM, dan HTTP 5xx error rate.
• Strategi Backup dan Disaster Recovery (Velero untuk backup klaster K8s dan snapshot RDS database) telah diuji secara berkala.

Dengan memadukan automasi provisioning infrastruktur melalui Terraform dan continuous delivery deklaratif menggunakan ArgoCD, organisasi Anda mencapai level kematangan operasional DevOps tertinggi: cepat, aman, transparan, dan sangat tahan banting terhadap kegagalan sistem.