Membangun GitOps Pipeline Otomatis dengan ArgoCD dan Kubernetes di Infrastruktur On-Premise

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan perangkat lunak modern, adopsi Continuous Integration and Continuous Deployment (CI/CD) tradisional sering kali menghadapi titik jenuh operasional ketika infrastruktur berkembang dari skala puluhan microservices menjadi ratusan cluster Kubernetes on-premise. Pendekatan push-based CI/CD konvensional—di mana server CI seperti Jenkins, GitLab CI, atau Tekton memiliki akses langsung (kubeconfig) ke klaster Kubernetes produksi untuk menerapkan perubahan manifes—menyimpan cacat arsitektur yang krusial dari sudut pandang keamanan dan keandalan sistem.

Secara historis, model push menciptakan attack vector yang berbahaya. Jika build server atau token akses CI/CD Anda disusupi oleh penyerang, seluruh infrastruktur Kubernetes di belakangnya langsung jatuh ke tangan musuh karena server eksternal memegang kredensial administratif penuh (cluster-admin). Selain itu, kondisi aktual klaster (actual state) sering kali melenceng dari kondisi yang diinginkan dalam kode (desired state) akibat praktik hotfixing manual melalui perintah kubectl edit atau kubectl patch darurat oleh insinyur di tengah malam. Hal ini memicu fenomena Configuration Drift yang membuat debugging menjadi mimpi buruk.

Sebaliknya, GitOps membalik paradigma ini menjadi pull-based. Klaster Kubernetes menarik sendiri perubahan dari repositori Git yang bertindak sebagai satu-satunya sumber kebenaran tunggal (Single Source of Truth). ArgoCD, sebagai implementasi declarative continuous delivery terkemuka, berjalan di dalam klaster itu sendiri. Ia secara konstan membandingkan desired state di Git dengan live state di klaster, lalu melakukan sinkronisasi secara otomatis maupun terkontrol.

Sebelum vs Sesudah Penerapan GitOps dengan ArgoCD

[!IMPORTANT] Pada infrastruktur on-premise, isolasi jaringan adalah prioritas utama. Menggunakan ArgoCD memastikan bahwa Anda tidak perlu membuka port eksternal atau memberikan akses firewall masuk ke klaster Kubernetes dari server CI/CD eksternal.

2. Konsep Inti & Deep Dive Arsitektur

ArgoCD dibangun di atas arsitektur berbasis controller Kubernetes yang mengimplementasikan Custom Resource Definitions (CRD) seperti Application, AppProject, dan Cluster. Di balik layar, ArgoCD terdiri dari beberapa komponen utama yang bekerja secara sinkron untuk memastikan konsistensi sistem:

1. API Server: Antarmuka berbasis gRPC/REST yang melayani permintaan dari ArgoCD CLI, UI, dan webhook integrasi Git.
2. Repository Server: Layanan mikro yang bertanggung jawab untuk mengkloning repositori Git, merender templat manifes (Helm, Kustomize, Ksonnet), dan menghasilkan manifes Kubernetes murni.
3. Application Controller: Inti dari logika rekonsiliasi (reconciliation loop). Komponen ini secara periodik memindai live state klaster, membandingkannya dengan manifes yang dihasilkan oleh Repository Server, dan mendeteksi apakah terjadi perbedaan (OutOfSync).

Alur Eksekusi Data (Data Flow Architecture)

+-------------------+         1. Git Push          +------------------------+
| Developer/Engineer| ---------------------------> | Git Repository (GitHub)|
+-------------------+                              +------------------------+
                                                                |
                                                   2. Webhook / Polling
                                                                v
+---------------------------------------------------------------+---------------------------------------------------------------+
| Kubernetes Cluster (On-Premise)                                                                                               |
|                                                                                                                               |
|  +--------------------------+    3. Fetch & Render Manifests    +----------------------------------+                          |
|  | ArgoCD Repository Server | <-------------------------------- | ArgoCD Application Controller    |                          |
|  +--------------------------+                                   +----------------------------------+                          |
|               |                                                                   |                                           |
|               +----------------------- 4. Compare State <-------------------------+                                           |
|                                              |                                                                                |
|                                       5. Apply Manifests (Sync)                                                               |
|                                              v                                                                                |
|                               +------------------------------+                                                                |
|                               | Kubernetes API Server        |                                                                |
|                               +------------------------------+                                                                |
|                                              |                                                                                |
|                                       6. Actual State Deployed                                                                |
|                                              v                                                                                |
|                               [ Pods, Services, Ingress, DB ]                                                                 |
+-------------------------------------------------------------------------------------------------------------------------------+

