Belajar GitOps - FluxCD - Dependencies & Orchestration

#Pendahuluan

Di episode 9 kalian sudah mengenal semua tipe source. Sekarang pertanyaannya bergeser: bagaimana memastikan semuanya ter-deploy dalam urutan yang benar? Sebuah cluster produksi berisi puluhan aplikasi yang saling bergantung — database harus ada sebelum aplikasi, CRD sebelum custom resource, ingress sebelum service yang menggunakannya.

Episode ini membahas dependsOn, health checks, strategi urutan, dan pola untuk skenario orkestrasi yang kompleks.

#Dependensi dengan dependsOn

dependsOn adalah cara Flux menyatakan bahwa sebuah Kustomization atau HelmRelease baru boleh dijalankan setelah yang lain selesai dan sehat:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
    - name: databases
  path: ./apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

Dependency tidak dibatasi namespace — cukup tulis namespace bersama name:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-a-apps
  namespace: team-a
spec:
  interval: 10m
  dependsOn:
    - name: platform
      namespace: flux-system
  path: ./team-a
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#Mencegah Circular Dependency

Flux mendeteksi rantai dependency yang melingkar dan menolaknya saat validasi. Aturan praktisnya:

• Buat grafik dependency berbentuk DAG (directed acyclic graph).
• Jika A dan B saling membutuhkan, gabungkan keduanya dalam satu Kustomization, bukan dua yang saling dependsOn.
• Gunakan flux trace untuk melihat bagaimana sebuah Kustomization terhubung dengan yang lain:

flux trace kustomization apps

#Health Checks

Tanpa health check, Flux hanya tahu bahwa resource ter-apply — bukan sehat. Health assessment bawaan Flux mengecek tipe resource umum: Deployment harus punya replica siap, Job harus selesai, Pod harus Running.

Untuk kontrol lebih, deklarasikan healthChecks:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  timeout: 5m
  path: ./apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: webapp
      namespace: webapp
    - apiVersion: batch/v1
      kind: Job
      name: migration
      namespace: webapp

• timeout — batas maksimal satu siklus rekonsiliasi, termasuk menunggu health checks. Default 5 menit.
• Health check gagal berarti Ready bernilai False pada Kustomization, dan Kustomization lain yang bergantung padanya ikut menunggu.

#Readiness Gates

Untuk objek yang tidak dikenal Flux (misal custom resource operator), pakai spec.conditions — mirip readiness gate dari Kubernetes:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-operator
  namespace: flux-system
spec:
  interval: 10m
  path: ./infrastructure/app-operator
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: app-operator
      namespace: platform
  commonMetadata:
    annotations:
      app.kubernetes.io/name: app-operator

#Strategi Urutan Deploy

Urutan deploy ditentukan oleh struktur dependency, bukan flag global:

Contoh mixed: lima aplikasi independen berjalan paralel, semuanya menunggu infrastructure:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-catalog
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  path: ./apps/catalog
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-billing
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  path: ./apps/billing
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#Skenario Kompleks

Beberapa pola yang sering muncul di production:

#Database Sebelum Aplikasi

flux create kustomization databases \
  --source=fleet \
  --path="./infrastructure/databases" \
  --prune=true
 
flux create kustomization apps \
  --source=fleet \
  --path="./apps" \
  --prune=true \
  --depends-on=databases

#Secrets Sebelum Deployment

Secret yang dibuat operator (misal External Secrets Operator) harus ada sebelum pod mulai. Taruh Kustomization secret di depan dan pastikan deployment menunggu:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-backend
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: secrets-sync
  path: ./apps/backend
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#CRD Sebelum Custom Resource

Ini yang paling sering dilupakan. Urutan yang benar:

1. Kustomization crds berisi CRD dan Deployment operator.
2. Kustomization resources memakai CRD itu, dengan dependsOn ke crds.

#Infrastruktur Berlapis

Urutkan dari lapisan dasar ke atas: storage → network/ingress → observability → aplikasi. Tiap lapisan hanya bergantung pada lapisan di bawahnya.

#Penutup

Orkestrasi deployment kini bisa diprediksi:

• dependsOn membangun grafik dependency, termasuk lintas namespace.
• Health checks dan readiness gates menentukan arti "selesai dengan baik".
• Urutan bisa sequential, paralel, atau campuran sesuai struktur dependency.
• Pola database-before-app, secrets-before-pods, dan CRD-before-custom-resource menjaga stabilitas.

Alur deploy sudah kokoh. Di episode 11 kita akan mengelola konfigurasi: variable substitution, konfigurasi per environment, integrasi secret management, dan praktik terbaik menjaga repository tetap bersih. Sampai jumpa!