Halaman ini menyediakan titik awal untuk membantu Anda merencanakan dan merancang pipeline CI/CD GitOps untuk Kubernetes. GitOps, bersama dengan alat seperti Config Sync, menawarkan manfaat seperti stabilitas kode yang lebih baik, keterbacaan yang lebih baik, dan otomatisasi.
GitOps adalah pendekatan yang berkembang pesat untuk mengelola konfigurasi Kubernetes dalam skala besar. Bergantung pada persyaratan Anda untuk pipeline CI/CD, ada banyak opsi untuk cara Anda merancang dan mengatur aplikasi dan kode konfigurasi. Dengan mempelajari beberapa praktik terbaik GitOps, Anda dapat membuat arsitektur yang stabil, tertata rapi, dan aman.
Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang ingin menerapkan GitOps di lingkungan mereka. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
Mengelola repositori
Saat menyiapkan arsitektur GitOps, pisahkan repositori berdasarkan jenis file konfigurasi yang disimpan di setiap repositori. Pada tingkat tinggi, Anda dapat mempertimbangkan setidaknya empat jenis repositori:
- Repositori paket untuk grup konfigurasi terkait.
- Repositori platform untuk konfigurasi seluruh armada untuk cluster dan namespace.
- Repositori konfigurasi aplikasi.
- Repositori kode aplikasi.
Diagram berikut menunjukkan tata letak repositori ini:
Pada Gambar 2:
- Tim pengembangan mengirimkan kode untuk aplikasi dan konfigurasi aplikasi ke repositori.
- Kode untuk aplikasi dan konfigurasi disimpan di tempat yang sama dan tim aplikasi memiliki kontrol atas repositori ini.
- Tim aplikasi mengirimkan kode ke dalam build.
Menggunakan repositori paket pribadi terpusat
Gunakan repositori pusat untuk paket publik atau internal, seperti diagram Helm,untuk
membantu tim menemukan paket. Misalnya, jika repositori
terstruktur secara logis atau berisi readme, menggunakan repositori paket
pribadi terpusat dapat membantu tim menemukan informasi dengan cepat. Anda dapat menggunakan layanan seperti
Artifact Registry atau repositori Git untuk mengatur repositori pusat.
Misalnya, tim platform organisasi Anda dapat menerapkan kebijakan yang memungkinkan tim aplikasi menggunakan paket hanya dari repositori pusat.
Anda dapat membatasi izin tulis ke repositori hanya untuk sejumlah kecil engineer. Anggota organisasi lainnya dapat memiliki akses baca. Sebaiknya terapkan proses untuk mempromosikan paket ke repositori pusat dan menyiarkan update.
Meskipun mengelola repositori pusat dapat menambahkan beberapa overhead tambahan karena seseorang harus mengelola repositori pusat, dan menambahkan proses tambahan untuk tim aplikasi, ada banyak manfaat dari pendekatan ini:
- Tim pusat dapat memilih untuk menambahkan paket publik pada ritme yang ditentukan, yang membantu menghindari gangguan akibat konektivitas atau churn upstream.
- Kombinasi peninjau otomatis dan manual dapat memeriksa masalah pada paket sebelum menyediakannya secara luas.
- Repositori pusat menyediakan cara bagi tim untuk menemukan apa yang digunakan dan didukung. Misalnya, tim dapat menemukan deployment Redis standar yang disimpan di repositori pusat.
- Anda dapat mengotomatiskan perubahan pada paket upstream untuk memastikan bahwa paket tersebut memenuhi standar internal seperti nilai default, menambahkan label, dan repositori gambar penampung.
Membuat repositori WET
WET adalah singkatan dari "Write Everything Twice". Hal ini berbeda dengan DRY, yang merupakan singkatan dari "Don't Repeat Yourself". Pendekatan ini mewakili dua jenis file konfigurasi yang berbeda:
- Konfigurasi DRY, dengan satu file konfigurasi yang mengalami tindakan transformasi untuk mengisi kolom dengan nilai yang berbeda untuk lingkungan yang berbeda. Misalnya, Anda dapat memiliki konfigurasi cluster bersama yang diisi dengan region yang berbeda atau setelan keamanan yang berbeda untuk lingkungan yang berbeda.
- Konfigurasi WET (atau terkadang, "fully-hydrated"), dengan setiap file konfigurasi mewakili status akhir.
Meskipun repositori WET dapat menyebabkan beberapa file konfigurasi berulang, repositori ini memiliki manfaat berikut untuk alur kerja GitOps:
- Anggota tim akan lebih mudah meninjau perubahan.
- Tidak ada pemrosesan yang diperlukan untuk melihat status file konfigurasi yang diinginkan.
Menguji lebih awal saat memvalidasi konfigurasi
Menunggu hingga Config Sync mulai menyinkronkan untuk memeriksa masalah dapat membuat commit Git yang tidak perlu dan loop masukan yang lama. Banyak masalah dapat ditemukan
sebelum konfigurasi diterapkan ke cluster menggunakan fungsi validator kpt.
Meskipun Anda harus menambahkan alat dan logika tambahan ke proses commit, pengujian sebelum menerapkan konfigurasi memiliki manfaat berikut:
- Menampilkan perubahan konfigurasi dalam permintaan perubahan dapat membantu mencegah error menjadi repositori.
- Mengurangi dampak masalah dalam konfigurasi bersama.
Menggunakan folder, bukan cabang
Gunakan folder untuk varian file konfigurasi, bukan cabang. Dengan
folder, Anda dapat menggunakan perintah tree untuk melihat varian. Dengan cabang, Anda
tidak dapat mengetahui apakah delta antara cabang produksi dan pengembangan adalah
perubahan konfigurasi mendatang atau perbedaan permanen antara tampilan
lingkungan prod dan dev.
Kelemahan utama pendekatan ini adalah penggunaan folder tidak memungkinkan Anda mempromosikan perubahan konfigurasi menggunakan permintaan perubahan ke file yang sama. Namun, menggunakan folder bukan cabang memiliki manfaat berikut:
- Penemuan folder lebih mudah daripada cabang.
- Anda dapat melakukan diff pada folder dengan banyak alat CLI dan GUI, sedangkan diff cabang kurang umum di luar penyedia Git.
- Membedakan antara perbedaan permanen dan perbedaan yang tidak dipromosikan akan lebih mudah dengan folder.
- Anda dapat men-deploy perubahan ke beberapa cluster dan namespace dalam satu permintaan perubahan, sedangkan cabang memerlukan beberapa permintaan perubahan ke cabang yang berbeda.
Meminimalkan penggunaan ClusterSelectors
ClusterSelectors memungkinkan Anda menerapkan bagian tertentu dari konfigurasi ke subkumpulan cluster. Alih-alih mengonfigurasi objek RootSync atau RepoSync,
Anda dapat mengubah resource yang diterapkan atau menambahkan label
ke cluster. Meskipun ini adalah cara ringan untuk menambahkan atribut ke cluster,
karena jumlah ClusterSelectors bertambah seiring waktu, akan menjadi rumit
untuk memahami status akhir cluster.
Karena Config Sync memungkinkan Anda menyinkronkan beberapa objek RootSync dan RepoSync sekaligus, Anda dapat menambahkan konfigurasi yang relevan ke repositori terpisah, lalu menyinkronkannya ke cluster yang diinginkan. Hal ini memudahkan untuk memahami
status akhir cluster dan Anda dapat menyusun konfigurasi untuk
cluster ke dalam folder, bukan menerapkan keputusan konfigurasi tersebut langsung
di cluster.
Menghindari pengelolaan Tugas dengan Config Sync
Pada umumnya, Tugas dan tugas situasional lainnya harus dikelola oleh layanan yang menangani pengelolaan siklus prosesnya. Kemudian, Anda dapat mengelola layanan tersebut dengan Config Sync, bukan Tugas itu sendiri.
Meskipun Config Sync dapat menerapkan Tugas untuk Anda, Tugas tidak cocok untuk deployment GitOps karena alasan berikut:
Kolom yang tidak dapat diubah: Banyak kolom Lowongan yang tidak dapat diubah. Untuk mengubah kolom yang tidak dapat diubah, objek harus dihapus dan dibuat ulang. Namun, Config Sync tidak menghapus objek Anda kecuali jika Anda menghapusnya dari sumber.
Pemrosesan Tugas yang tidak disengaja: Jika Anda menyinkronkan Tugas dengan Config Sync, lalu Tugas tersebut dihapus dari cluster, Config Sync akan menganggapnya sebagai penyimpangan dari status yang Anda pilih dan membuat ulang Tugas. Jika Anda menentukan Time to live (TTL) Tugas, Config Sync akan otomatis menghapus Tugas dan otomatis membuat ulang dan memulai ulang Tugas, hingga Anda menghapus Tugas dari sumber tepercaya.
Masalah rekonsiliasi: Sinkronisasi Konfigurasi biasanya menunggu objek direkonsiliasi setelah diterapkan. Namun, Tugas dianggap telah direkonsiliasi saat mulai berjalan. Artinya, Config Sync tidak menunggu Tugas selesai sebelum melanjutkan penerapan objek lainnya. Namun, jika Tugas gagal di lain waktu, hal tersebut dianggap sebagai kegagalan untuk merekonsiliasi. Dalam beberapa kasus, hal ini dapat memblokir resource lain agar tidak disinkronkan dan menyebabkan error hingga Anda memperbaikinya. Dalam kasus lain, sinkronisasi mungkin berhasil dan hanya rekonsiliasi yang gagal.
Karena alasan ini, sebaiknya jangan menyinkronkan Tugas dengan Config Sync.
Menggunakan repositori tidak terstruktur
Config Sync mendukung dua struktur untuk mengatur repositori: tidak terstruktur dan hierarkis.
Pendekatan tidak terstruktur direkomendasikan karena
memungkinkan Anda mengatur repositori dengan cara yang paling nyaman bagi Anda.
Sebagai perbandingan, repositori hierarkis menerapkan struktur tertentu seperti
Custom Resource Definition (CRD) dalam direktori cluster.
Hal ini dapat menyebabkan masalah saat Anda perlu membagikan konfigurasi. Misalnya, jika satu tim memublikasikan paket yang berisi CRD, tim lain yang perlu menggunakan paket tersebut harus memindahkan CRD ke direktori cluster, sehingga menambah overhead pada proses.
Dengan menggunakan repositori tak terstruktur, akan jauh lebih mudah untuk membagikan dan menggunakan kembali paket konfigurasi. Namun, tanpa proses atau pedoman yang ditentukan untuk mengatur repositori, struktur repositori dapat bervariasi di seluruh tim, yang dapat mempersulit penerapan alat di seluruh fleet.
Untuk mempelajari cara mengonversi repositori hierarkis, lihat Mengonversi repositori hierarkis ke repositori tidak terstruktur.
Memisahkan repositori kode dan konfigurasi
Saat menskalakan repositori mono, Anda memerlukan build khusus untuk setiap folder. Izin dan masalah untuk orang yang mengerjakan kode dan mengerjakan konfigurasi cluster umumnya berbeda.
Memisahkan repositori kode dan konfigurasi memiliki manfaat berikut:
- Menghindari commit "looping". Misalnya, melakukan commit ke repositori kode dapat memicu permintaan CI, yang dapat menghasilkan image, yang kemudian memerlukan commit kode.
- Jumlah commit yang diperlukan dapat menjadi beban bagi anggota tim yang berkontribusi.
- Anda dapat menggunakan izin yang berbeda untuk orang yang mengerjakan kode aplikasi dan konfigurasi cluster.
Memisahkan repositori kode dan konfigurasi memiliki kelemahan berikut:
- Mengurangi penemuan untuk konfigurasi aplikasi karena tidak berada di repositori yang sama dengan kode aplikasi.
- Mengelola banyak repositori dapat menghabiskan banyak waktu.
Menggunakan repositori terpisah untuk mengisolasi perubahan
Saat menskalakan repositori mono, izin yang berbeda diperlukan di folder yang berbeda. Oleh karena itu, pemisahan repositori memungkinkan batas keamanan antara konfigurasi keamanan, platform, dan aplikasi. Sebaiknya pisahkan repositori produksi dan non-produksi.
Meskipun mengelola banyak repositori dapat menjadi tugas yang besar, mengisolasi berbagai jenis konfigurasi di repositori yang berbeda memiliki manfaat berikut:
- Dalam organisasi dengan tim platform, keamanan, dan aplikasi, ritme perubahan dan izin berbeda.
- Izin tetap berada di tingkat repositori. File
CODEOWNERSmemungkinkan organisasi membatasi izin tulis sekaligus tetap mengizinkan izin baca. - Config Sync mendukung beberapa sinkronisasi per namespace yang dapat memberikan efek serupa seperti mengambil file dari beberapa repositori.
Menyematkan versi paket
Baik menggunakan Helm maupun Git, Anda harus menyematkan versi paket konfigurasi ke sesuatu yang tidak akan dipindahkan secara tidak sengaja tanpa peluncuran eksplisit.
Meskipun hal ini menambahkan pemeriksaan tambahan ke peluncuran Anda saat konfigurasi bersama diperbarui, tindakan ini mengurangi risiko pembaruan bersama yang memiliki dampak lebih besar dari yang diinginkan.
Menggunakan Workload Identity Federation untuk GKE
Anda dapat mengaktifkan Workload Identity Federation untuk GKE di cluster GKE, yang memungkinkan workload Kubernetes mengakses layanan Google dengan cara yang aman dan mudah dikelola.
Meskipun beberapa layanan non-Google Cloud, seperti GitHub dan GitLab, tidak mendukung Workload Identity Federation untuk GKE, Anda harus mencoba menggunakan Workload Identity Federation untuk GKE jika memungkinkan karena peningkatan keamanan dan pengurangan kompleksitas pengelolaan secret dan sandi.