L
Infrastructure as Code (IaC) • Literally Web ID

Implementasi GitOps dan Infrastructure as Code Skala Enterprise dengan Terraform dan ArgoCD

⏱️ 15 menit baca • 📅 14 Oct 2026 • 👁️ 1 views
Implementasi GitOps dan Infrastructure as Code Skala Enterprise dengan Terraform dan ArgoCD

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan web enterprise modern, kompleksitas manajemen infrastruktur telah melampaui kemampuan operasional tim manual (Ops). Skala aplikasi yang menuntut high availability 99.99%, multi-region deployment, serta integrasi ekosistem web yang masif (mulai dari front-end SPA/SSR di Cloudflare Edge, backend Go/Node.js, database cluster MySQL/MariaDB berkinerja tinggi, hingga sistem antrean pesan berbasis Redis) menciptakan titik-titik kerentanan operasional yang parah.

Masalah Utama: Infrastructure Drift & Human Error

Secara historis, perubahan infrastruktur dilakukan melalui skrip shell ad-hoc, konsol web cloud provider (AWS/GCP Console), atau eksekusi Terraform lokal oleh engineer yang berbeda-beda. Hal ini memicu fenomena Infrastructure Drift—kondisi di mana keadaan riil infrastruktur di cloud menyimpang jauh dari dokumentasi atau file konfigurasi aslinya. Ketika terjadi insiden kegagalan sistem (misalnya lonjakan traffic pada malam hari yang memerlukan scaling instan pada web server Nginx atau penambahan worker PHP-FPM), tim sering kali terjebak dalam troubleshooting manual yang memakan waktu.

Perbandingan: Sebelum vs Sesudah GitOps & IaC Enterprise

  • Sebelum (Manual / Imperative Ops):
    • Perubahan infrastruktur via Console GUI atau script lokal.
    • State Terraform disimpan secara lokal di mesin engineer, sering terjadi state lock conflict atau korupsi state.
    • Deployment aplikasi terpisah dari infrastruktur, memicu inkonsistensi environment (Staging vs Production).
    • Audit trail nihil; sulit melacak siapa yang mengubah konfigurasi security group atau rule WAF.
  • Sesudah (GitOps & Declarative IaC dengan Terraform & ArgoCD):
    • Semua infrastruktur dan aplikasi dideklarasikan sebagai kode (Infrastructure as Code & GitOps).
    • Git menjadi satu-satunya Single Source of Truth (SSoT).
    • Terraform mengelola resource lower-level (VPC, EKS, RDS, S3/MinIO), sementara ArgoCD melakukan sinkronisasi continuous reconciliation untuk upper-level (Kubernetes Deployment, Service, Ingress Controller, ConfigMap).
    • Drift dideteksi secara otomatis dan dapat diperbaiki secara otomatis (self-healing) atau melalui approval pull request.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur GitOps modern menggabungkan dua pilar utama: Infrastructure as Code (Terraform) untuk provisioning fondasi cloud, dan GitOps Continuous Delivery (ArgoCD) untuk orkestrasi aplikasi di atas Kubernetes.

Alur Eksekusi & Data Flow Under the Hood

+------------------+         Git Push         +------------------------+
| Developer/Ops    | ------------------------>| Git Repository (SSoT)  |
+------------------+                          +------------------------+
                                                          |
         +------------------------------------------------+
         |
         v
+------------------------+                    +------------------------+
| Terraform Cloud/CI     |                    | ArgoCD Controller      |
| (AWS S3 Remote State)  |                    | (In-Cluster Watcher)   |
+------------------------+                    +------------------------+
         |                                                |
         v Provision                                      v Synchronize
+------------------------+                    +------------------------+
| Cloud Infrastructure   |                    | Kubernetes Cluster     |
| (VPC, EKS, RDS, S3)    |                    | (Pods, Services, Ingress)|
+------------------------+                    +------------------------+
  1. Deklarasi SSoT: Seluruh definisi infrastruktur (HCF/Terraform) dan manifest aplikasi Kubernetes (YAML/Helm/Kustomize) disimpan dalam satu atau beberapa repositori Git terpusat.
  2. Provisioning Layer (Terraform): Pipeline CI/CD mendeteksi perubahan pada file Terraform, melakukan terraform plan, dan mengeksekusi terraform apply untuk membangun atau memperbarui resource cloud (seperti AWS VPC, EKS Cluster, dan bucket S3 untuk penyimpanan aset web).
  3. Synchronization Layer (ArgoCD): ArgoCD yang berjalan di dalam kluster Kubernetes terus menerus memantau repositori Git target. Ketika ada perbedaan antara state di Git dan state aktual di kluster Kubernetes (misalnya jumlah replika pod web Nginx berubah secara manual), ArgoCD langsung memicu proses sinkronisasi (reconciliation loop).

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk menentukan strategi yang paling efisien dalam arsitektur enterprise, berikut adalah perbandingan mendalam antara tiga pendekatan orkestrasi deployment:

