GitOps adalah metodologi pengembangan yang mempromosikan penggunaan file berversi dalam repositori kontrol sumber untuk mendefinisikan dan mengelola infrastruktur Anda. Mengekspresikan arsitektur Anda sebagai file deklaratif menyediakan cara untuk memeriksa konfigurasi sistem Anda saat ini, menggabungkan perubahan dari beberapa kontributor, dan mengembalikan ke status sebelumnya.
Saat ini pendekatan ini mirip dengan Infrastructure as Code (IaC). GitOps lebih dari sekedar IaC: implementasi yang sukses akan mencakup a otomatis mekanisme untuk menerapkan file konfigurasi Anda ke komponen infrastruktur langsung. Mengintegrasikan perubahan akan menyebabkan status infrastruktur Anda bertransisi ke yang dijelaskan oleh konten repositori yang diubah.
Ini membutuhkan jembatan antara platform kontrol sumber Anda dan penyedia infrastruktur Anda, memungkinkan keadaan saat ini untuk dikomunikasikan di antara keduanya. Ada berbagai cara jembatan ini dapat diimplementasikan, masing-masing menempatkan serangkaian tanggung jawab unik pada platform yang terlibat. Dalam artikel ini, kita akan melihat model penerapan berbasis Agen (atau berbasis Tarik), lalu membandingkannya dengan pendekatan berbasis Push.
Apa itu Agen?
GitOps berbasis agen mengacu pada menjalankan proses dalam infrastruktur Anda yang memfasilitasi penerapan Anda. Proses ini bertanggung jawab untuk menjaga komunikasi dengan platform kontrol sumber yang menghosting file IaC Anda.
Agen adalah aktif bagian dari infrastruktur Anda. Ini akan terhubung secara berkala ke repositori Git Anda, memeriksa perubahan, dan menarik komit baru ke dalam lingkungan penerapan Anda. Agen selanjutnya akan mengambil tindakan untuk menerapkan perubahan yang diperoleh ke lingkungannya, memicu transisi status yang sesuai.
Agen dapat menyediakan fitur tambahan seperti pemantauan penerapan bawaan, pencatatan log, dan peringatan. Mereka memberi Anda informasi terus-menerus tentang aktivitas dalam infrastruktur Anda. Agen menangani integrasi dengan alat Anda yang ada untuk menampilkan informasi yang relevan di tempat yang sesuai.
Model agen berbeda dari pandangan konvensional tentang Continuous Integration and Continuous Deployment (CI/CD) dengan memotong konsep pipa pemicu-terikat. Sebagai gantinya, ada loop rekonsiliasi otomatis yang menangkap perubahan saat tersedia. Hanya komit dan penggabungan baru secara tidak langsung mendorong inovasi dalam infrastruktur Anda. Mungkin perlu beberapa saat bagi agen untuk mendapatkan data baru.
Beberapa vendor menawarkan agen yang dapat digunakan untuk mengimplementasikan alur kerja GitOps. GitLab sekarang mempromosikan pendekatan ini sebagai metode yang disukai untuk penerapan ke Kubernetes, melalui Agen GitLab untuk Kubernetes. Agen terhubung ke instance GitLab dari dalam cluster Anda, kemudian memfasilitasi komunikasi dua arah untuk meluncurkan perubahan dan mengirim informasi kembali ke repositori Anda.
Flux by Weaveworks adalah opsi lain yang berfungsi dengan repositori Git apa pun dan menyertakan kemampuan peringatan. Flux sekarang menjadi proyek inkubator dalam Cloud Native Computing Foundation (CNCF). Ini berfungsi sebagai operator Kubernetes yang mengambil perubahan yang dibuat pada repo Git Anda yang terhubung.
Keuntungan Agen
GitOps berbasis agen memiliki banyak keunggulan yang membuatnya menarik bagi berbagai pemangku kepentingan. Pertama, ada perbedaan yang jelas antara tanggung jawab: platform kontrol sumber Anda tidak dapat diubah dan tidak perlu khawatir tentang koneksi ke infrastruktur Anda. Agen perlu diberikan kredensial repositori tetapi sebaliknya mandiri. Saat dijalankan, fokusnya hanya pada pendeteksian dan penerapan perubahan.
Mengisolasi masalah ini dapat membantu Anda mengidentifikasi masalah dan penyebab kegagalan penerapan. Anda dapat segera membuang platform kontrol sumber. Jika ini dilakukan dan cabang master Anda berisi perubahan yang benar, perbedaan dalam keadaan sebenarnya dari infrastruktur Anda harus menjadi masalah sinkronisasi agen.
Agen juga menawarkan tingkat otomatisasi yang lebih tinggi daripada GitOps berbasis Push. Agar berhasil mengadopsi aliran berbasis Push, Anda perlu mengonfigurasi repositori Anda dengan kredensial untuk infrastruktur Anda dan membuat pipeline CI yang menjalankan skrip yang benar untuk mengirim perubahan Anda. Skrip tersebut perlu direplikasi di semua proyek Anda, dipelihara dari waktu ke waktu, dan dikelola dengan hati-hati untuk melindungi kredensial sensitif Anda.
Sistem berbasis agen datang tanpa masalah ini. Setelah agen diinstal, Anda mendapat manfaat dari model penerapan tangguh yang tidak mudah berubah. Ada lebih sedikit variabel tentang menghubungkan ke repositori Git daripada berhasil mengakses lingkungan produksi seperti cluster Kubernetes. Jadi masuk akal untuk menarik perubahan dari sistem yang lebih sederhana ke yang lebih kompleks.
Manfaat lain adalah efek positif pada keamanan agen. Mereka berlari di dalam infrastruktur Anda sehingga Anda dapat mencegahnya dibuka untuk akses luar. Meskipun Anda perlu mengekspos repositori Git Anda, ini kurang berisiko daripada memberikan pintu ke lingkungan produksi Anda. Paparan token proyek GitHub kemungkinan hanya akan membocorkan kode sumber dan file IaC Anda – peristiwa serius tetapi tidak berarti jika dibandingkan dengan pemikiran kehilangan token akun Kubernetes produksi. Itu dapat menyebabkan pencurian data, pemerasan berikutnya, dan kompromi sistem yang tidak dapat diubah.
Bagaimana Dengan GitOps Berbasis Push?
Pendekatan alternatif adalah model berbasis Push di mana perubahan didorong ke infrastruktur Anda oleh platform kontrol sumber Anda atau sistem perantara. Komunikasi diprakarsai oleh sesuatu yang berjalan di luar lingkungan penerapan. Dorongan memaksa infrastruktur untuk menerima status baru dari server pengontrol.
GitOps berbasis push biasanya diimplementasikan dalam pipeline CI Anda. Anda menggunakan model ini jika Anda memiliki pipeline yang dikonfigurasi pada koneksi dan penggunaan cluster Kubernetes kubectl apply untuk membuat penerapan. Contoh lain adalah pipa berjalan rsync untuk menyinkronkan konten repositori Anda dengan host jarak jauh.
Keterbatasan pendekatan ini terletak pada ketidakmampuannya untuk menawarkan keuntungan yang terkait dengan agen yang kita bahas di atas. Anda perlu mengonfigurasi setiap repositori secara manual dengan koneksi infrastruktur yang sesuai, membuka lingkungan Anda untuk akses eksternal, dan bertanggung jawab untuk memelihara skrip penerapan Anda dari waktu ke waktu.
GitOps berbasis push masih memiliki beberapa manfaat berbeda. Faktor penting adalah sifatnya yang familier: Anda dapat terus menggunakan alat yang sudah Anda ketahui dan harapkan untuk dikembangkan, seperti kubectl, helmdan docker. Ini membantu meminimalkan perbedaan antara penerapan lokal dan langsung.
Penanganan kesalahan juga bisa lebih sederhana. Pendekatan berbasis push cenderung lebih sinkron yang dapat membantu menentukan urutan peristiwa yang mengarah ke kegagalan. Sementara agen memberi Anda titik awal yang jelas (agen itu sendiri), Anda kemudian dibiarkan memfilter peristiwa yang terkait dengan aktivitas agen itu. Peristiwa tersebut dapat mencakup lusinan proyek dan siklus rekonsiliasi yang berbeda. Kemampuan untuk memulai dari jalur pipa CI tertentu dapat membantu memberikan umpan balik langsung saat debugging.
Terakhir, terdapat argumen bahwa model berbasis Push sebenarnya lebih dapat beradaptasi dengan perubahan infrastruktur di masa depan. Mengadopsi Tarik berarti Anda menyelaraskan sistem Anda dengan harapan spesifik dari agen pilihan Anda. Ini dapat dengan cepat memperumit masalah jika Anda perlu menerapkan ke platform baru di mana agen tersebut tidak didukung. Pendekatan berbasis Push skrip lebih fleksibel di sini. Ini memungkinkan Anda memenuhi banyak lingkungan unik dengan menyertakan logika kondisional yang mengambil tindakan yang benar untuk platform target.
Ringkasan
GitOps berbasis agen mengacu pada menjalankan komponen aktif dalam infrastruktur Anda yang menjangkau ke repositori sumber Anda untuk mengambil dan menerapkan perubahan. Ini membalikkan model berbasis Push tempat Anda menjalankan skrip dalam pipeline CI untuk membuat penerapan dan menerapkan perubahan status.
Alur kerja Push adalah umum, mudah dimengerti, dan memiliki beberapa daya tarik penting. Namun, “tarik” yang digerakkan oleh agen mendapatkan lebih banyak perhatian di ekosistem cloud karena vendor dan pengembang menyadari manfaatnya.
Mengadopsi pendekatan berbasis Tarik dapat mengurangi pemeliharaan dari waktu ke waktu, meningkatkan keamanan lingkungan Anda, dan membantu Anda mengidentifikasi kegagalan saat perubahan tidak berlaku. Agen juga dapat menyederhanakan penyiapan fitur periferal seperti peringatan dan agregasi metrik, mempercepat jalur adopsi DevOps Anda tanpa harus mengintegrasikan skrip CI yang rumit secara manual.