GitOps: Perbandingan Metode Tarik dan Dorong

Catatan. terjemahan: Di komunitas Kubernetes, tren yang disebut GitOps semakin populer, seperti yang telah kita lihat secara pribadi, mengunjungi KubeCon Europe 2019. Istilah ini relatif baru ditemukan oleh kepala Weaveworks - Alexis Richardson - dan berarti penggunaan alat yang familiar bagi pengembang (terutama Git, karena itulah namanya) untuk memecahkan masalah operasional. Secara khusus, kita berbicara tentang pengoperasian Kubernetes dengan menyimpan konfigurasinya di Git dan secara otomatis meluncurkan perubahan pada cluster. Matthias Jg membahas dua pendekatan terhadap peluncuran ini dalam artikel ini.

Tahun lalu, (sebenarnya, secara resmi ini terjadi pada Agustus 2017 - kira-kira terjemahan) Ada pendekatan baru untuk menerapkan aplikasi di Kubernetes. Ini disebut GitOps, dan didasarkan pada gagasan dasar bahwa versi penerapan dilacak di lingkungan aman repositori Git.

Keuntungan utama dari pendekatan ini adalah sebagai berikut::

1. Versi penerapan dan riwayat perubahan. Status seluruh klaster disimpan dalam repositori Git, dan penerapan diperbarui hanya melalui penerapan. Selain itu, semua perubahan dapat dilacak menggunakan riwayat penerapan.
2. Rollback menggunakan perintah Git yang familiar. Sederhana git reset memungkinkan Anda mengatur ulang perubahan dalam penerapan; negara bagian sebelumnya selalu tersedia.
3. Kontrol akses siap. Biasanya, sistem Git berisi banyak data sensitif, sehingga sebagian besar perusahaan memberikan perhatian khusus untuk melindunginya. Oleh karena itu, perlindungan ini juga berlaku untuk operasi dengan penerapan.
4. Kebijakan untuk Penerapan. Sebagian besar sistem Git secara asli mendukung kebijakan cabang demi cabang—misalnya, hanya permintaan penarikan yang dapat memperbarui master, dan perubahan harus ditinjau dan diterima oleh anggota tim lainnya. Seperti halnya kontrol akses, kebijakan yang sama berlaku untuk pembaruan penerapan.

Seperti yang Anda lihat, ada banyak manfaat dari metode GitOps. Selama setahun terakhir, ada dua pendekatan yang mendapatkan popularitas tertentu. Yang satu berbasis dorong, yang lain berbasis tarik. Sebelum kita membahasnya, mari kita lihat dulu seperti apa penerapan Kubernetes pada umumnya.

Metode Penerapan

Dalam beberapa tahun terakhir, berbagai metode dan alat penerapan telah diterapkan di Kubernetes:

1. Berdasarkan template Kubernetes/Kustomize asli. Ini adalah cara termudah untuk menerapkan aplikasi di Kubernetes. Pengembang membuat file YAML dasar dan menerapkannya. Untuk menghindari penulisan ulang template yang sama secara terus-menerus, Kustomize dikembangkan (mengubah template Kubernetes menjadi modul). Catatan. terjemahan: Kustomize telah diintegrasikan ke dalam kubectl dengan rilis Kubernetes 1.14.
2. Bagan Helm. Bagan helm memungkinkan Anda membuat kumpulan templat, wadah init, sidecar, dll., yang digunakan untuk menyebarkan aplikasi dengan opsi penyesuaian yang lebih fleksibel dibandingkan dengan pendekatan berbasis templat. Metode ini didasarkan pada file YAML yang diberi template. Helm mengisinya dengan berbagai parameter dan kemudian mengirimkannya ke Tiller, komponen cluster yang menyebarkannya ke cluster dan memungkinkan pembaruan dan rollback. Yang penting adalah Helm pada dasarnya hanya memasukkan nilai yang diinginkan ke dalam templat dan kemudian menerapkannya dengan cara yang sama seperti yang dilakukan pada pendekatan tradisional. (baca lebih lanjut tentang cara kerjanya dan bagaimana Anda dapat menggunakannya di kami artikel oleh Helm - kira-kira. terjemahkan). Ada berbagai macam bagan Helm siap pakai yang mencakup berbagai tugas.
3. Alat Alternatif. Ada banyak alat alternatif. Kesamaan dari semuanya adalah mereka mengubah beberapa file template menjadi file YAML yang dapat dibaca Kubernetes dan kemudian menggunakannya.

Dalam pekerjaan kami, kami terus-menerus menggunakan diagram Helm untuk alat-alat penting (karena mereka sudah menyiapkan banyak hal, yang membuat hidup lebih mudah) dan file YAML Kubernetes “murni” untuk menerapkan aplikasi kami sendiri.

Tarik dorong

Di salah satu postingan blog terbaru saya, saya memperkenalkan alat tersebut Fluks Tenun, yang memungkinkan Anda mengkomit templat ke repositori Git dan memperbarui penerapan setelah setiap penerapan atau push kontainer. Pengalaman saya menunjukkan bahwa alat ini adalah salah satu alat utama dalam mempromosikan pendekatan tarik, jadi saya akan sering merujuknya. Jika Anda ingin tahu lebih banyak tentang cara menggunakannya, di sini tautan ke artikel.

