GitOps: Perbandingan Kaedah Tarik dan Tolak

Catatan. terjemah: Dalam komuniti Kubernetes, trend yang dipanggil GitOps semakin popular, seperti yang kita lihat secara peribadi, melawat KubeCon Europe 2019. Istilah ini agak baru dicipta oleh ketua Weaveworks - Alexis Richardson - dan bermaksud penggunaan alat yang biasa digunakan oleh pembangun (terutamanya Git, oleh itu namanya) untuk menyelesaikan masalah operasi. Khususnya, kita bercakap tentang pengendalian Kubernetes dengan menyimpan konfigurasinya dalam Git dan secara automatik melancarkan perubahan kepada kluster. Matthias Jg bercakap tentang dua pendekatan untuk pelancaran ini dalam artikel ini.

Tahun lepas, (malah, secara rasmi perkara ini berlaku pada Ogos 2017 - lebih kurang transl.) Terdapat pendekatan baharu untuk menggunakan aplikasi dalam Kubernetes. Ia dipanggil GitOps, dan ia berdasarkan idea asas bahawa versi penggunaan dijejaki dalam persekitaran selamat repositori Git.

Kelebihan utama pendekatan ini adalah seperti berikut::

1. Penyebaran versi dan sejarah perubahan. Keadaan keseluruhan kluster disimpan dalam repositori Git, dan penempatan hanya dikemas kini melalui komit. Selain itu, semua perubahan boleh dijejaki menggunakan sejarah komit.
2. Rollback menggunakan arahan Git yang biasa... Kosong git reset membolehkan anda menetapkan semula perubahan dalam penempatan; negeri lepas sentiasa tersedia.
3. Kawalan akses sedia. Biasanya, sistem Git mengandungi banyak data sensitif, jadi kebanyakan syarikat memberi perhatian khusus untuk melindunginya. Sehubungan itu, perlindungan ini juga terpakai pada operasi dengan penempatan.
4. Dasar untuk Kerahan. Kebanyakan sistem Git secara asli menyokong dasar cawangan demi cawangan—contohnya, hanya permintaan tarik boleh mengemas kini induk dan perubahan mesti disemak dan diterima oleh ahli pasukan yang lain. Seperti kawalan akses, dasar yang sama digunakan untuk kemas kini penggunaan.

Seperti yang anda lihat, terdapat banyak faedah kepada kaedah GitOps. Sepanjang tahun lalu, dua pendekatan telah mendapat populariti tertentu. Satu berasaskan tolak, satu lagi berasaskan tarikan. Sebelum kita melihatnya, mari kita lihat dahulu rupa penggunaan Kubernetes yang biasa.

Kaedah Penggunaan

Dalam beberapa tahun kebelakangan ini, pelbagai kaedah dan alatan untuk penempatan telah diwujudkan di Kubernetes:

1. Berdasarkan templat Kubernetes/Kustomize asli. Ini ialah cara paling mudah untuk menggunakan aplikasi pada Kubernetes. Pembangun mencipta fail YAML asas dan menggunakannya. Untuk menghapuskan penulisan semula templat yang sama secara berterusan, Kustomize telah dibangunkan (ia menjadikan templat Kubernetes menjadi modul). Catatan. terjemah: Kustomize telah disepadukan ke dalam kubectl dengan keluaran Kubernetes 1.14.
2. Carta Helm. Carta helm membolehkan anda membuat set templat, bekas init, sidecar, dsb., yang digunakan untuk menggunakan aplikasi dengan pilihan penyesuaian yang lebih fleksibel berbanding pendekatan berasaskan templat. Kaedah ini adalah berdasarkan fail YAML templat. Helm mengisinya dengan pelbagai parameter dan kemudian menghantarnya ke Tiller, komponen kluster yang mengerahkannya ke kluster dan membenarkan kemas kini dan rollback. Yang penting ialah Helm pada dasarnya hanya memasukkan nilai yang dikehendaki ke dalam templat dan kemudian menerapkannya dengan cara yang sama seperti yang dilakukan dalam pendekatan tradisional (baca lebih lanjut tentang cara semuanya berfungsi dan cara anda boleh menggunakannya dalam kami artikel oleh Helm - lebih kurang terjemah.). Terdapat pelbagai jenis carta Helm siap sedia merangkumi pelbagai tugas.
3. Alat Alternatif. Terdapat banyak alat alternatif. Apa yang mereka semua mempunyai persamaan ialah mereka menukar beberapa fail templat menjadi fail YAML yang boleh dibaca Kubernetes dan kemudian menggunakannya.

