GitOps dengan ArgoCD

📋 Daftar Isi

Pengenalan GitOps
4 Prinsip GitOps
Arsitektur GitOps
ArgoCD: Instalasi & Setup
Membuat & Mengelola Aplikasi
Sync, Rollback & Health
Multi-Cluster Deployment
GitOps Best Practices
Quiz Pemahaman

1. Pengenalan GitOps

GitOps adalah paradigma operasional yang menggunakan Git sebagai single source of truth untuk mendefinisikan dan mengelola infrastruktur dan aplikasi. Konsep ini dipopulerkan oleh Weaveworks pada tahun 2017 dan kini menjadi standar industri untuk continuous delivery di Kubernetes.

Inti dari GitOps sederhana: semua perubahan pada infrastruktur dan aplikasi harus dinyatakan secara declarative dalam repository Git. Perubahan ini kemudian secara otomatis diterapkan ke cluster, dan agent di dalam cluster memastikan bahwa state aktual sesuai dengan state yang didefinisikan di Git.

GitOps vs Traditional CI/CD

Aspek	Traditional CI/CD	GitOps
Deployment Trigger	Push dari pipeline ke cluster	Pull dari agent di cluster ke Git
Source of Truth	Pipeline script + database config	Git repository
Rollback	Run pipeline lama atau manual	`git revert` → otomatis di-apply
Audit Trail	CI/CD logs terpisah	Git history (siapa, kapan, apa yang berubah)
Disaster Recovery	Restore dari backup	Re-apply dari Git repository
Cluster Access	Pipeline butuh credentials cluster	Hanya agent di cluster yang butuh credentials
Drift Detection	Manual atau tidak ada	Otomatis oleh GitOps agent

Manfaat GitOps

Manfaat	Penjelasan
Increased Productivity	Deploy lebih cepat dan lebih sering dengan confidence
Enhanced Developer Experience	Developer cukup push ke Git, tidak perlu akses cluster
Improved Stability	Drift detection dan auto-recovery mengurangi human error
Higher Reliability	Consistency antara Git dan cluster, audit trail lengkap
Consistency & Standardization	Satu cara untuk manage semua environment
Stronger Security	Cluster tidak perlu diakses langsung dari CI/CD

2. 4 Prinsip GitOps

GitOps didasarkan pada empat prinsip fundamental yang menjadi fondasi untuk semua implementasi. Prinsip-prinsip ini berasal dari metodologi DevOps dan SRE yang sudah terbukti.

Prinsip 1: Declarative Configuration

Seluruh sistem yang di-deploy harus didefinisikan secara declarative, bukan imperatif. Ini berarti Anda mendeskripsikan apa yang diinginkan (desired state), bukan bagaimana cara mencapainya.

YAML — Declarative vs Imperative

# ❌ IMPERATIVE (cara lama — "how to do it")
# kubectl create deployment nginx --image=nginx:1.25 --replicas=3
# kubectl expose deployment nginx --port=80 --type=ClusterIP
# kubectl scale deployment nginx --replicas=5

# ✅ DECLARATIVE (GitOps — "what to have")
# deploy-nginx.yaml — committed di Git
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: production
  labels:
    app: nginx
    version: "1.25"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: production
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Prinsip 2: Versioned & Immutable

Seluruh desired state harus disimpan di Git yang mendukung versioning, immutability, dan history. Setiap perubahan tercatat dengan siapa, kapan, dan mengapa (commit message).

Prinsip 3: Pulled & Auto-Approved

Software agent di dalam cluster menarik (pull) desired state dari Git, bukan push dari CI/CD. Agent ini otomatis mendeteksi perubahan dan menerapkannya tanpa perlu approval manual (untuk environment tertentu).

Prinsip 4: Continuously Reconciled

Agent secara continuous membandingkan desired state (Git) dengan actual state (cluster). Jika ada drift (perbedaan), agent otomatis mengembalikan cluster ke desired state.

Diagram: 4 Prinsip GitOps dalam Aksi