NB! Semua manfaat menggunakan GitOps tetap sama untuk kedua pendekatan tersebut.

Pendekatan berbasis tarik

Pendekatan tarik didasarkan pada kenyataan bahwa semua perubahan diterapkan dari dalam cluster. Ada operator di dalam cluster yang secara teratur memeriksa repositori Git dan Docker Registry terkait. Jika ada perubahan yang terjadi pada cluster tersebut, status cluster akan diperbarui secara internal. Proses ini umumnya dianggap sangat aman, karena tidak ada klien eksternal yang memiliki akses ke hak administrator cluster.

Pro:

1. Tidak ada klien eksternal yang mempunyai hak untuk membuat perubahan pada cluster; semua pembaruan diluncurkan dari dalam.
2. Beberapa alat juga memungkinkan Anda menyinkronkan pembaruan bagan Helm dan menautkannya ke klaster.
3. Docker Registry dapat dipindai untuk versi baru. Jika image baru tersedia, repositori dan penerapan Git diperbarui ke versi baru.
4. Alat tarik dapat didistribusikan ke namespace berbeda dengan repositori dan izin Git berbeda. Berkat ini, model multi-penyewa dapat digunakan. Misalnya, tim A mungkin menggunakan namespace A, tim B mungkin menggunakan namespace B, dan tim infrastruktur mungkin menggunakan ruang global.
5. Biasanya, alatnya sangat ringan.
6. Dikombinasikan dengan alat seperti operator Rahasia Tersegel Bitnami, rahasia dapat disimpan terenkripsi dalam repositori Git dan diambil dalam cluster.
7. Tidak ada koneksi ke saluran CD karena penerapan terjadi di dalam kluster.

Kontra:

1. Mengelola rahasia penerapan dari diagram Helm lebih sulit daripada yang biasa, karena rahasia tersebut harus dibuat terlebih dahulu dalam bentuk, katakanlah, rahasia tersegel, kemudian didekripsi oleh operator internal, dan baru setelah itu rahasia tersebut tersedia untuk alat penarik. Kemudian Anda dapat menjalankan rilis di Helm dengan nilai-nilai dalam rahasia yang sudah diterapkan. Cara termudah adalah dengan membuat rahasia dengan semua nilai Helm yang digunakan untuk penerapan, mendekripsinya, dan mengkomitnya ke Git.
2. Saat Anda melakukan pendekatan tarik, Anda menjadi terikat pada alat penarik. Hal ini membatasi kemampuan untuk menyesuaikan proses penerapan dalam sebuah cluster. Misalnya, Kustomize menjadi rumit karena harus dijalankan sebelum templat akhir dikomit ke Git. Saya tidak mengatakan Anda tidak dapat menggunakan alat yang berdiri sendiri, namun alat tersebut lebih sulit untuk diintegrasikan ke dalam proses penerapan Anda.

Pendekatan berbasis dorong

Dalam pendekatan push, sistem eksternal (terutama pipeline CD) meluncurkan penerapan ke cluster setelah penerapan ke repositori Git atau jika pipeline CI sebelumnya berhasil. Dalam pendekatan ini, sistem memiliki akses ke cluster.

Kelebihan::

1. Keamanan ditentukan oleh repositori Git dan pipeline build.
2. Menerapkan grafik Helm lebih mudah dan mendukung plugin Helm.
3. Rahasia lebih mudah dikelola karena rahasia dapat digunakan dalam pipeline dan juga dapat disimpan terenkripsi di Git (tergantung preferensi pengguna).
4. Tidak ada koneksi ke alat tertentu, karena jenis apa pun dapat digunakan.
5. Pembaruan versi kontainer dapat dimulai oleh alur build.

Kontra:

1. Data akses cluster ada di dalam sistem build.
2. Memperbarui kontainer penerapan masih lebih mudah dengan proses tarik.
3. Ketergantungan yang besar pada sistem CD, karena pipeline yang kami butuhkan mungkin awalnya ditulis untuk Gitlab Runners, lalu tim memutuskan untuk pindah ke Azure DevOps atau Jenkins... dan harus memigrasikan sejumlah besar build pipeline.

Hasil: Dorong atau Tarik?

Seperti yang biasanya terjadi, setiap pendekatan mempunyai pro dan kontra. Beberapa tugas lebih mudah diselesaikan dengan satu tugas dan lebih sulit dengan tugas lainnya. Awalnya saya melakukan penerapan secara manual, tetapi setelah saya menemukan beberapa artikel tentang Weave Flux, saya memutuskan untuk mengimplementasikan proses GitOps untuk semua proyek. Untuk template dasar, ini mudah, tapi kemudian saya mulai mengalami kesulitan dengan grafik Helm. Pada saat itu, Weave Flux hanya menawarkan versi dasar dari Helm Chart Operator, tetapi bahkan sekarang beberapa tugas menjadi lebih sulit karena kebutuhan untuk membuat rahasia secara manual dan menerapkannya. Anda dapat berargumentasi bahwa pendekatan tarikan jauh lebih aman karena kredensial klaster tidak dapat diakses di luar klaster, sehingga membuatnya jauh lebih aman dan sepadan dengan upaya ekstra yang dilakukan.