Parameter Komparasi Imperative Deployment (Bash/Ansible Push) Terraform Pure (CI/CD Pipeline) GitOps Enterprise (Terraform + ArgoCD)
Model Operasional Imperative (Procedural steps) Declarative (Infrastructure) Declarative (App + Infra)
Source of Truth Script files / Jenkins jobs Git repository (for code) Git repository (Strict SSoT)
Drift Detection Tidak ada / Manual check terraform plan on schedule Real-time continuous monitoring
Rollback Mechanism Manual revert script Re-apply previous commit Git revert + Auto-sync
Security Footprint Tinggi (Kredensial di CI/CD) Sedang (Kredensial di CI/CD) Rendah (Agen in-cluster tanpa inbound port)
Resource Overhead Minimal Minimal Sedang (Membutuhkan controller pods di K8s)

[!IMPORTANT] Pendekatan GitOps murni dengan ArgoCD menghilangkan kebutuhan membuka akses inbound firewall ke kluster Kubernetes Anda, karena ArgoCD bertindak sebagai agen pull-based yang secara aktif menarik konfigurasi dari Git keluar melalui koneksi HTTPS/SSH outbound.


4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum masuk ke implementasi teknis, pastikan environment Anda memenuhi spesifikasi enterprise berikut:

  • Operating System: Ubuntu 22.04 LTS / RHEL 9 (untuk mesin runner CI/CD dan lokal workstation).
  • Tools & CLI:
    • Terraform v1.5+ (terraform version)
    • Kubernetes CLI (kubectl v1.28+)
    • ArgoCD CLI (argocd v2.9+)
    • AWS CLI v2 / MinIO Client (mc)
  • Infrastructure Access:
    • Akses ke AWS Cloud (atau MinIO Instance untuk S3-compatible backend).
    • Kubernetes Cluster (EKS, GKE, atau Bare-Metal K8s via Rancher/K3s).
    • Repository Git privat (GitHub Enterprise / GitLab / Bitbucket).

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Manajemen State Terraform di AWS S3 & DynamoDB

Buat struktur direktori untuk modul backend Terraform guna memastikan kolaborasi tim aman dari state corruption.

Simpan file berikut sebagai backend.tf:

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

  backend "s3" {
    bucket         = "enterprise-terraform-state-bucket-prod"
    key            = "core-infra/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

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

Langkah 2: Provisioning S3 Storage & Database Redis/MySQL untuk Web Stack

Simpan file konfigurasi infrastruktur utama sebagai main.tf:

resource "aws_s3_bucket" "web_assets" {
  bucket        = "enterprise-web-static-assets-storage"
  force_destroy = false
}

resource "aws_s3_bucket_server_side_encryption_configuration" "web_assets_enc" {
  bucket = aws_s3_bucket.web_assets.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_db_subnet_group" "db_subnet" {
  name       = "enterprise-db-subnet-group"
  subnet_ids = ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"]
}

resource "aws_db_instance" "mysql_master" {
  identifier             = "enterprise-mysql-master"
  engine                 = "mysql"
  engine_version         = "8.0.35"
  instance_class         = "db.m6i.xlarge"
  allocated_storage      = 100
  max_allocated_storage  = 1000
  storage_type           = "gp3"
  db_name                = "appdb"
  username               = "dbadmin"
  password               = "SuperSecurePassword123!_ChangeMe"
  db_subnet_group_name   = aws_db_subnet_group.db_subnet.name
  skip_final_snapshot    = false
  final_snapshot_identifier = "enterprise-mysql-final-snapshot"
  publicly_accessible    = false
}

Langkah 3: Setup ArgoCD di Kubernetes Cluster

Lakukan instalasi ArgoCD ke dalam kluster Kubernetes menggunakan namespace khusus.

# Membuat namespace untuk ArgoCD
kubectl create namespace argocd

# Menginstal manifest resmi ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Memverifikasi pod ArgoCD berjalan dengan normal
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server

Ubah service ArgoCD menjadi LoadBalancer atau gunakan Ingress Controller (Nginx/Traefik) dengan TLS Let's Encrypt untuk akses dashboard enterprise.

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer\
🏷️ Tags: #Nginx #High Concurrency #Performance #Sysadmin #Web Server