GitOps #

GitOps adalah pendekatan deployment di mana seluruh desired state cluster didefinisikan di Git repository — manifest Kubernetes, Helm values, Kustomize overlays, semuanya. Tidak ada kubectl apply manual ke production. Tidak ada konfigurasi yang dibuat langsung di cluster tanpa melewati Git. Setiap perubahan harus melalui pull request, di-review, di-merge, dan baru kemudian operator GitOps yang mendeteksi perbedaan antara Git dan cluster lalu menerapkannya secara otomatis.

Mengapa GitOps? #

Masalah dengan pendekatan tradisional (push-based CI/CD):

  Developer push → CI build → CI/CD deploy langsung ke cluster
                               via kubectl apply

  Masalah:
  ✗ CI/CD pipeline punya akses penuh ke cluster production
  ✗ Tidak ada audit trail siapa yang deploy apa kapan
  ✗ Konfigurasi di cluster bisa berbeda dari yang ada di Git
    (seseorang hotfix langsung via kubectl tanpa commit)
  ✗ Disaster recovery: sulit reproduce state cluster dari awal
  ✗ Rollback: harus trigger pipeline ulang atau manual kubectl

GitOps memperbaiki semua ini:
  ✓ Git adalah source of truth — cluster harus selalu sama dengan Git
  ✓ Audit trail lengkap via Git history
  ✓ CI/CD tidak punya akses ke cluster (pull-based, bukan push-based)
  ✓ Drift detection: notifikasi jika cluster menyimpang dari Git
  ✓ Disaster recovery: apply semua manifest di Git → cluster kembali

Pull-Based vs Push-Based #

Perbedaan fundamental antara GitOps dan CI/CD tradisional:

Push-Based (tradisional):

  Git → CI build → CI/CD pipeline ──────► kubectl apply → Cluster
                        │
                        └── punya credentials cluster production
                            (risiko keamanan)

Pull-Based (GitOps):

  Git → CI build → push image → update manifest di Git
                                        │
                              GitOps operator (di dalam cluster)
                              watch Git repository setiap N detik
                              jika ada diff → apply perubahan
                                        │
                                      Cluster

  CI/CD tidak punya credentials cluster production!
  Operator di dalam cluster yang "pull" dari Git.

ArgoCD #

ArgoCD adalah GitOps operator paling populer untuk Kubernetes. Ia berjalan sebagai deployment di dalam cluster dan terus memantau repository Git yang ditentukan.

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

# Akses ArgoCD UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Buka: https://localhost:8080

# ArgoCD Application — definisikan apa yang di-sync
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-production
  namespace: argocd
spec:
  project: default

  # Sumber: Git repository
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    targetRevision: main          # branch/tag/commit
    path: overlays/production     # path di dalam repo (Kustomize)

  # Tujuan: cluster dan namespace
  destination:
    server: https://kubernetes.default.svc
    namespace: production

  # Policy sync
  syncPolicy:
    automated:
      prune: true       # hapus resource di cluster yang tidak ada di Git
      selfHeal: true    # pulihkan resource yang diubah langsung di cluster
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        maxDuration: 3m

ArgoCD status:

  Synced    — cluster sama dengan Git
  OutOfSync — ada perbedaan antara Git dan cluster
  Healthy   — semua resource berjalan dengan baik
  Degraded  — ada resource yang tidak healthy

Flux #

Flux adalah alternatif ArgoCD yang lebih modular dan GitOps-native. Lebih cocok untuk tim yang ingin integrasi langsung dengan toolkit seperti Helm dan Kustomize tanpa UI tambahan.

# Install Flux CLI
brew install fluxcd/tap/flux   # atau download dari GitHub

# Bootstrap Flux ke cluster (GitHub)
flux bootstrap github \
  --owner=myorg \
  --repository=k8s-manifests \
  --branch=main \
  --path=clusters/production \
  --personal

# Flux GitRepository — definisikan sumber Git
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: k8s-manifests
  namespace: flux-system
spec:
  interval: 1m            # check setiap 1 menit
  url: https://github.com/myorg/k8s-manifests
  ref:
    branch: main