Dalam kerja kami, kami sentiasa menggunakan carta Helm untuk alatan penting (kerana ia mempunyai banyak perkara yang sudah sedia, yang menjadikan hidup lebih mudah) dan fail YAML Kubernetes "tulen" untuk menggunakan aplikasi kami sendiri.

Tarik tolak

Dalam salah satu catatan blog saya baru-baru ini, saya memperkenalkan alat tersebut Tenunan Fluks, yang membolehkan anda memasukkan templat ke repositori Git dan mengemas kini penggunaan selepas setiap komit atau tolak bekas. Pengalaman saya menunjukkan bahawa alat ini adalah salah satu yang utama dalam mempromosikan pendekatan tarik, jadi saya akan sering merujuknya. Jika anda ingin mengetahui lebih lanjut tentang cara menggunakannya, di sini pautan ke artikel.

NB! Semua faedah menggunakan GitOps kekal sama untuk kedua-dua pendekatan.

Pendekatan berasaskan tarik

Pendekatan tarik adalah berdasarkan fakta bahawa semua perubahan digunakan dari dalam kelompok. Terdapat pengendali di dalam kluster yang kerap menyemak repositori Git dan Docker Registry yang berkaitan. Jika sebarang perubahan berlaku kepada mereka, keadaan kluster dikemas kini secara dalaman. Proses ini secara amnya dianggap sangat selamat, kerana tiada pelanggan luaran mempunyai akses kepada hak pentadbir kelompok.

Kelebihan:

1. Tiada pelanggan luaran mempunyai hak untuk membuat perubahan pada kluster; semua kemas kini dilancarkan dari dalam.
2. Sesetengah alatan juga membenarkan anda menyegerakkan kemas kini carta Helm dan memautkannya ke gugusan.
3. Docker Registry boleh diimbas untuk versi baharu. Jika imej baharu tersedia, repositori dan penggunaan Git dikemas kini kepada versi baharu.
4. Alat Tarik boleh diedarkan merentasi ruang nama yang berbeza dengan repositori dan kebenaran Git yang berbeza. Terima kasih kepada ini, model multitenant boleh digunakan. Sebagai contoh, pasukan A mungkin menggunakan ruang nama A, pasukan B mungkin menggunakan ruang nama B dan pasukan infrastruktur mungkin menggunakan ruang global.
5. Sebagai peraturan, alat itu sangat ringan.
6. Digabungkan dengan alatan seperti operator Rahsia Termeterai Bitnami, rahsia boleh disimpan disulitkan dalam repositori Git dan diambil dalam kelompok.
7. Tiada sambungan ke saluran paip CD sejak penempatan berlaku dalam kelompok.

Kekurangan:

1. Menguruskan rahsia penggunaan daripada carta Helm adalah lebih sukar daripada yang biasa, kerana ia mula-mula perlu dijana dalam bentuk, katakan, rahsia yang dimeterai, kemudian dinyahsulit oleh pengendali dalaman, dan hanya selepas itu ia tersedia untuk alat tarik. Kemudian anda boleh menjalankan keluaran dalam Helm dengan nilai dalam rahsia yang telah digunakan. Cara paling mudah ialah mencipta rahsia dengan semua nilai Helm yang digunakan untuk penempatan, menyahsulitnya dan menyerahkannya kepada Git.
2. Apabila anda mengambil pendekatan tarik, anda akan terikat dengan alat tarik. Ini mengehadkan keupayaan untuk menyesuaikan proses penggunaan dalam kelompok. Sebagai contoh, Kustomize adalah rumit oleh fakta bahawa ia mesti dijalankan sebelum templat akhir diberikan kepada Git. Saya tidak mengatakan anda tidak boleh menggunakan alat kendiri, tetapi ia lebih sukar untuk disepadukan ke dalam proses penggunaan anda.

Pendekatan berasaskan tolak

Dalam pendekatan tolak, sistem luaran (terutamanya saluran paip CD) melancarkan penggunaan ke kluster selepas komit ke repositori Git atau jika saluran paip CI sebelumnya berjaya. Dalam pendekatan ini, sistem mempunyai akses kepada kluster.

Kelebihan:

1. Keselamatan ditentukan oleh repositori Git dan membina saluran paip.
2. Menggunakan carta Helm adalah lebih mudah dan menyokong pemalam Helm.
3. Rahsia lebih mudah diurus kerana rahsia boleh digunakan dalam saluran paip dan juga boleh disimpan disulitkan dalam Git (bergantung pada pilihan pengguna).
4. Tiada sambungan kepada alat tertentu, kerana sebarang jenis boleh digunakan.
5. Kemas kini versi bekas boleh dimulakan oleh saluran paip binaan.

Kekurangan:

1. Data akses kluster berada di dalam sistem binaan.
2. Mengemas kini bekas penggunaan masih lebih mudah dengan proses tarik.
3. Pergantungan berat pada sistem CD, memandangkan saluran paip yang kami perlukan mungkin pada asalnya ditulis untuk Gitlab Runners, dan kemudian pasukan memutuskan untuk berpindah ke Azure DevOps atau Jenkins... dan perlu memindahkan sejumlah besar saluran paip binaan.

Keputusan: Tolak atau Tarik?

Seperti biasa, setiap pendekatan mempunyai kebaikan dan keburukan. Sesetengah tugas lebih mudah untuk diselesaikan dengan satu dan lebih sukar dengan yang lain. Pada mulanya saya melakukan penempatan secara manual, tetapi selepas saya menemui beberapa artikel tentang Weave Flux, saya memutuskan untuk melaksanakan proses GitOps untuk semua projek. Untuk templat asas ini adalah mudah, tetapi kemudian saya mula menghadapi kesukaran dengan carta Helm. Pada masa itu, Weave Flux hanya menawarkan versi asas Operator Carta Helm, tetapi kini beberapa tugas lebih sukar kerana keperluan untuk mencipta rahsia secara manual dan menggunakannya. Anda boleh berhujah bahawa pendekatan tarik adalah lebih selamat kerana bukti kelayakan kluster tidak boleh diakses di luar kluster, menjadikannya lebih selamat sehingga ia berbaloi dengan usaha tambahan.

Selepas beberapa pemikiran, saya sampai pada kesimpulan yang tidak dijangka bahawa ini tidak begitu. Jika kita bercakap tentang komponen yang memerlukan perlindungan maksimum, senarai ini akan termasuk storan rahsia, sistem CI/CD dan repositori Git. Maklumat di dalamnya sangat terdedah dan memerlukan perlindungan maksimum. Selain itu, jika seseorang masuk ke repositori Git anda dan boleh menolak kod di sana, mereka boleh menggunakan apa sahaja yang mereka mahu (sama ada tarik atau tolak) dan menyusup ke sistem kluster. Oleh itu, komponen paling penting yang perlu dilindungi ialah repositori Git dan sistem CI/CD, bukan kelayakan kluster. Jika anda mempunyai dasar dan kawalan keselamatan yang dikonfigurasikan dengan baik untuk jenis sistem ini, dan bukti kelayakan kelompok hanya diekstrak ke dalam saluran paip sebagai rahsia, keselamatan tambahan pendekatan tarik mungkin tidak bernilai seperti yang difikirkan pada asalnya.