┌──────────────────────────────────────────────────────────────────┐
│                    GITOPS WORKFLOW                                │
│                                                                  │
│  1. Developer push kode ke app repo                             │
│       │                                                          │
│       ▼                                                          │
│  2. CI Pipeline: build & test → push image ke registry          │
│       │                                                          │
│       ▼                                                          │
│  3. Update image tag di config repo (declarative)               │
│       │                                                          │
│       ▼                                                          │
│  ┌──────────────────────────────────────────────┐               │
│  │              GIT REPOSITORY                   │  ← Source     │
│  │  (Versioned, Immutable, Auditable)            │    of Truth   │
│  └───────────────────┬──────────────────────────┘               │
│                      │ Pull (continuous reconcile)              │
│                      ▼                                           │
│  ┌──────────────────────────────────────────────┐               │
│  │         GITOPS AGENT (ArgoCD)                 │               │
│  │  • Monitor Git repo for changes               │               │
│  │  • Compare desired vs actual state            │               │
│  │  • Auto-apply changes to cluster              │               │
│  │  • Drift detection & auto-heal               │               │
│  └───────────────────┬──────────────────────────┘               │
│                      │ Apply                                     │
│                      ▼                                           │
│  ┌──────────────────────────────────────────────┐               │
│  │          KUBERNETES CLUSTER                   │               │
│  │  (Always matches Git desired state)           │               │
│  └──────────────────────────────────────────────┘               │
│                                                                  │
│  Ops: git revert → cluster otomatis rollback!                   │
│  Audit: git log → complete history of all changes               │
│  Recovery: git clone → rebuild entire infra                      │
└──────────────────────────────────────────────────────────────────┘

3. Arsitektur GitOps

Arsitektur GitOps modern melibatkan beberapa komponen yang bekerja sama untuk menciptakan pipeline deployment yang otomatis, aman, dan terauditasi. Berikut gambaran arsitektur standar yang digunakan di banyak perusahaan.

Repo Structure: Monorepo vs Polyrepo

Aspek	App Repo + Config Repo (Polyrepo)	Monorepo (Satu Repo)
Struktur	Source code di app repo, manifest di config repo	Source code dan manifest dalam satu repo
Keamanan	Tim infra manage config repo, developer manage app repo	Akses tercampur, perlu CODEOWNERS
Review	PR terpisah, clear ownership	PR tunggal, perlu careful review
Rekomendasi	✅ Direkomendasikan untuk tim besar	Cocok untuk tim kecil atau startup

Direktori Config Repository

File Structure — GitOps Config Repository

gitops-config/
├── README.md
├── apps/
│   ├── api-service/
│   │   ├── base/                          # Base manifests
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   ├── hpa.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/                      # Environment overrides
│   │       ├── staging/
│   │       │   ├── kustomization.yaml
│   │       │   └── patches-replicas.yaml
│   │       └── production/
│   │           ├── kustomization.yaml
│   │           ├── patches-replicas.yaml
│   │           └── patches-resources.yaml
│   │
│   ├── web-frontend/
│   │   ├── base/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   ├── ingress.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/
│   │       ├── staging/
│   │       └── production/
│   │
│   └── worker/
│       ├── base/
│       └── overlays/
│
├── infrastructure/                        # Infra-level resources
│   ├── namespaces.yaml
│   ├── network-policies.yaml
│   ├── rbac.yaml
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
│
└── projects/                              # ArgoCD project definitions
    ├── default.yaml
    └── production.yaml

4. ArgoCD: Instalasi & Setup

ArgoCD adalah GitOps operator untuk Kubernetes yang implementasi yang powerful dan declarative. ArgoCD mengimplementasikan keempat prinsip GitOps dan menyediakan UI, CLI, dan API untuk mengelola deployment. ArgoCD adalah CNCF graduated project yang digunakan oleh ribuan perusahaan di seluruh dunia.

Instalasi ArgoCD

Bash — ArgoCD Installation

# Buat namespace
kubectl create namespace argocd

# Install ArgoCD (stable release)
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Tunggu semua pods running
kubectl wait --for=condition=Ready pods --all -n argocd --timeout=300s

# Cek status pods
kubectl get pods -n argocd
# NAME                                  READY   STATUS    RESTARTS   AGE
# argocd-application-controller-xxx     1/1     Running   0          2m
# argocd-dex-server-xxx                 1/1     Running   0          2m
# argocd-redis-xxx                      1/1     Running   0          2m
# argocd-repo-server-xxx                1/1     Running   0          2m
# argocd-server-xxx                     1/1     Running   0          2m