---
# Flux Kustomization — definisikan apa yang di-apply
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: production-api
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: k8s-manifests
  path: ./overlays/production
  prune: true             # hapus resource tidak ada di Git
  targetNamespace: production
  healthChecks:
  - apiVersion: apps/v1
    kind: Deployment
    name: api
    namespace: production

Alur Kerja GitOps Lengkap #

1. Developer buat Pull Request dengan perubahan kode

2. CI pipeline:
   → Build dan test
   → Build Docker image
   → Push ke registry: my-api:a1b2c3d (commit hash sebagai tag)
   → Update manifest di repository Git:
     sed -i "s|my-api:.*|my-api:a1b2c3d|" overlays/production/kustomization.yaml
     git commit -m "chore: update api image to a1b2c3d"
     git push

3. Pull Request di-review dan di-merge ke main

4. ArgoCD/Flux deteksi perubahan di Git (dalam ~1 menit)

5. Diff dihitung: cluster punya image a1b2c3d-1, Git punya a1b2c3d
   → OutOfSync detected

6. Sync dijalankan: kubectl apply manifest dari Git
   → Rolling update dimulai

7. ArgoCD/Flux report: Synced + Healthy

Sync Otomatis vs Manual Approval #

Tidak semua sync harus otomatis. Pola yang umum:

# Development: sync otomatis tanpa approval
syncPolicy:
  automated:
    prune: true
    selfHeal: true

---
# Staging: sync otomatis tapi dengan notification
syncPolicy:
  automated:
    prune: true
  notifications:
    # Kirim notifikasi ke Slack setelah sync

# Production: manual approval sebelum sync
# Tidak ada automated syncPolicy
# Operator harus klik "Sync" di ArgoCD UI atau:
argocd app sync api-production

Pola yang direkomendasikan untuk production kritikal: automated sync untuk update image patch/minor, manual sync untuk perubahan besar atau konfigurasi infrastruktur.

Perbandingan ArgoCD vs Flux #

ArgoCD:
  ✓ UI yang kaya — visualisasi resource tree, diff viewer
  ✓ RBAC bawaan — kontrol siapa bisa sync apa
  ✓ Multi-cluster management dari satu UI
  ✓ Application Sets untuk deploy ke banyak cluster sekaligus
  ✗ Lebih berat resource-wise
  ✗ Satu database (Redis) sebagai single point of failure

Flux:
  ✓ Lebih ringan dan modular
  ✓ Native support untuk Helm dan Kustomize sebagai first-class citizen
  ✓ Tidak butuh UI (pure GitOps — semua via Git)
  ✓ Multi-tenancy via Flux Tenancy
  ✗ Kurva belajar lebih tinggi tanpa UI
  ✗ Debugging lebih sulit tanpa visualisasi

Pilih ArgoCD jika:
  → Tim butuh UI untuk visualisasi dan monitoring
  → Multi-cluster management
  → Banyak tim dengan kebutuhan RBAC berbeda

Pilih Flux jika:
  → Tim engineer yang nyaman dengan CLI dan YAML
  → Ekosistem yang sudah pakai Helm banyak
  → Ingin minimal footprint

Ringkasan #

  • Git adalah single source of truth — desired state cluster sepenuhnya ada di Git; tidak ada konfigurasi “live” yang tidak ada di repository.
  • Pull-based lebih aman dari push-based — CI/CD tidak perlu credentials cluster production; operator di dalam cluster yang pull dari Git dan apply.
  • ArgoCD untuk visualisasi, Flux untuk kesederhanaan — ArgoCD unggul dengan UI dan multi-cluster; Flux lebih ringan dan native GitOps tanpa UI.
  • selfHeal: true untuk mencegah configuration drift — ArgoCD otomatis mengembalikan resource yang diubah langsung di cluster ke kondisi yang ada di Git.
  • Alur CI/CD berubah — CI build image dan update manifest di Git; GitOps operator yang deploy ke cluster; pemisahan yang bersih antara CI dan CD.
  • Manual approval untuk production kritikal — tidak semua sync harus otomatis; untuk perubahan besar, workflow review dan approval sebelum sync lebih aman.

← Sebelumnya: Rollback Strategy   Berikutnya: Anti-Pattern Deployment →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact