Belajar GitOps - FluxCD - Notifications & Alerts

#Pendahuluan

Di episode 13 kalian sudah belajar image automation — FluxCD memantau registry dan memperbarui Git secara otomatis. Semua otomatisasi itu menarik, tetapi otomatisasi tanpa visibilitas bisa berbahaya. Bagaimana kalian tahu image baru sudah masuk? Bagaimana tahu sync gagal di malam hari? Jawabannya ada di notifikasi.

Episode 14 membahas sistem event FluxCD dan bagaimana mengubahnya menjadi alert yang sampai ke tim: mulai dari konsep event, Provider, Alert CRD, contoh notifikasi, webhook receiver, sampai template kustom.

#Sistem Event di FluxCD

Setiap controller FluxCD menghasilkan event ketika sesuatu terjadi: sync berhasil, sync gagal, artifact diperbarui, health check gagal, dan lain-lain. Semua event dikumpulkan oleh notification-controller, komponen yang juga menangani provider dan receiver.

Setiap event membawa metadata: severity, timestamp, reason, komponen yang menghasilkan, dan informasi objek terkait. Metadata inilah bahan baku yang disaring dan dirutekan oleh Alert.

#Provider

Provider adalah definisi ke mana notifikasi dikirim. Notification-controller mendukung banyak jenis provider:

Kredensial provider disimpan di Secret, bukan langsung di Provider. Contoh untuk Slack:

apiVersion: v1
kind: Secret
metadata:
  name: slack-url
  namespace: flux-system
stringData:
  address: https://hooks.slack.com/services/xxxxx

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: slack
  namespace: flux-system
spec:
  type: slack
  channel: gitops
  secretRef:
    name: slack-url

Provider hanya aktif di namespace yang sama dengan Alert yang mereferensikannya. Prinsip yang sama berlaku untuk Teams, Discord, dan provider lainnya — yang berbeda hanya nilai type dan isi Secret.

#Alert CRD

Alert menghubungkan event dari sumber tertentu dengan provider tertentu, sekaligus menyaring event yang tidak penting. Komponen utama dari Alert:

• eventSources — objek yang event-nya dipantau, misalnya Kustomization, HelmRelease, GitRepository
• eventSeverity — tingkat keparahan yang diteruskan, info atau error
• providerRef — referensi ke Provider tujuan
• inclusionList dan exclusionList — filter berdasarkan reason event
• eventMetadata — metadata tambahan yang dilampirkan ke notifikasi

Contoh Alert untuk kegagalan deployment:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: deploy-failure
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: "*"
    - kind: HelmRelease
      name: "*"

Alert di atas meneruskan semua event severity error dari semua Kustomization dan HelmRelease ke channel Slack gitops.

#Filter dengan Exclusion List

Untuk channel yang sibuk, filter event yang terlalu berisik:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: discord-alerts
  namespace: flux-system
spec:
  providerRef:
    name: discord
  eventSeverity: info
  eventSources:
    - kind: Kustomization
      name: "*"
  exclusionList:
    - "reason=ReconciliationSucceeded"
    - "reason=ArtifactUpToDate"

Dengan begitu channel Discord hanya menerima event yang benar-benar informatif.

#Contoh Notifikasi

#Deployment Success dan Failure

Alert dengan eventSeverity: error seperti contoh sebelumnya menangkap kegagalan. Untuk notifikasi keberhasilan, buat Alert terpisah dengan severity info dan exclusion list untuk reason yang bising.

#Source Updates

Pantau GitRepository agar tim tahu kapan artifact baru dihasilkan:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: source-updates
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: info
  eventSources:
    - kind: GitRepository
      name: "*"
    - kind: OCIRepository
      name: "*"

#Health Status Changes

Kegagalan health check dari Kustomization bisa disaring secara spesifik:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: health-checks
  namespace: flux-system
spec:
  providerRef:
    name: teams
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: "*"
  inclusionList:
    - "reason=HealthCheckFailed"

#Ringkasan Strategi

#Webhook Receiver

Selain mengirim notifikasi keluar, FluxCD juga bisa menerima event masuk melalui Receiver. Receiver berguna untuk mempercepat reconciliation: saat terjadi push di GitHub, webhook memicu Flux untuk langsung sync tanpa menunggu interval.

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: github-receiver
  namespace: flux-system
spec:
  type: github
  events:
    - ping
    - push
  secretRef:
    name: receiver-token
  resources:
    - kind: GitRepository
      name: "*"

FluxCD mendukung berbagai tipe receiver: github, gitlab, bitbucket, harbor, dan generic. Untuk tipe GitHub, konfigurasikan webhook di pengaturan repository GitHub agar mengarah ke URL Receiver yang diekspos FluxCD.

#Template dan Variable Substitution

Pesan notifikasi default sudah cukup untuk banyak kasus, tapi kadang perlu konteks tambahan. Alert mendukung eventMetadata yang melampirkan informasi tambahan ke setiap event:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: webhook-alerts
  namespace: flux-system
spec:
  providerRef:
    name: webhook
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: "*"
  eventMetadata:
    cluster: prod-eu
    team: platform

Provider bertipe webhook dapat menerima payload yang memuat metadata tersebut, sehingga sistem penerima bisa memprosesnya lebih lanjut, misalnya mengelompokkan alert berdasarkan cluster.

#Penutup

Episode 14 ini menjelaskan bagaimana membuat FluxCD berbicara kepada tim melalui notifikasi yang tepat sasaran.

Inti yang harus dibawa pulang:

• Semua controller menghasilkan event dan notification-controller yang merutekannya.
• Provider mendefinisikan tujuan notifikasi, dan kredensial disimpan terpisah di Secret.
• Alert CRD menghubungkan event dengan provider plus filter severity, reason, dan sumber.
• Receiver memungkinkan Flux dipicu dari luar, misalnya push GitHub, untuk sync instan.
• Metadata membuat notifikasi lebih informatif untuk tim yang sedang on-call.

Di episode 15 berikutnya kita masuk fase baru: Progressive Delivery dengan Flagger — cara mendeploy versi baru dengan risiko minimal menggunakan canary, A/B testing, dan blue-green secara otomatis. Sampai jumpa!