# Expose ArgoCD server (LoadBalancer atau port-forward)
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

# Atau port-forward untuk development
kubectl port-forward svc/argocd-server -n argocd 8080:443

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

# Login via CLI
argocd login localhost:8080 --username admin --password  --insecure

# Ganti password default
argocd account update-password

# Install ArgoCD CLI
curl -sSL -o argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd
sudo mv argocd /usr/local/bin/

Akses ArgoCD

💡 Akses ArgoCD UI

Setelah instalasi, ArgoCD bisa diakses melalui:

Web UI: https://localhost:8080 (atau IP LoadBalancer)
CLI: argocd command
REST API: https://argocd-server/api/v1/
gRPC API: Untuk integrasi dengan tool lain

5. Membuat & Mengelola Aplikasi

ArgoCD mengelola Application — yang merupakan custom resource (CRD) yang mendefinisikan hubungan antara Git repository dan target cluster/namespace. Setiap application merepresentasikan satu unit deployment yang bisa di-manage secara independen.

Membuat Aplikasi via CLI

Bash — ArgoCD Application Creation

# Tambahkan cluster target (jika multi-cluster)
argocd cluster add staging-cluster-context

# Buat aplikasi via CLI
argocd app create api-service \
  --repo https://github.com/myorg/gitops-config.git \
  --path apps/api-service/overlays/production \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --sync-policy automated \
  --auto-prune \
  --self-heal \
  --revision main

# Lihat status aplikasi
argocd app get api-service

# Sync manual
argocd app sync api-service

# Lihat diff sebelum sync (dry-run)
argocd app diff api-service

Membuat Aplikasi via YAML Manifest

YAML — ArgoCD Application CRD

# argocd-app-api-service.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default

  source:
    repoURL: https://github.com/myorg/gitops-config.git
    targetRevision: main
    path: apps/api-service/overlays/production

    # Kustomize options
    kustomize:
      images:
        - myregistry.io/api-service:v1.2.3

  destination:
    server: https://kubernetes.default.svc
    namespace: production

  syncPolicy:
    automated:
      prune: true         # Hapus resource yang tidak ada di Git
      selfHeal: true      # Auto-revert manual changes
      allowEmpty: false    # Jangan sync jika tidak ada resource
    syncOptions:
      - CreateNamespace=true
      - PruneLast=true     # Hapus resource lama terakhir
      - ApplyOutOfSyncOnly=true
      - ServerSideApply=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

  # Health monitoring
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas    # Ignore autoscaler replica changes

# Terapkan manifest
kubectl apply -f argocd-app-api-service.yaml

Kustomize Overlay untuk Environment

YAML — Kustomize Overlay Production

# apps/api-service/overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
resources:
  - ../../base
patchesStrategicMerge:
  - patches-replicas.yaml
  - patches-resources.yaml
  - patches-env.yaml

# apps/api-service/overlays/production/patches-replicas.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 5    # Production: 5 replicas

# apps/api-service/overlays/production/patches-resources.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      containers:
        - name: api-service
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: "2"
              memory: 2Gi

6. Sync, Rollback & Health

Sync adalah proses menerapkan desired state dari Git ke cluster. ArgoCD mendukung berbagai mode sync, monitoring health status, dan mekanisme rollback yang sangat powerful.

Sync States

Status	Penjelasan	Aksi
Synced	Cluster sesuai dengan Git	Tidak perlu aksi
OutOfSync	Ada perbedaan antara Git dan cluster	Auto-sync atau manual sync
Syncing	Sedang dalam proses sync	Tunggu selesai
Sync Failed	Proses sync gagal	Cek error, fix, retry

Health Status

Health	Penjelasan
Healthy 🟢	Semua resource berjalan normal sesuai expected
Progressing 🔵	Resource sedang dalam proses (deploying, scaling)
Degraded 🟡	Ada masalah partial — beberapa pod crash atau error
Suspended ⚪	Resource di-suspend (misalnya deployment replicas=0)
Missing ⚫	Resource yang diharapkan tidak ditemukan di cluster
Unknown ❓	Health tidak bisa ditentukan

Rollback dengan GitOps

Salah satu keunggulan terbesar GitOps adalah rollback yang sederhana dan terpercaya. Karena semua state ada di Git, rollback hanya perlu git revert.

Bash — Rollback Workflow

