GitOps menjadikan repositori Git sebagai sumber deklaratif bagi konfigurasi aplikasi dan infrastruktur. Namun, keadaan di cluster atau server tidak selalu sama dengan konfigurasi yang tersimpan di repositori. Seseorang mungkin mengubah resource langsung dari konsol, sebuah controller dapat mengisi nilai tertentu, atau proses darurat meninggalkan perubahan yang tidak pernah dicatat. Selisih antara keadaan yang diinginkan dan keadaan aktual ini disebut configuration drift.
Jika dibiarkan, drift membuat lingkungan produksi sulit diprediksi. Perubahan yang tidak tercatat dapat hilang saat deployment berikutnya, menimbulkan perbedaan antara staging dan produksi, atau melemahkan kontrol keamanan. Karena itu, deteksi drift merupakan bagian penting dari operasi GitOps—bukan sekadar cara memeriksa apakah deployment berhasil.
Apa yang dimaksud dengan configuration drift?
Dalam pendekatan deklaratif, Git menyimpan keadaan yang diinginkan: misalnya jumlah replika, batas sumber daya, konfigurasi jaringan, kebijakan akses, dan versi image container. Controller membandingkan definisi tersebut dengan keadaan aktual di lingkungan target. Ketika keduanya berbeda, sistem menandai aplikasi sebagai tidak sinkron atau out of sync.
Tidak semua perbedaan berarti insiden. Kubernetes dapat menambahkan nilai bawaan, controller dapat mengelola field tertentu, dan beberapa sistem menghasilkan metadata secara otomatis. Tim perlu membedakan perubahan yang memang diharapkan dari perubahan manual atau konfigurasi yang menyimpang. Tanpa aturan pembandingan yang jelas, tim bisa tenggelam dalam peringatan yang tidak berguna.
Bagaimana alat GitOps mendeteksi drift?
Alat seperti Argo CD dan Flux memantau sumber deklaratif serta membandingkannya dengan resource yang berjalan. Argo CD menampilkan status sinkronisasi dan perbedaan konfigurasi; dokumentasi resminya menjelaskan mekanisme sinkronisasi otomatis. Flux menggunakan rekonsiliasi berkelanjutan untuk menjaga sumber yang dideklarasikan tetap diterapkan pada cluster.
Ketika ada selisih, operator dapat melihat resource yang terdampak, membandingkan manifest dengan keadaan aktual, lalu memutuskan apakah perubahan perlu dikembalikan atau dicatat ke Git. Status kesehatan dan status sinkronisasi adalah dua hal berbeda: aplikasi dapat tetap berjalan normal walaupun konfigurasinya menyimpang.
Mengapa drift perlu ditangani dengan hati-hati?
- Keamanan: perubahan manual mungkin membuka port, memperluas izin, atau menonaktifkan kontrol.
- Keandalan: perubahan darurat yang tidak dicatat dapat tertimpa saat rekonsiliasi berikutnya.
- Konsistensi: lingkungan yang seharusnya serupa bisa memiliki konfigurasi berbeda tanpa diketahui tim.
- Audit: tanpa jejak perubahan di Git, peninjau kesulitan mengetahui siapa mengubah apa dan alasannya.
Drift kecil yang terus menumpuk juga menyulitkan pemecahan masalah karena konfigurasi yang diperiksa pengembang tidak lagi mencerminkan sistem yang benar-benar berjalan.
Alur praktis menangani drift
- Deteksi dan beri konteks. Catat nama aplikasi, resource, waktu pertama kali menyimpang, dan lingkungan yang terdampak. Cocokkan dengan riwayat deployment serta perubahan Git.
- Tinjau perbedaan sebelum bertindak. Periksa diff untuk mengetahui field yang berubah. Pastikan selisih bukan nilai bawaan atau perubahan yang dikelola controller lain.
- Tentukan sumber kebenaran. Jika perubahan manual memang diperlukan, masukkan perubahan yang sah ke Git melalui pull request. Jika tidak sah, rencanakan pemulihan ke keadaan deklaratif yang disetujui.
- Uji dampak rekonsiliasi. Sebelum sinkronisasi, periksa apakah tindakan akan mengganti konfigurasi penting, menghapus resource, atau memicu restart.
- Catat penyebab dan pencegahan. Perbaiki prosedur akses, dokumentasi keadaan darurat, atau pipeline agar perubahan serupa tidak terulang.
Gunakan otomatisasi dengan pagar pengaman
Sinkronisasi otomatis dapat mempercepat pemulihan, tetapi mengaktifkannya tanpa kontrol dapat memperburuk insiden. Fitur self-heal membantu mengembalikan perubahan yang tidak diinginkan, sedangkan kebijakan pruning dapat menghapus resource yang tidak lagi tercantum dalam deklarasi. Untuk resource penting, pertimbangkan persetujuan eksplisit sebelum penghapusan dan batasi siapa yang boleh mengubah konfigurasi produksi secara langsung.
Mulailah dengan mode pemantauan dan notifikasi. Setelah tim memahami pola drift normal, aktifkan pemulihan otomatis untuk resource berisiko rendah. Gunakan jendela pemeliharaan, prosedur rollback, dan pengujian pada staging. Pastikan tim mengetahui cara menghentikan rekonsiliasi otomatis bila perubahan yang tidak diharapkan mulai terjadi.
Metrik dan kebiasaan yang membantu
Pantau jumlah resource yang tidak sinkron, lamanya drift berlangsung, frekuensi perubahan manual, dan waktu yang dibutuhkan untuk menyelesaikannya. Peringatan sebaiknya menyertakan nama aplikasi, lingkungan, resource, serta tautan ke diff, bukan hanya pesan umum. Tinjau pola berulang untuk mengetahui apakah penyebabnya adalah akses manual, nilai konfigurasi yang tidak konsisten, atau controller yang saling bertentangan.
Jangan langsung menerapkan pemulihan massal pada seluruh cluster. Mulai dari ruang lingkup kecil, pastikan diff dapat dipahami, dan buat perubahan melalui proses peninjauan yang dapat diaudit. Dengan cara ini, GitOps menjadi mekanisme pengendalian konfigurasi yang dapat dipercaya, bukan otomatisasi yang berjalan tanpa pengawasan.
Kesimpulan
Deteksi drift membantu tim menemukan perbedaan antara konfigurasi di Git dan resource yang benar-benar berjalan. Keberhasilan tidak hanya bergantung pada alat, tetapi juga pada aturan pembandingan, proses peninjauan, dan pemulihan yang aman. Mulailah dengan observabilitas, selidiki penyebab perbedaan, lalu aktifkan otomatisasi secara bertahap sesuai risiko. Dengan jejak perubahan yang jelas, lingkungan lebih konsisten, aman, dan mudah diaudit.