Setelah beberapa pemikiran, saya sampai pada kesimpulan yang tidak terduga bahwa ini tidak benar. Jika kita berbicara tentang komponen yang memerlukan perlindungan maksimal, daftar ini akan mencakup penyimpanan rahasia, sistem CI/CD, dan repositori Git. Informasi di dalamnya sangat rentan dan membutuhkan perlindungan maksimal. Selain itu, jika seseorang masuk ke repositori Git Anda dan dapat memasukkan kode ke sana, mereka dapat menerapkan apa pun yang mereka inginkan (baik itu tarik atau dorong) dan menyusup ke sistem cluster. Oleh karena itu, komponen terpenting yang perlu dilindungi adalah repositori Git dan sistem CI/CD, bukan kredensial cluster. Jika Anda memiliki kebijakan dan kontrol keamanan yang terkonfigurasi dengan baik untuk jenis sistem ini, dan kredensial klaster hanya diekstraksi ke dalam pipeline sebagai rahasia, keamanan tambahan dari pendekatan pull mungkin tidak seberharga yang diperkirakan sebelumnya.

Jadi, jika pendekatan tarik lebih padat karya dan tidak memberikan manfaat keamanan, bukankah logis jika hanya menggunakan pendekatan dorong? Namun seseorang mungkin berpendapat bahwa dalam pendekatan push Anda terlalu terikat dengan sistem CD dan, mungkin, lebih baik tidak melakukan hal ini agar lebih mudah untuk melakukan migrasi di masa mendatang.

Menurut pendapat saya (seperti biasa), Anda harus menggunakan apa yang paling cocok untuk kasus atau kombinasi tertentu. Secara pribadi, saya menggunakan kedua pendekatan: Weave Flux untuk penerapan berbasis tarik yang sebagian besar mencakup layanan kami sendiri, dan pendekatan push dengan Helm dan plugin, yang memudahkan penerapan diagram Helm ke cluster dan memungkinkan Anda membuat rahasia dengan mulus. Saya rasa tidak akan pernah ada satu solusi yang cocok untuk semua kasus, karena selalu ada banyak perbedaan dan bergantung pada aplikasi spesifik. Oleh karena itu, saya sangat merekomendasikan GitOps - ini membuat hidup lebih mudah dan meningkatkan keamanan.

Saya harap pengalaman saya tentang topik ini akan membantu Anda memutuskan metode mana yang lebih cocok untuk jenis penerapan Anda, dan saya akan senang mendengar pendapat Anda.

PS Catatan dari penerjemah

Kelemahan dari model tarik adalah sulitnya memasukkan manifes yang dirender ke dalam Git, namun tidak ada kerugiannya karena pipa CD dalam model tarik hidup terpisah dari peluncuran dan pada dasarnya menjadi pipa kategori Penerapan Berkelanjutan. Oleh karena itu, diperlukan lebih banyak upaya untuk mengumpulkan status mereka dari semua penerapan dan menyediakan akses ke log/status, sebaiknya dengan referensi ke sistem CD.

Dalam hal ini, model push memungkinkan kita untuk memberikan setidaknya beberapa jaminan peluncuran, karena umur pipeline dapat dibuat sama dengan umur peluncuran.

Kami mencoba kedua model tersebut dan sampai pada kesimpulan yang sama seperti penulis artikel:

1. Model tarik cocok bagi kita untuk mengatur pembaruan komponen sistem pada sejumlah besar cluster (lihat. artikel tentang addon-operator).
2. Model push berdasarkan GitLab CI sangat cocok untuk meluncurkan aplikasi menggunakan grafik Helm. Pada saat yang sama, peluncuran penerapan dalam jaringan pipa dipantau menggunakan alat ini wer. Ngomong-ngomong, dalam konteks proyek kami ini, kami mendengar “GitOps” yang konstan ketika kami mendiskusikan masalah mendesak para insinyur DevOps di stand kami di KubeCon Europe'19.

PPS dari penerjemah

Baca juga di blog kami:

• «Tip & trik Kubernetes: mentransfer sumber daya yang berjalan di cluster ke manajemen Helm 2»;
• «Memperkenalkan kubedog, perpustakaan untuk melacak sumber daya Kubernetes»;
• «Memperluas dan melengkapi Kubernetes (review dan laporan video)»;
• «Tips untuk membuat alur kerja khusus di GitLab CI'.

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Apakah Anda menggunakan GitOps?

• Ya, pendekatan tarik

• Ya, dorong

• Ya, tarik + dorong

• Ya, sesuatu yang lain

• Tidak

30 pengguna memilih. 10 pengguna abstain.

Sumber: www.habr.com