# === ROLLBACK ===

# Lihat history deploy
argocd app history api-service
# ID  DATE                           REVISION
# 5   2026-06-25 14:30 +0700        main (abc1234)
# 4   2026-06-25 10:00 +0700        main (def5678)
# 3   2026-06-24 16:00 +0700        main (ghi9012)

# Opsi 1: Rollback ke revision tertentu
argocd app rollback api-service 4

# Opsi 2: Git revert (lebih "GitOps way")
cd gitops-config
git revert HEAD
git push origin main
# ArgoCD otomatis mendeteksi dan sync ke state sebelumnya

# Opsi 3: Lihat dan apply manifest tertentu
argocd app manifests api-service --revision def5678

# Cek status setelah rollback
argocd app get api-service

⚠️ Perbedaan Rollback ArgoCD vs Git Revert

argocd app rollback: Menggunakan cached manifest dari history, cepat tapi tidak tercatat di Git
git revert: Membuat commit baru yang mengembalikan perubahan, tercatat di Git history, recommended
Untuk produksi, selalu gunakan git revert agar audit trail lengkap dan semua orang tahu apa yang terjadi

7. Multi-Cluster Deployment

Salah satu keunggulan ArgoCD adalah kemampuan mengelola multiple cluster dari satu control plane. Ini sangat berguna untuk organisasi yang memiliki staging, production, dan environment regional yang tersebar di berbagai cloud provider.

Menambah Cluster ke ArgoCD

Bash — Multi-Cluster Setup

# Tambah cluster baru ke ArgoCD
# Metode 1: Via kubectl context
argocd cluster add staging-context --name staging
argocd cluster add production-us-east --name us-east
argocd cluster add production-eu-west --name eu-west

# Metode 2: Via kubeconfig file
argocd cluster add --kubeconfig /path/to/kubeconfig --name production-asia

# Lihat semua cluster yang terdaftar
argocd cluster list
# SERVER                          NAME        STATUS
# https://kubernetes.default.svc  in-cluster  Successful
# https://staging.example.com     staging     Successful
# https://us-east.example.com     us-east     Successful
# https://eu-west.example.com     eu-west     Successful

# Test koneksi ke cluster
argocd cluster get us-east

Deploy ke Multi-Cluster

YAML — Multi-Cluster Application

# Deploy ke cluster staging
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service-staging
  namespace: argocd
spec:
  project: staging
  source:
    repoURL: https://github.com/myorg/gitops-config.git
    targetRevision: main
    path: apps/api-service/overlays/staging
  destination:
    server: https://staging.example.com    # Cluster staging
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
---
# Deploy ke cluster production US
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service-us-east
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/myorg/gitops-config.git
    targetRevision: release/v1.2    # Pin ke release branch
    path: apps/api-service/overlays/production
  destination:
    server: https://us-east.example.com
    namespace: production
  syncPolicy:
    automated:
      selfHeal: true     # Self-heal saja, manual sync
  # Production: TIDAK auto-prune, manual approval dulu
---
# Deploy ke cluster production EU
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service-eu-west
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/myorg/gitops-config.git
    targetRevision: release/v1.2
    path: apps/api-service/overlays/production
  destination:
    server: https://eu-west.example.com
    namespace: production
  syncPolicy:
    automated:
      selfHeal: true

Arsitektur Multi-Cluster

Diagram: ArgoCD Multi-Cluster Architecture

┌──────────────────────────────────────────────────────────────────┐
│                ARGOCD CONTROL PLANE                               │
│                (Central Cluster)                                  │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐    │
│  │                   ArgoCD Server                           │    │
│  │  • Web UI (Single Pane of Glass)                         │    │
│  │  • Application Controller                                 │    │
│  │  • Repo Server                                            │    │
│  └───────────────────────┬──────────────────────────────────┘    │
│                          │                                        │
│         ┌────────────────┼────────────────┐                      │
│         │                │                │                      │
│         ▼                ▼                ▼                      │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐                 │
│  │  Staging   │  │ Prod US    │  │ Prod EU    │                 │
│  │  Cluster   │  │  Cluster   │  │  Cluster   │                 │
│  │            │  │            │  │            │                 │
│  │ Auto-sync  │  │ Manual     │  │ Manual     │                 │
│  │ Auto-prune │  │ sync       │  │ sync       │                 │
│  │ main branch│  │ release/   │  │ release/   │                 │
│  │            │  │ v1.2       │  │ v1.2       │                 │
│  └────────────┘  └────────────┘  └────────────┘                 │
└──────────────────────────────────────────────────────────────────┘