Ketika sebuah commit baru didorong ke repositori Git, Git server mengirimkan webhook ke ArgoCD API Server. Controller segera memerintahkan Repository Server untuk mengambil kode terbaru. Repository Server memproses Kustomize atau Helm chart, lalu mengirimkan manifes yang telah dirender kembali ke Controller. Controller mengevaluasi apakah status saat ini di klaster sama dengan manifes baru. Jika tidak sinkron (OutOfSync), dan mode sinkronisasi diatur ke otomatis, Controller akan menerapkan perubahan tersebut melalui Kubernetes API Server.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun arsitektur GitOps di lingkungan on-premise, pemilihan alat manajemen konfigurasi manifes sangat menentukan kompleksitas pemeliharaan dan konsumsi sumber daya (resource footprint).

Perbandingan Engine Manifes: Kustomize vs Helm vs Plain YAML

[!TIP] Untuk infrastruktur on-premise yang menuntut transparansi audit keamanan yang ketat dan pencegahan kerentanan dari template pihak ketiga yang tidak dikenal, Kustomize adalah pilihan superior dibandingkan Helm karena tidak memperkenalkan lapisan templating bahasa pemrograman tambahan.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menginstal ArgoCD pada klaster Kubernetes on-premise Anda, pastikan spesifikasi perangkat keras dan perangkat lunak memenuhi standar produksi berikut:

Spesifikasi Minimum Klaster (Per Node Master & Worker)

• OS: Ubuntu Server 22.04 LTS / RHEL 9 (Kernel Linux >= 5.15)
• CPU: Minimal 4 vCPU
• RAM: Minimal 8 GB
• Penyimpanan: NVMe SSD dengan dukungan CSI (Container Storage Interface) seperti Rook-Ceph atau Local Path Provisioner
• Kubernetes Version: v1.26 - v1.30
• Container Runtime: containerd >= 1.6

Verifikasi Akses dan Dependensi CLI

Pastikan Anda memiliki hak akses klaster administratif dan tool berikut terinstal di mesin manajemen Anda:

# Verifikasi versi kubectl
kubectl version --client

# Verifikasi koneksi ke klaster on-premise
kubectl cluster-info

# Pastikan kustomize tersedia
kustomize version

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi ArgoCD pada Klaster On-Premise

Buat namespace khusus untuk ArgoCD dan terapkan manifes instalasi resmi berstandar produksi.

# Buat namespace argocd
kubectl create namespace argocd

# Terapkan manifes instalasi stabil ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Verifikasi bahwa seluruh pod ArgoCD berjalan dengan normal:

kubectl get pods -n argocd

Langkah 2: Eksposur ArgoCD UI untuk Lingkungan On-Premise

Karena lingkungan on-premise umumnya tidak memiliki Load Balancer awan otomatis seperti AWS ELB, kita akan menggunakan NodePort atau Ingress Controller (Nginx Ingress) dengan sertifikat SSL lokal.

Ubah tipe layanan argocd-server menjadi NodePort atau konfigurasikan Ingress berikut (argocd-ingress.yaml):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: argocd.internal.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 443

Terapkan Ingress:

kubectl apply -f argocd-ingress.yaml

Dapatkan kata sandi awal untuk akun admin:

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

Langkah 3: Setup Manifest Kubernetes Berbasis Kustomize

Kita akan membangun struktur direktori repositori Git yang memisahkan basis aplikasi web (misalnya stack Nginx + PHP-FPM / Node.js) dan overlay lingkungan (staging dan production).

Struktur direktori repositori Git Anda (gitops-infra):

├── apps/
│   └── base/
│       ├── deployment.yaml
│       ├── service.yaml
│       ├── ingress.yaml
│       └── kustomization.yaml
└── environments/
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        ├── patch-replicas.yaml
        └── kustomization.yaml

Berikut adalah isi file apps/base/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: registry.internal.company.com/engineering/webapp:v1.0.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "100m"
            memory: "128Mi"
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true

Isi file apps/base/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: web-app-svc
spec:
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP

Isi file apps/base/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
- ingress.yaml

Isi file environments/production/patch-replicas.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 5

Isi file environments/production/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
resources:
- ../../apps/base
patches:
- path: patch-replicas.yaml

Langkah 4: Mendaftarkan Aplikasi ke ArgoCD

Buat file deklaratif aplikasi ArgoCD (argocd-app-production.yaml):

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

Terapkan aplikasi ke klaster:

kubectl apply -f argocd-app-production.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah konfigurasi sinkronisasi otomatis pada manifes Application ArgoCD di atas:

• syncPolicy.automated.prune: true: Parameter ini memerintahkan ArgoCD untuk secara otomatis menghapus sumber daya Kubernetes di klaster jika objek tersebut dihapus dari manifes Git. Tanpa opsi ini, penghapusan file di Git tidak akan menghapus resource aktif di klaster (orphaned resources).
• syncPolicy.automated.selfHeal: true: Fitur inti keamanan GitOps. Jika seseorang secara manual mengubah konfigurasi (drift) di klaster menggunakan perintah kubectl scale deployment web-app --replicas=10, ArgoCD akan langsung mendeteksi perbedaan tersebut, membatalkannya, dan mengembalikannya ke nilai 5 sesuai definisi Git.
• syncOptions: [CreateNamespace=true]: Memastikan bahwa jika namespace production belum ada di klaster on-premise, ArgoCD akan membuatnya secara otomatis sebelum menerapkan manifes aplikasi.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada lingkungan on-premise dengan trafik tinggi (misalnya e-commerce flash sale yang melayani 50.000 requests per second), kestabilan dan kecepatan rekonsiliasi ArgoCD sangat diuji. Dalam kasus nyata di mana backend web menggunakan Go dan database MySQL/Redis di belakang Nginx Load Balancer:

1. Manajemen Trafik Tinggi: Modifikasi parameter Horizontal Pod Autoscaler (HPA) yang dideklarasikan melalui Kustomize memungkinkan klaster menambah replica pods secara instan ketika metrik CPU mencapai 75%.
2. Zero-Downtime Deployment: Strategi RollingUpdate pada Deployment Kubernetes dikonfigurasi dengan maxSurge: 25% dan maxUnavailable: 0%. Hal ini memastikan saat ArgoCD melakukan sinkronisasi versi image Docker baru, pod lama tidak dimatikan sebelum pod baru benar-benar siap dan lulus uji readiness probe.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern Fatal: Menyimpan Plaintext Secrets (seperti database password, kunci API JWT, atau kredensial SMTP) secara langsung di dalam repositori Git publik maupun privat.

Solusi Secret Management di GitOps On-Premise

Karena Git adalah sumber kebenaran yang dapat dibaca oleh siapa saja yang memiliki akses repositori, penyimpanan secrets mentah adalah pelanggaran keamanan fatal. Gunakan salah satu pendekatan berikut:

1. Bitnami Sealed Secrets: Mengenkripsi secret di mesin lokal menggunakan kunci publik klaster (kubeseal), menghasilkan file SealedSecret yang aman disimpan di Git. Controller di klaster akan mendekripsinya secara lokal.
2. External Secrets Operator (ESO): Mengambil data sensitif secara langsung dari penyimpanan eksternal aman seperti HashiCorp Vault atau AWS Secrets Manager saat sinkronisasi.

Contoh implementasi SealedSecret:

# Membuat secret lokal
kubectl create secret generic db-credentials --from-literal=password='SuperSecretPass123' --dry-run=client -o yaml > secret.yaml

# Mengenkripsi menjadi SealedSecret
kubeseal --format=yaml < secret.yaml > sealed-secret.yaml

File sealed-secret.yaml kini aman untuk didorong ke repositori Git.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk mengukur efektivitas dan kesehatan performa ArgoCD di lingkungan on-premise, Anda wajib memantau metrik internal melalui Prometheus dan Grafana. Metrik kunci yang harus diawasi meliputi:

• argocd_app_sync_status: Mengetahui status sinkronisasi aplikasi (Synced vs OutOfSync).
• argocd_redis_request_duration_seconds: Mengukur latensi komunikasi internal cache Redis ArgoCD.
• argocd_git_request_duration_seconds: Durasi waktu yang dibutuhkan ArgoCD untuk mengambil data dari repositori Git.

Tuning Performa ArgoCD Controller

Jika klaster Anda mengelola ratusan aplikasi dan mengalami kelambatan rekonsiliasi (sync lag), sesuaikan parameter environment variables pada deployment argocd-application-controller:

env:
- name: ARGOCD_CONTROLLER_RECONCILE_TIMEOUT
  value: "180s"
- name: ARGOCD_OPR_THREAD_COUNT
  value: "10"

Menaikkan jumlah thread worker (ARGOCD_OPR_THREAD_COUNT) memungkinkan controller memproses beberapa aplikasi secara paralel, memaksimalkan pemanfaatan inti CPU pada server master on-premise Anda.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan pipeline GitOps ArgoCD ke lingkungan produksi on-premise, pastikan Anda telah melewati daftar pemeriksaan (checklist) berikut:

• Autentikasi dan Otorisasi (RBAC) ArgoCD terintegrasi dengan LDAP/OIDC perusahaan.
• Semua kredensial sensitif telah dienkripsi menggunakan Sealed Secrets atau Vault.
• Fitur Self-Healing dan Prune aktif pada manifes produksi untuk mencegah configuration drift.
• Kebijakan NetworkPolicies diterapkan untuk mengisolasi namespace ArgoCD dari namespace aplikasi bisnis.
• Monitoring Prometheus dan alerting webhook (PagerDuty/Slack) aktif untuk memantau kegagalan sinkronisasi.

Dengan menerapkan arsitektur GitOps menggunakan ArgoCD pada infrastruktur Kubernetes on-premise, organisasi Anda mencapai tingkat transparansi operasional yang maksimal, keamanan akses yang ketat, serta pemulihan bencana (disaster recovery) yang dapat diandalkan hanya dengan satu perintah pemulihan commit Git.