Jadi, jika pendekatan tarik lebih intensif buruh dan tidak memberikan faedah keselamatan, bukankah logik untuk menggunakan pendekatan tolak sahaja? Tetapi seseorang mungkin berpendapat bahawa dalam pendekatan push anda terlalu terikat dengan sistem CD dan, mungkin, lebih baik tidak melakukan ini supaya lebih mudah untuk melakukan migrasi pada masa akan datang.

Pada pendapat saya (seperti biasa), anda harus menggunakan apa yang paling sesuai untuk kes tertentu atau gabungan. Secara peribadi, saya menggunakan kedua-dua pendekatan: Weave Flux untuk penempatan berasaskan tarik yang kebanyakannya merangkumi perkhidmatan kami sendiri, dan pendekatan tolak dengan Helm dan pemalam, yang memudahkan anda menggunakan carta Helm pada gugusan dan membolehkan anda mencipta rahsia dengan lancar. Saya fikir tidak akan ada penyelesaian tunggal yang sesuai untuk semua kes, kerana sentiasa ada banyak nuansa dan ia bergantung pada aplikasi tertentu. Walaupun begitu, saya sangat mengesyorkan GitOps - ia menjadikan hidup lebih mudah dan meningkatkan keselamatan.

Saya harap pengalaman saya tentang topik ini akan membantu anda memutuskan kaedah yang lebih sesuai untuk jenis penggunaan anda, dan saya berbesar hati untuk mendengar pendapat anda.

Nota PS daripada penterjemah

Kelemahan model tarik ialah sukar untuk meletakkan manifes yang diberikan ke dalam Git, tetapi tidak ada kelemahan bahawa saluran paip CD dalam model tarik hidup secara berasingan daripada pelancaran dan pada asasnya menjadi saluran paip kategori Memohon Berterusan. Oleh itu, lebih banyak usaha akan diperlukan untuk mengumpul status mereka daripada semua penempatan dan entah bagaimana menyediakan akses kepada log/status, sebaik-baiknya dengan merujuk kepada sistem CD.

Dalam pengertian ini, model tolak membolehkan kami memberikan sekurang-kurangnya beberapa jaminan pelancaran, kerana jangka hayat saluran paip boleh dibuat sama dengan jangka hayat pelancaran.

Kami mencuba kedua-dua model dan membuat kesimpulan yang sama seperti pengarang artikel:

1. Model tarik sesuai untuk kami mengatur kemas kini komponen sistem pada sejumlah besar kelompok (lihat. artikel tentang addon-operator).
2. Model tolak berdasarkan GitLab CI sangat sesuai untuk melancarkan aplikasi menggunakan carta Helm. Pada masa yang sama, pelancaran penggunaan dalam saluran paip dipantau menggunakan alat tersebut werf. Sebenarnya, dalam konteks projek kami ini, kami mendengar "GitOps" yang berterusan apabila kami membincangkan masalah mendesak jurutera DevOps di tempat kami di KubeCon Europe'19.

PPS daripada penterjemah

Baca juga di blog kami:

• «Petua & kiat Kubernetes: memindahkan sumber yang berjalan dalam kelompok kepada pengurusan Helm 2»;
• «Memperkenalkan kubedog, perpustakaan untuk menjejaki sumber Kubernetes»;
• «Memperluas dan melengkapkan Kubernetes (laporan ulasan dan video)»;
• «Petua untuk mencipta aliran kerja tersuai dalam GitLab CI'.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Adakah anda menggunakan GitOps?

• Ya, pendekatan tarik

• Ya, tolak

• Ya, tarik + tolak

• Ya, sesuatu yang lain

• Tiada

30 pengguna mengundi. 10 pengguna berpantang.

Sumber: www.habr.com