8. GitOps Best Practices

Setelah memahami konsep dan implementasi dasar, berikut best practices yang harus diterapkan untuk GitOps yang sukses di production.

Repository & Structure

💡 Best Practice: Repository

Pisahkan app repo dan config repo — Source code terpisah dari manifest deployment
Gunakan Kustomize atau Helm — Hindari raw YAML yang redundan antar environment
Gunakan branch strategy yang jelas — Contoh: main → staging, release/* → production
CODEOWNERS di config repo — Tim infra men-review perubahan manifest
Semua perubahan via Pull Request — Tidak ada commit langsung ke main/release branch

Security & RBAC

YAML — ArgoCD RBAC Policy

# argocd-rbac-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # Default policy: read-only
  policy.default: role:readonly

  policy.csv: |
    # Admin bisa melakukan semua aksi
    p, role:admin, *, *, */*, allow

    # Developer bisa sync aplikasi tertentu
    p, role:developer, applications, get, staging/*, allow
    p, role:developer, applications, sync, staging/*, allow
    p, role:developer, applications, action/*, staging/*, allow

    # Production hanya bisa di-read, sync butuh approval
    p, role:developer, applications, get, production/*, allow

    # SRE team bisa manage semua
    p, role:sre, applications, *, */*, allow
    p, role:sre, clusters, *, *, allow

    # Assign user ke roles
    g, alice, role:admin
    g, bob, role:developer
    g, carol, role:sre

  # Scopes: match groups dari SSO
  scopes: "[groups]"

Arsitektur Deployment Pipeline yang Disarankan

Diagram: Enterprise GitOps Pipeline

┌──────────────────────────────────────────────────────────────────┐
│               ENTERPRISE GITOPS PIPELINE                         │
│                                                                  │
│  Developer                                                      │
│    │ 1. Push kode ke app repo                                   │
│    ▼                                                            │
│  ┌──────────────┐                                               │
│  │  CI Pipeline │ ← Build, Test, Security Scan, Image Push      │
│  │  (GitHub     │   • Unit test + integration test              │
│  │   Actions)   │   • Container scanning (Trivy/Snyk)           │
│  │              │   • Push image ke registry                    │
│  └──────┬───────┘                                               │
│         │ 2. Update image tag di config repo                    │
│         ▼                                                       │
│  ┌──────────────┐                                               │
│  │ Config Repo  │ ← Kustomize/Helm manifests                   │
│  │ (Git)        │                                               │
│  └──────┬───────┘                                               │
│         │ 3. PR review & merge                                  │
│         ▼                                                       │
│  ┌──────────────┐                                               │
│  │   ArgoCD     │ ← Automated sync to staging                   │
│  │              │                                               │
│  │ Staging      │ → Auto-sync, auto-prune, run tests           │
│  │              │                                               │
│  │ Production   │ → Manual sync (gate) + auto-heal              │
│  └──────┬───────┘                                               │
│         │                                                       │
│         ▼                                                       │
│  ┌──────────────────────────────────────────────┐               │
│  │         KUBERNETES CLUSTERS                   │               │
│  │  • Always matches Git                         │               │
│  │  • Auto-heal drift                            │               │
│  │  • Complete audit trail                       │               │
│  └──────────────────────────────────────────────┘               │
└──────────────────────────────────────────────────────────────────┘

Checklist GitOps Implementation

No.	Checklist Item	Prioritas
1	Gunakan Git sebagai single source of truth	🔴 Wajib
2	Semua perubahan via Pull Request	🔴 Wajib
3	Aktifkan automated sync untuk staging	🔴 Wajib
4	Aktifkan self-heal untuk semua environment	🔴 Wajib
5	Gunakan Kustomize/Helm untuk menghindari YAML duplikat	🟡 Penting
6	Pisahkan app repo dan config repo	🟡 Penting
7	Implementasi RBAC dan SSO di ArgoCD	🟡 Penting
8	Setup notification (Slack/email) untuk sync events	🟡 Penting
9	Gunakan ArgoCD ApplicationSet untuk multi-cluster	🟢 Recommended
10	Monitor ArgoCD health dan metrics	🟢 Recommended

⚠️ Common Pitfalls

Jangan commit secrets ke Git — Gunakan Sealed Secrets, External Secrets, atau SOPS
Jangan auto-prune di production — Butuh approval manual untuk menghapus resource
Jangan lupa monitoring — Monitor ArgoCD metrics dan notification
Jangan satu config repo untuk semua team — Gunakan ArgoCD Projects untuk isolasi
Jangan update langsung ke cluster — Selalu lewat Git, jangan bypass ArgoCD

9. Quiz: Uji Pemahamanmu!

Setelah membaca tutorial di atas, jawablah 5 pertanyaan berikut untuk menguji pemahamanmu tentang GitOps dan ArgoCD:

Pertanyaan 1: Apa yang menjadi "single source of truth" dalam GitOps?

a) Kubernetes cluster

b) CI/CD pipeline configuration

c) Git repository

d) Docker registry

Pertanyaan 2: Apa yang dilakukan ArgoCD saat terjadi "drift" (perbedaan) antara Git dan cluster?

a) Mengirim email notifikasi dan menunggu manual approval

b) Mengabaikan perbedaan tersebut

c) Jika self-heal aktif, otomatis mengembalikan cluster ke state di Git

d) Meng-update Git repository agar sesuai dengan cluster

Pertanyaan 3: Perintah apa yang digunakan untuk rollback deployment di GitOps way?

a) kubectl rollout undo

b) argocd app rollback

c) git revert

d) helm rollback

Pertanyaan 4: Mengapa CI/CD pipeline dalam GitOps tidak perlu memiliki akses langsung ke Kubernetes cluster?

a) Karena Kubernetes tidak mendukung API access dari CI/CD

b) Karena pipeline hanya perlu push image ke registry

c) Karena GitOps agent di dalam cluster yang menarik (pull) perubahan dari Git

d) Karena pipeline menggunakan webhook untuk deploy

Pertanyaan 5: Apa perbedaan antara "automated sync" dan "manual sync" di ArgoCD?

a) Automated sync menghapus resource lama, manual sync tidak

b) Automated sync otomatis menerapkan perubahan saat Git berubah, manual sync memerlukan persetujuan atau trigger manusia

c) Automated sync hanya untuk staging, manual sync hanya untuk production

d) Tidak ada perbedaan, keduanya berjalan otomatis

GitOps dengan ArgoCD

1. Pengenalan GitOps

GitOps vs Traditional CI/CD

Manfaat GitOps

2. 4 Prinsip GitOps

Prinsip 1: Declarative Configuration

Prinsip 2: Versioned & Immutable

Prinsip 3: Pulled & Auto-Approved

Prinsip 4: Continuously Reconciled

3. Arsitektur GitOps

Repo Structure: Monorepo vs Polyrepo

Direktori Config Repository

4. ArgoCD: Instalasi & Setup

Instalasi ArgoCD

Akses ArgoCD

5. Membuat & Mengelola Aplikasi

Membuat Aplikasi via CLI

Membuat Aplikasi via YAML Manifest

Kustomize Overlay untuk Environment

6. Sync, Rollback & Health

Sync States

Health Status

Rollback dengan GitOps

7. Multi-Cluster Deployment

Menambah Cluster ke ArgoCD

Deploy ke Multi-Cluster

Arsitektur Multi-Cluster

8. GitOps Best Practices

Repository & Structure

Security & RBAC

Arsitektur Deployment Pipeline yang Disarankan

Checklist GitOps Implementation

9. Quiz: Uji Pemahamanmu!

Pertanyaan 1: Apa yang menjadi "single source of truth" dalam GitOps?

Pertanyaan 2: Apa yang dilakukan ArgoCD saat terjadi "drift" (perbedaan) antara Git dan cluster?

Pertanyaan 3: Perintah apa yang digunakan untuk rollback deployment di GitOps way?

Pertanyaan 4: Mengapa CI/CD pipeline dalam GitOps tidak perlu memiliki akses langsung ke Kubernetes cluster?

Pertanyaan 5: Apa perbedaan antara "automated sync" dan "manual sync" di ArgoCD?

📬 Dapatkan Tutorial Terbaru