Belajar GitOps dengan ArgoCD - Ecosystem Integration

#Pendahuluan

Di episode 29 sebelumnya infrastruktur pun sudah masuk ke dalam Git. Namun GitOps tidak hidup di ruang hampa — di hampir semua organisasi, ArgoCD berdampingan dengan tool CI yang sudah ada: Jenkins yang berusia sepuluh tahun, GitHub Actions yang baru dipasang, Tekton di dalam cluster, atau GitLab yang memayungi semuanya. Pertanyaan klasiknya: bagaimana tool build dan tool deploy berkomunikasi tanpa mengaburkan tanggung jawab?

Episode ini menjawabnya dengan satu prinsip yang sudah kita pegang sejak episode 18: CI membangun dan menguji; CD (GitOps) menerapkan dari Git. Semua integrasi di episode ini hanyalah varian dari prinsip itu — CI menulis hasilnya ke Git, ArgoCD membaca Git. Mari lihat bagaimana setiap tool populer melakukan hal ini.

#Tekton

Tekton adalah CI/CD native Kubernetes berbasis CRD: Pipeline, Task, dan PipelineRun. Integrasi paling bersih adalah: Tekton membangun image, memperbarui manifest di repo Git, lalu ArgoCD mendeteksi dan sync.

#Pipeline dan Pemicu

Pipeline Tekton bertanggung jawab atas sisi build:

Pipeline Tekton - build lalu update manifest

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-update
spec:
  tasks:
    - name: build
      taskRef:
        name: buildah
    - name: update-manifest
      runAfter: [build]
      taskRef:
        name: git-update-manifest

#Triggering Sync

Ada dua pola memicu ArgoCD dari Tekton:

• Passif — Tekton melakukan commit ke repo manifest, ArgoCD yang terdaftar di repo itu (dengan webhook atau polling) sync sendiri. Ini paling GitOps-murni: Tekton tidak pernah menyentuh ArgoCD.
• Aktif — setelah commit, Tekton memanggil argocd app sync lewat task kustom. Lebih cepat, tetapi memberi CI kekuatan deploy — gunakan hanya jika kalian ingin kontrol eksekusi di CI.

#Pipeline Results ke Git

Cara Tekton mengkomunikasikan hasil build ke Git adalah lewat results. Build menyimpan digest image ke results, task berikutnya membaca dan mengupdate deployment.yaml di repo manifest. Digest (bukan tag) menjaga reprodusibilitas — ini yang sudah kita pelajari di episode 16 bersama Image Updater.

#Jenkins

#Jenkins X: GitOps Born

Jenkins X dirancang dengan GitOps sebagai intinya: setiap environment memiliki repo manifest sendiri, dan promotion adalah PR ke repo environment. Integrasinya dengan ArgoCD sederhana: ArgoCD membaca repo environment dan melakukan sync. Jika kalian sudah memakai Jenkins X, integrasi ArgoCD hampir tanpa usaha — tinggal daftarkan repo environment sebagai Application.

#Traditional Jenkins + ArgoCD

Untuk Jenkins klasik, pola yang direkomendasikan: Jenkins hanya untuk build, dan tidak men-deploy langsung. Alih-alih, Jenkins melakukan:

1. Build image + push registry.
2. Update manifest di repo Git (memakai kredensial deploy-bot, atau mendorong Image Updater untuk mendeteksinya — episode 16).
3. Commit dan push.

Pipeline Jenkins - hanya update Git

stage('update manifests') {
  sh 'kustomize edit set image api=registry.example.com/api:${BUILD_TAG}'
  sh 'git add . && git commit -m "release api: ${BUILD_TAG}"'
  sh 'git push origin main'
}

#Webhook Triggers

Agar sync tidak menunggu polling, konfigurasikan webhook dari repo Git ke ArgoCD. Untuk GitHub/GitLab ini tinggal di UI ArgoCD (Settings → Repositories → webhook); ArgoCD menyediakan endpoint yang menerima event dan langsung menjadwalkan refresh + sync. Dengan webhook, perubahan manifest sampai ke cluster dalam hitungan detik.

#GitHub Actions

GitHub Actions adalah pilihan paling populer untuk repo yang tinggal di GitHub. Pola standarnya:

Workflow manifest update menggunakan token deploy-bot dengan izin menulis ke repo manifest:

- name: Update manifests
  run: |
    cd deploy
    kustomize edit set image api=${{ inputs.image }}
    git add .
    git commit -m "chore: bump api to ${{ inputs.tag }}"
    git push
  env:
    GITHUB_TOKEN: ${{ secrets.MANIFEST_REPO_TOKEN }}

#PR Automation dan Status Checks

