GitOps telah ada selama beberapa tahun sekarang, tetapi telah mendapatkan daya tarik baru-baru ini karena kontainer dan kompleksitas seputar pengelolaan dan penerapan lingkungan waktu proses kontainer yang konsisten.
Apa masalah yang coba dipecahkan GitOps? Nah, alat ini mengotomatiskan operasi perangkat lunak sehingga perusahaan dapat menjadi lebih baik dalam rekayasa perangkat lunak. GitOps memungkinkan tim aplikasi untuk merilis lebih sering dan mengoperasikan aplikasi cloud native dengan lebih efektif.
Blog ini akan menjelajahi apakah GitOps dapat diterapkan ke topologi edge—terutama membuat pipeline CI/CD yang dapat menerapkan aplikasi ke perangkat far edge. Untuk menegaskan kembali, edge mencakup perangkat-perangkat far edge sampai ke cloud, dengan enterprise edge dan network edge di sepanjang jalurnya.
GitOps adalah praktik DevOps yang menggunakan Git sebagai sumber kebenaran tunggal di mana status konfigurasi yang diinginkan disimpan. Fokusnya adalah pada otomatisasi operasi, didorong dari repositori Git. Meskipun ada dalam judul, Git bukan satu-satunya repositori yang dapat digunakan. Antarmuka yang disediakan oleh Git yang mengotomatiskan operasi. GitOps akhirnya menggunakan informasi yang diekstrak dari metadata build untuk menentukan paket mana yang akan dibangun yang dipicu oleh perubahan kode tertentu:
Pada intinya, model GitOps menggunakan pola pengontrol. Hal ini lebih lanjut dibantu oleh pola operator dari perspektif Kubernetes atau OpenShift, di mana operator adalah ekstensi perangkat lunak yang menggunakan sumber daya khusus untuk mengelola aplikasi dan komponennya.
Tidak tepat rasanya jika kami tidak menyebutkan Argo CD, alat GitOps yang membantu alur kerja GitOps. Argo CD adalah alat deklaratif sumber terbuka untuk integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD) aplikasi. Diimplementasikan sebagai pengontrol Kubernetes, Argo CD terus memantau definisi aplikasi dan konfigurasi yang sedang berjalan, membandingkan status aktif saat ini pada klaster dengan status yang diinginkan yang ditentukan dalam repositori Git.
Tetapi GitOps bukanlah produk, plugin, atau platform tunggal. Alur kerja GitOps membantu tim mengelola infrastruktur TI melalui proses yang sudah mereka gunakan dalam pengembangan aplikasi. Meminjam dari blog GitLab, GitOps membutuhkan tiga komponen inti: GitOps = IaC + PR atau MR + CI/CD
Operator Red Hat OpenShift menyederhanakan instalasi dan orkestrasi otomatis beban kerja yang kompleks. Operator tersebut membantu mengenkode logika operasional manusia untuk mengelola layanan yang berjalan sebagai aplikasi native Kubernetes, sehingga memudahkan operasi hari ke-2. Operator adalah perangkat lunak yang berjalan di sebuah pod di klaster, yang berinteraksi dengan server API Kubernetes. Operator OpenShift pada dasarnya adalah pengontrol khusus dan pada dasarnya dapat berupa pengontrol khusus untuk masing-masing aplikasi.
Red Hat OpenShift memudahkan pengembang yang ingin menggunakan GitOps dengan menyediakan operator yang diperlukan. Setelah diterapkan, operator tersebut kemudian dapat dilihat di bawah bagian Operator Terinstal di Konsol OpenShift. Operator Red Hat OpenShift GitOps adalah operator hulu untuk ArgoCD, dan operator Red Hat OpenShift Pipelines, yang juga diterapkan, adalah operator hulu untuk Tekton. Lihat Gambar 3:
Operator dan API terkait kemudian dapat digunakan untuk memulai satu atau beberapa pipeline GitOps yang dapat melakukan penerapan ke berbagai lingkungan untuk menarik hasil konfigurasi yang diinginkan dari Git. Lingkungan dapat berupa lingkungan pengembangan, pengujian, dan produksi yang biasa, tetapi juga dapat menjangkau lingkungan geografis seperti cloud perusahaan, jaringan telekomunikasi, atau node komputasi edge.
Sumber daya penerapan diklasifikasikan menjadi tiga bidang: infrastruktur, layanan, dan aplikasi. Area ini memudahkan untuk memisahkan dan mengelola penerapan sumber daya terkait:
Dalam blog sebelumnya, kita membahas DevOps dalam domain komputasi edge; di sini, kita akan melihat bagaimana GitOps dapat diterapkan dalam komputasi edge. Kami menyebutkan tiga edge dalam komputasi edge:
Ada juga cloud atau pusat data perusahaan. Mari kita lihat lebih dalam bidang-bidang ini. Bersamaan dengan lingkungan edge, Gambar 4 juga menggambarkan tiga area GitOps: infrastruktur, layanan, dan aplikasi.
Komputasi edge memantau proliferasi klaster OpenShift atau Kubernetes di sebagian besar pusat TI. Komputasi ini memiliki potensi untuk mencapai skala masif sebanyak ratusan hingga ribuan penerapan per pelanggan. Hasilnya adalah departemen TI perusahaan harus mengelola beberapa klaster waktu proses kontainer independen atau kooperatif yang berjalan on-prem dan/atau di cloud publik.
Memastikan klaster memiliki status yang diinginkan yang sama—meluncurkan perubahan dan mengembalikan ke kondisi sebelum perubahan pada beberapa cloud—adalah manfaat yang diberikan GitOps kepada bisnis berbasis edge dan IoT.
Paradigma GitOps dapat diterapkan di edge jaringan karena salah satu tantangan utama yang dihadapi Penyedia Layanan Komunikasi (CSP) adalah mencari orkestrasi, otomatisasi, dan manajemen jaringan mereka. Meskipun 5G merupakan keuntungan bagi konsumen, jaringan yang ditentukan oleh perangkat lunak (SDN), pemotongan jaringan dengan bandwidth yang berbeda, dan penerapan yang lebih cepat telah menciptakan tantangan bagi penyedia layanan telekomunikasi.
Pipeline penerapan otomatis adalah salah satu cara CSP dapat menghadirkan layanan kepada pelanggan dengan lebih cepat. Memiliki repositori pusat dan pendekatan deklaratif untuk penyediaan infrastruktur kontainer berarti waktu yang lebih cepat untuk memasarkan fitur baru dan permintaan perubahan. Paradigma seperti itu akan membantu penyediaan VNF (Fungsi Jaringan Virtual) dan CNF (Fungsi Jaringan Cloud-Native) di edge jaringan. Kontainerisasi komponen jaringan memungkinkan pengelolaan fungsi-fungsi tersebut. Terakhir, karena semua aktivitas konfigurasi dicatat dan disimpan di Git, kemampuan untuk melacak perubahan sangat penting untuk tujuan kepatuhan dan audit. Ada beberapa blog terkait dari WeaveWorks dalam referensi:
GitOps memungkinkan organisasi untuk menerapkan ke beberapa target secara bersamaan. Hal ini memungkinkan peluncuran penerapan yang terperinci. Ini akan sangat berguna ketika menerapkan aplikasi ke ratusan dan puluhan ribu node edge, yang memiliki berbagai bentuk dan faktor bentuk dan menggunakan protokol komunikasi yang bervariasi—terutama jika node edge adalah klaster kecil menggunakan Intel NUC atau NVIDIA Jetson.
Kerangka kerja GitOps dapat bermanfaat dalam menerapkan aplikasi dan menggunakan repositori Git sebagai sumber kebenaran tunggal. Tim ITOps mencari penerapan aplikasi otonom, manajemen dan operasi node edge, yang difasilitasi dengan penggunaan operator Red Hat OpenShift.
Manfaat GitOps jelas di edge jaringan dan edge perusahaan. Perangkat near edge menghadirkan tantangan yang berbeda karena kapasitas penyimpanan dan komputasi beberapa perangkat ini tidak cukup besar untuk meng-host layanan GitOps dan menjalankan aplikasi.
Rilis distribusi Kubernetes yang ringan, seperti K3s dan K0s, dimaksudkan untuk contoh penggunaan IoT dan edge. Kemampuan untuk menerapkan distribusi Kubernetes yang ringan di perangkat edge memungkinkan kita menjalankan alat GitOps seperti Argo CD. Perangkat kemudian akan dapat mengadopsi model pull saat melakukan polling repositori Git untuk status yang diinginkan dan menyinkronkannya ke status aktif klaster.
Dengan menggunakan GitOps, Anda menyelesaikan masalah infrastruktur dan penyebaran konfigurasi aplikasi. Operator GitOps bawaan di Red Hat OpenShift memudahkan penerapan pipeline berbasis Argo CD. Pelanggan IBM® Cloud Paks, termasuk IBM Cloud Pak for Network Automation, dapat menggunakan operator Red Hat untuk menginstal sumber daya dan menggunakan kerangka kerja GitOps untuk mengotomatiskan dan mengontrol proses penerapan.
IBM Cloud Native Toolkit adalah titik awal yang bagus. Alat ini merupakan kumpulan aset sumber terbuka yang memungkinkan pengembangan aplikasi dan penerapan operasi.
Terima kasih khusus kepada Hollis Chui dan Kavitha Bade untuk meninjau artikel tersebut.