Definisi GitOps dan Single Source of Truth (SSOT)
Pertama, mari kita pahami definisi sistem GitOps. Seperti yang telah dijelaskan sebelumnya mengenai karakteristik Kubernetes yang berbasis deklaratif dan proses instalasinya, semua sumber daya dalam Kubernetes dapat dikonfigurasi menggunakan kode. Oleh karena itu, sistem GitOps hadir sebagai konsep di mana konfigurasi tersebut disimpan di repositori Git, lalu sistem memastikan kondisi operasional saat ini (Ops) selalu selaras dengan kode di Git.
Dalam lingkungan kerja, pendekatan GitOps sering digunakan untuk mencegah perubahan langsung pada sistem produksi tanpa proses commit dan push. Tanpa GitOps, seseorang bisa saja mengubah konfigurasi langsung dari sumber lokal atau melalui perintah manual, sehingga pelacakan riwayat perubahan menjadi sangat sulit. Sebagai contoh, skenario umum sering terjadi ketika sebagian cluster bermasalah karena adanya perubahan manual tanpa dokumentasi yang rapi. Selain itu, proses pembangunan sistem baru tanpa pendekatan ini membutuhkan upaya ekstra untuk mencari konfigurasi yang benar.
Peran SSOT dalam Sistem GitOps
Sistem GitOps mengadopsi konsep Single Source of Truth (SSOT) yang sangat mendasar. Secara umum, SSOT adalah prinsip manajemen data yang menyatakan bahwa hanya ada satu versi data akurat serta terpercaya di seluruh sistem. Oleh sebab itu, konsep ini memiliki peran penting dalam meningkatkan stabilitas arsitektur:
- Konsistensi: Semua komponen sistem mengacu pada sumber data yang sama, sehingga tidak ada perbedaan informasi antar-layanan.
- Akurasi: Mengurangi potensi duplikasi atau inkonsistensi, sehingga akurasi data sistem tetap terjaga.
- Efisiensi: Proses pembaruan menjadi jauh lebih efisien karena tersimpan di satu lokasi utama yang terkelola.
Melalui penerapan sistem GitOps dan konsep SSOT, organisasi dapat menjaga stabilitas infrastruktur secara berkelanjutan.
Dalam sistem GitOps, repositori Git berfungsi sebagai SSOT untuk seluruh konfigurasi dan status sistem. Dengan menyimpan seluruh status kode serta infrastruktur ke dalam Git, sistem dapat dikelola secara otomatis menggunakan pendekatan deklaratif. Artinya, modifikasi status operasional tidak lagi dilakukan lewat perintah lokal, melainkan wajib melalui repositori Git terpusat.
Tantangan dan Pilihan Alat GitOps
Keuntungan utama sistem GitOps adalah kemampuannya menjaga konsistensi sistem dan mendorong kolaborasi tim yang solid. Karena seluruh anggota tim mengacu pada sumber data yang serupa, risiko inkonsistensi data dapat ditekan secara signifikan. Di samping itu, riwayat pelacakan status sistem pada titik waktu tertentu dapat ditinjau kembali dengan sangat mudah.
Namun, penerapan prinsip ini sering kali menghadapi hambatan di lapangan. Dalam rutinitas pekerjaan yang padat, godaan untuk mengubah konfigurasi secara langsung di server produksi cukup tinggi. Oleh karena itu, kehadiran alat GitOps yang mampu menegakkan kebijakan arsitektur secara otomatis menjadi sangat krusial.
Untuk menerapkan alur kerja tersebut, Continuous Deployment (CD) membutuhkan alat pendukung yang andal. Saat ini, ArgoCD menjadi salah satu opsi paling populer karena alasan berikut:
- Menyediakan antarmuka pengguna (UI) yang ramah pengguna.
- Sangat mudah diintegrasikan dengan berbagai alat cloud-native lainnya.
- Memiliki komunitas pengguna yang besar, sehingga dukungan dokumentasinya sangat melimpah.
Dengan memanfaatkan ArgoCD, tim rekayasa perangkat lunak dapat menjalankan GitOps secara konsisten dan efisien.
Fitur Unggulan ArgoCD: Sinkronisasi dan Visibilitas
Secara fungsional, ArgoCD terus memantau repositori Git serta klaster Kubernetes yang ditentukan. Jika sistem mendeteksi perbedaan, ArgoCD secara otomatis menyinkronkan status klaster agar persis dengan repositori. Selain mode otomatis tersebut, tersedia pula opsi sinkronisasi manual untuk kebutuhan pengujian khusus. Selanjutnya, jika timbul gangguan, sistem dapat segera dikembalikan (rollback) ke kondisi stabil sebelumnya berkat pencatatan versi di Git.
BACA JUGA : Apa saja platform yang didukung oleh APM JENNIFER
Di samping itu, ArgoCD menyediakan dasbor visual untuk memantau status aplikasi secara real-time sekaligus mengevaluasi metrik kesehatan (health). Ketika aplikasi dijalankan melalui Helm, struktur dependensi sumber daya kerap kali sulit dipahami. Namun, dasbor ArgoCD menyajikan visualisasi hierarki aplikasi dengan jelas dan transparan. Selain fitur pemantauan tersebut, ArgoCD juga menyediakan kontrol akses berbasis peran (RBAC) demi menjaga keamanan deployment.
Singkatnya, repositori Git bertindak sebagai SSOT agar klaster selalu sinkron tanpa jeda. Melalui pola kerja ini, kolaborasi antara tim pengembang dan tim operasional (DevOps) berjalan jauh lebih cepat dan stabil.
Panduan Praktik Instalasi ArgoCD
Untuk memahami cara kerjanya secara mendalam, berikut adalah alur praktikum yang akan dijalankan:
- Melakukan instalasi ArgoCD pada klaster.
- Menjalankan proses deployment Helm Chart NGINX menggunakan ArgoCD.
- Menguji eksperimen GitOps untuk memvalidasi perubahan manual lokal.
Mari kita mulai dengan tahapan persiapan instalasi.
Di dalam ekosistem Kubernetes, aplikasi umumnya dipasang menggunakan Helm sebagai pengelola paket (package manager). Serupa dengan fungsi APT atau YUM pada Linux, Helm membungkus berbagai manifest menjadi format chart terpadu. Oleh sebab itu, alur manajemen aplikasi menjadi jauh lebih ringkas. Pembahasan menyeluruh seputar Helm dapat dipelajari pada Bab 11.
Pengguna Windows WSL (dengan Homebrew) maupun macOS dapat memasang Helm di komputer lokal menggunakan perintah brew.
Setelah Helm terpasang, unduh Helm Chart resmi dari repositori ArgoCD.
Daftarkan repositori Helm ArgoCD ke lingkungan lokal menggunakan perintah helm repo add, kemudian unduh chart tersebut melalui helm pull. Selanjutnya, salin file konfigurasi bawaan Values.yaml menjadi jerry-test-values.yaml untuk penyesuaian parameter. Format modifikasi Helm Values resmi ini dapat dirujuk langsung pada repositori GitHub penulis.
Konfigurasi Nilai Helm ArgoCD
Pada parameter .configs.credentialTemplates.ssh-creds, daftarkan kredensial GitHub yang akan diakses oleh ArgoCD. Masukkan kunci privat SSH yang telah terdaftar di akun GitHub Anda (umumnya berada di ~/.ssh/id_rsa). Mengingat sifatnya yang rahasia, data kunci tersebut perlu disamarkan demi alasan keamanan.
Walaupun informasi repositori dapat dikonfigurasi melalui antarmuka grafis (GUI) setelah instalasi, memasukkannya langsung ke dalam kode sumber jauh lebih dianjurkan. Pendekatan deklaratif ini menjaga konsistensi konfigurasi serta memudahkan replikasi di masa mendatang.
Selanjutnya, isi parameter .repositories.k8s-class.name/url dengan nama serta URL repositori Git yang digunakan. Karena pengaturan Ingress belum diterapkan pada tahap ini, konfigurasi rute lalu lintas eksternal dapat diabaikan sementara waktu hingga pembahasan Bab 5. Setelah semua parameter siap, jalankan instalasi ArgoCD menggunakan berkas jerry-test-values.yaml.
Mengakses Dasbor ArgoCD via Port-Forward
Setelah pod ArgoCD berjalan normal, kita dapat mengakses layanannya menggunakan teknik port-forward. Biasanya, akses dari luar klaster membutuhkan konfigurasi Ingress. Namun, metode port-forward menjadi alternatif praktis bagi administrator untuk membuka akses tanpa menambah konfigurasi jaringan yang rumit.
Fitur ini dijalankan melalui perintah kubectl port-forward. Melalui mekanisme tersebut, lalu lintas data dari sistem lokal akan diteruskan oleh API Server Kubernetes menuju pod tujuan di dalam klaster.
Kubernetes mengatur lalu lintas pod melalui objek Service, sehingga penggunaan port-forward berbasis Service menjadi jauh lebih fleksibel. Pemetaan 8080:80 menandakan bahwa port 8080 pada localhost diarahkan langsung menuju port 80 milik Service di dalam klaster. Oleh karena itu, dasbor ArgoCD dapat langsung dibuka melalui peramban di alamat localhost:8080.
Untuk masuk pertama kali, kata sandi akun admin tersimpan di dalam objek Kubernetes Secret. Dekode Secret tersebut untuk membaca kata sandi aslinya.
Masukkan nama pengguna admin beserta kata sandi yang telah didekode. Setelah berhasil masuk, buka menu Settings > Repositories untuk memastikan repositori GitHub Anda telah terhubung secara normal.
Deployment Aplikasi NGINX via ArgoCD
Tahap berikutnya adalah mendeploy aplikasi web NGINX menggunakan Helm Chart melalui kontrol ArgoCD.
Langkah pengunduhan Helm Chart ini serupa dengan tahap sebelumnya. Anda dapat menggunakan versi rilis terbaru atau menetapkan versi spesifik (misalnya 15.1.0) agar selaras dengan konfigurasi panduan ini. Ubah parameter Values.yaml seperlunya, seperti menaikkan jumlah replika pod menjadi 2.
Meskipun proses deployment dapat dieksekusi langsung lewat antarmuka web, mendefinisikan aplikasi ke dalam bentuk kode deklaratif jauh lebih sejalan dengan prinsip GitOps. Untuk kebutuhan ini, ArgoCD menyediakan Custom Resource Definition (CRD) bernama Application.
Melalui CRD, kita dapat membuat jenis sumber daya baru di luar objek bawaan Kubernetes (seperti Pod atau Deployment). Selanjutnya, buat berkas manifest Application untuk server NGINX dengan konfigurasi berikut:
.metadata.finalizers: Memastikan penghapusan objekApplicationikut membersihkan seluruh komponen pod terkait..spec.destination.server: Menentukan klaster target deployment (gunakan[https://kubernetes.default.svc](https://kubernetes.default.svc)untuk klaster lokal)..spec.source.helm: Menentukan tipe instalasi menggunakan chart Helm..spec.source.pathdanrepoURL: Menunjukkan lokasi folder serta repositori sumber aplikasi..spec.syncPolicy.automated: Mengaktifkan sinkronisasi otomatis ketika ada perubahan kode di repositori Git..spec.syncOptions.CreateNamespace: Membuat namespace baru secara otomatis jika belum tersedia.
Terapkan manifest tersebut ke dalam klaster menggunakan perintah kubectl apply.
Verifikasi Sumber Daya dan Status Aplikasi
Setelah manifest diterapkan, objek Application akan langsung terdaftar di dalam klaster Kubernetes.
Buka kembali antarmuka web ArgoCD, lalu pastikan entri baru bernama argocd/nginx telah muncul pada daftar aplikasi.
Klik entri tersebut untuk memeriksa visualisasi pohon sumber daya yang terbentuk, mulai dari Service hingga Deployment.
Di samping pemantauan lewat web, status pod NGINX juga dapat diperiksa langsung melalui terminal lokal menggunakan perintah kubectl get pods.
Dengan demikian, seluruh proses instalasi beban kerja telah sepenuhnya dialihkan ke ArgoCD, bukan lagi dijalankan secara ad-hoc dari terminal lokal. Langkah ini menjamin bahwa seluruh konfigurasi tersimpan rapi di dalam Git.
Pengujian Validasi GitOps Terhadap Perubahan Manual
Sekarang, mari kita buktikan ketangguhan sistem GitOps ketika terjadi perubahan status yang tidak sesuai dengan repositori Git. Buka dua jendela terminal secara berdampingan: jendela atas untuk mengirim perintah manual, dan jendela bawah untuk memantau status secara langsung (kubectl get pod -w).
Pada terminal atas, ubah replika pod NGINX secara manual dari 2 menjadi 5 menggunakan perintah kubectl scale.
Meskipun perintah skala berhasil dikirim, jumlah pod tidak bertambah menjadi 5. Status pod sempat berada pada fase ContainerCreating, namun sesaat kemudian berubah menjadi Terminating.
Jumlah pod pada akhirnya tetap bertahan di angka 2. Fenomena ini terjadi karena konfigurasi pada repositori Git masih mencatat 2 replika, sehingga ArgoCD secara otomatis mengembalikan status klaster agar tetap sinkron dengan Git.
Selanjutnya, nonaktifkan opsi automated pada ArgoCD untuk melihat perbedaan secara detail. Jalankan kembali perintah kubectl scale deployment nginx --replicas 5. Kali ini, antarmuka web ArgoCD akan menampilkan status OutOfSync.
Buka menu APP DIFF untuk meninjau detail perbedaan; sistem akan menandai selisih antara 5 replika di klaster dan 2 replika di Git.
Penerapan Perubahan Melalui Jalur Git yang Tepat
Oleh sebab itu, dalam lingkungan produksi, tim operasional umumnya menonaktifkan fitur auto-sync agar evaluasi perubahan dapat diperiksa secara teliti sebelum diterapkan ke sistem aktif.
Untuk memperbarui jumlah pod secara sah, buka berkas Values.yaml NGINX di repositori lokal, lalu ubah nilai replicaCount menjadi 1.
Lakukan commit dan push perubahan tersebut ke cabang utama (main branch) repositori Git.
Begitu kode baru masuk ke repositori, ArgoCD akan membaca pembaruan tersebut dan menyelaraskan jumlah pod menjadi 1 secara otomatis. Pola deklaratif serupa juga berlaku saat mengelola infrastruktur berbasis Terraform melalui mekanisme tinjauan Pull Request (PR).
Proses peninjauan kode oleh rekan kerja terbukti mampu meminimalkan kesalahan fatal saat memperbarui infrastruktur klaster, seperti peningkatan versi EKS.
Selain skrip Terraform, skrip otomatisasi seperti kode Python AWS MSK juga sebaiknya dikelola di dalam repositori Git. Kendati proses rekayasa berbasis kode membutuhkan kedisiplinan tinggi, dokumentasi yang terpusat akan mempermudah pemeliharaan sistem di masa mendatang.
Pada akhirnya, GitOps bukan sekadar perihal perkakas perangkat lunak, melainkan komitmen operasional untuk menjaga stabilitas infrastruktur melalui prosedur yang tertib.
Penerapan alur kerja GitOps memang menjaga konsistensi deployment, namun pemantauan performa aplikasi secara real-time tetap menjadi kunci utama. Oleh sebab itu, Anda memerlukan solusi pemantauan menyeluruh untuk memastikan setiap rilis berjalan optimal tanpa kendala di balik layar.
Ingin membuktikannya langsung? Anda bisa mencoba keandalan JENNIFER APM secara cuma-cuma lewat penawaran FREE TRIAL selama 1 Bulan GRATIS. Kunjungi beranda APM GEEKS, klik banner promo yang tersedia, dan mulai pantau aplikasi Anda sekarang juga! Klik Disini