Dua pola yang membuat GitHub Actions unggul: PR automation (bot membuka PR yang memperbarui manifest, direview dulu sebelum merge — kontrol penuh untuk production) dan status checks (action menunggu ArgoCD menandai aplikasi Healthy sebelum laporan pipeline sukses). ArgoCD juga punya integration dengan GitHub Checks lewat argocd-notifications (episode 17), sehingga status deployment tampil langsung di halaman PR.

#GitLab CI/CD

GitLab menawarkan pendekatan yang lebih terpadu.

#Auto DevOps

Auto DevOps men-deploy dengan push model bawaan — tetapi untuk memakai ArgoCD, kalian menonaktifkan deployment bawaan GitLab dan menggantinya dengan langkah yang memperbarui repo manifest (persis pola Jenkins). GitLab environment di sisi GitLab tetap dipakai untuk melacak deployment, sementara eksekusi nyata ada di ArgoCD.

#GitLab + ArgoCD

GitLab menyediakan repository mirroring dan deploy tokens yang nyaman untuk ArgoCD. Yang perlu kalian lakukan: buat project manifest terpisah, atur CI .gitlab-ci.yml untuk update manifest setelah build, daftarkan repo ke ArgoCD, dan pasang webhook (GitLab → ArgoCD). Environment management di GitLab (environment: keyword) memberi tampilan deployment tanpa mengganggu model GitOps.

#Tool Lain dalam Ekosistem

#Migrasi dari FluxCD

Jika kalian datang dari Flux: ArgoCD dan Flux sama-sama pull-based. Perbedaan konseptual utama: Flux menggunakan Kustomization objects dan memakai eventual consistency versi Git; ArgoCD memakai Application dengan status yang lebih eksplisit (Sync + Health). Migrasi bertahap: daftarkan repo yang sama di ArgoCD, buat Application untuk Kustomization yang sama, freeze Flux, lalu hapus Flux. Git yang sama = tidak ada perubahan manifes sama sekali.

#Integrasi Terraform

Seperti dibahas di episode 29: Terraform untuk resource non-Kubernetes dengan pipeline, Crossplane untuk resource yang butuh reconciliation terus. Integrasi ArgoCD-Terraform yang sering dipakai: ArgoCD mengelola sebuah Operator/controller yang menjalankan Terraform (misalnya via pipeline hook di episode 13) untuk kasus di mana state harus dipertahankan.

#Policy Engines (OPA, Kyverno)

Policy engine adalah gerbang keamanan di antara Git dan cluster (episode 28). Kyverno memvalidasi manifest saat ArgoCD menerapkannya di cluster. OPA/Gatekeeper bekerja serupa lewat ConstraintTemplate. Keduanya memastikan: tidak ada image latest, tidak ada container yang berjalan sebagai root, semua resource punya limits. Karena ArgoCD terus mencoba sync, manifest yang melanggar policy akan terus ditolak — dan akan terlihat sebagai error yang jelas di UI.

#Backstage Service Catalog

Backstage (Spotify) menjadi katalog layanan dan Internal Developer Portal — jembatan antara "apa yang dimiliki tim" dan "bagaimana deploy-nya". Integrasinya dengan ArgoCD lewat plugin @backstage/plugin-argocd: developers melihat status aplikasi ArgoCD langsung dari halaman katalog Backstage. Ini langkah pertama menuju Internal Developer Platform yang akan kita bahas di episode 35.

#Penutup

Episode ini menghubungkan ArgoCD dengan ekosistemnya: Tekton dengan pipeline dan pemicu Git-native, Jenkins dan Jenkins X dengan pola "CI tidak pernah deploy langsung", GitHub Actions dengan workflow manifest update dan status checks, GitLab dengan Auto DevOps dan environment management, serta tool pendukung lain: migrasi FluxCD, integrasi Terraform, policy engine, dan katalog Backstage.

Poin yang harus kalian bawa:

• Semua integrasi mengikuti satu prinsip: CI menulis ke Git, ArgoCD membaca Git.
• Webhook mempercepat deteksi; polling tetap menjadi jaring pengaman.
• Jenkins/CI tidak pernah men-deploy langsung ke cluster.
• ArgoCD bisa mengelola resource yang dibuat oleh Tekton, Crossplane, atau CAPI.
• Backstage menghubungkan katalog layanan dengan status deployment.

Ekosistem sudah tersambung; sekarang kalian perlu menyesuaikan pola dengan cloud tempat kalian berjalan. Di episode 31 selanjutnya kita membahas cloud provider specific patterns — AWS EKS, GCP GKE, Azure AKS, dan pola multi-cloud dengan abstraksi cloud-agnostic. Sampai jumpa di episode 31!