Geekly articles weekly

GitOps: membandingkan metode Tarik dan Dorong

Catatan perev. : Di komunitas Kubernetes, tren yang disebut GitOps semakin populer, seperti yang kita lihat secara pribadi dengan mengunjungi KubeCon Eropa 2019. Istilah ini diciptakan secara relatif baru-baru ini oleh kepala Weaveworks - Alexis Richardson - dan berarti penggunaan alat-alat yang akrab bagi pengembang (terutama Git, dari mana nama itu sendiri) untuk memecahkan masalah operasional. Secara khusus, kita berbicara tentang mengeksploitasi Kubernetes melalui menyimpan konfigurasinya di Git dan secara otomatis meluncurkan perubahan ke cluster. Matthias Jg berbicara tentang dua pendekatan untuk peluncuran ini dalam artikel ini.



Tahun lalu (pada kenyataannya, ini secara resmi terjadi pada bulan Agustus 2017 - kira-kira. Terjemahan) , Sebuah pendekatan baru untuk menyebarkan aplikasi di Kubernetes muncul. Ini disebut GitOps, dan didasarkan pada gagasan dasar bahwa pelacakan versi penyebaran dilakukan dalam lingkungan repositori Git yang aman.

Keuntungan utama dari pendekatan ini adalah sebagai berikut :

  1. Penerapan versi dan ubah riwayat . Keadaan seluruh cluster disimpan dalam repositori Git, dan penyebaran hanya diperbarui oleh komit. Selain itu, semua perubahan dapat dilacak menggunakan riwayat komit.
  2. Kickback menggunakan perintah Git yang sudah dikenal . git reset sederhana memungkinkan Anda untuk membuang perubahan dalam penerapan; status terakhir selalu tersedia.
  3. Kontrol akses siap . Biasanya, sistem Git berisi banyak data rahasia, sehingga sebagian besar perusahaan memberikan perhatian khusus untuk melindunginya. Dengan demikian, perlindungan ini meluas ke operasi dengan penyebaran.
  4. Kebijakan untuk penerapan . Sebagian besar sistem Git awalnya mendukung kebijakan untuk cabang yang berbeda - misalnya, hanya permintaan tarik yang dapat memperbarui master, dan anggota tim lainnya harus memeriksa dan menerima perubahan. Seperti halnya kontrol akses, kebijakan yang sama berlaku untuk pembaruan penempatan.

Seperti yang Anda lihat, metode GitOps memiliki banyak keuntungan. Selama setahun terakhir, dua pendekatan telah mendapatkan popularitas tertentu. Satu didasarkan pada dorongan, yang lain pada tarikan. Sebelum melihat mereka, mari kita lihat dulu seperti apa penyebaran Kubernet.

Metode Penempatan


Dalam beberapa tahun terakhir, berbagai metode dan alat penyebaran telah didirikan di Kubernetes:

  1. Berdasarkan templat Kubernetes / Kustomize asli . Ini adalah cara termudah untuk menyebarkan aplikasi ke Kubernetes. Pengembang membuat file YAML dasar dan menerapkannya. Untuk menghilangkan penulisan ulang konstan dari pola yang sama, Kustomize dikembangkan (mengubah pola Kubernetes menjadi modul). Catatan perev. : Kustomize telah diintegrasikan ke dalam kubectl dengan merilis Kubernetes 1.14 .
  2. Grafik Helm . Diagram Helm memungkinkan Anda untuk membuat set templat, wadah init, sidecar'ov, dll., Yang digunakan untuk menggunakan aplikasi dengan opsi konfigurasi yang lebih fleksibel daripada dalam pendekatan berbasis templat. Metode ini didasarkan pada file template YAML. Helm mengisinya dengan berbagai parameter dan kemudian mengirimkannya ke Tiller, komponen kluster yang menyebarkannya di kluster dan memungkinkan pembaruan dan rollback. Yang penting adalah, pada kenyataannya, Helm hanya memasukkan nilai-nilai yang diperlukan ke dalam template dan kemudian menerapkannya dengan cara yang sama seperti yang dilakukan dalam pendekatan tradisional (untuk rincian lebih lanjut tentang bagaimana semua itu bekerja dan bagaimana Anda dapat menggunakannya, baca artikel kami tentang Helm - approx. .) . Ada berbagai macam grafik Helm siap pakai yang mencakup berbagai tugas.
  3. Alat alternatif . Ada banyak alat alternatif. Semuanya disatukan oleh fakta bahwa mereka mengubah beberapa file template menjadi file YAML yang ramah dari Kubernet dan kemudian menerapkannya.

Dalam pekerjaan kami, kami terus-menerus menggunakan grafik Helm untuk alat-alat penting (karena banyak dari mereka sudah siap, yang sangat menyederhanakan kehidupan) dan Kubernet “membersihkan” file-file YAML untuk menyebarkan aplikasi kami sendiri.

Tarik & dorong


Dalam salah satu posting blog saya yang baru, saya memperkenalkan alat Weave Flux , yang memungkinkan Anda untuk mengkomit templat ke repositori Git dan memperbarui penyebaran setelah setiap komit atau mendorong wadah. Pengalaman saya menunjukkan bahwa alat ini adalah salah satu yang utama dalam mempromosikan pendekatan tarikan, jadi saya akan sering merujuknya. Jika Anda ingin tahu lebih banyak tentang cara menggunakannya, berikut adalah tautan ke artikel tersebut .

NB! Semua manfaat menggunakan GitOps dipertahankan untuk kedua pendekatan.

Pendekatan Berbasis Tarik




Pendekatan tarikan didasarkan pada kenyataan bahwa semua perubahan diterapkan dari dalam cluster. Ada operator di dalam cluster yang secara teratur memeriksa repositori Git dan Docker yang terkait. Jika ada perubahan yang terjadi di dalamnya, status cluster diperbarui secara internal. Biasanya dianggap bahwa proses seperti itu sangat aman, karena tidak ada klien eksternal yang memiliki akses ke hak administrator cluster.

Pro:

  1. Tidak ada klien eksternal yang memiliki hak untuk membuat perubahan pada klaster, semua pembaruan digulir dari dalam.
  2. Beberapa alat juga memungkinkan Anda untuk menyinkronkan pembaruan ke grafik Helm dan mengikatnya ke sebuah cluster.
  3. Registry Docker dapat dipindai untuk versi baru. Jika gambar baru muncul, repositori dan penyebaran Git diperbarui ke versi baru.
  4. Alat tarik dapat didistribusikan di ruang nama yang berbeda dengan repositori dan izin Git yang berbeda. Berkat ini, dimungkinkan untuk menggunakan model multitenant. Misalnya, tim A dapat menggunakan namespace A, tim B dapat menggunakan namespace B, dan tim infrastruktur dapat menggunakan ruang global.
  5. Sebagai aturan, alat sangat ringan.
  6. Dikombinasikan dengan alat-alat seperti pernyataan Bitnami Sealed Secrets , rahasia dapat disimpan dienkripsi dalam repositori Git dan diambil dalam cluster.
  7. Tidak ada komunikasi dengan saluran pipa CD, karena penyebaran terjadi di dalam cluster.

Cons :

  1. Mengelola rahasia penyebaran dari grafik Helm lebih rumit dari biasanya, karena Anda pertama-tama harus membuatnya di, katakanlah, menyegel rahasia, kemudian mendekripsi mereka dengan operator internal dan hanya setelah itu mereka menjadi tersedia untuk alat tarik. Kemudian Anda dapat meluncurkan rilis di Helm dengan nilai-nilai di rahasia yang sudah dikerahkan. Cara termudah adalah dengan membuat rahasia dengan semua nilai Helm yang digunakan untuk penyebaran, mendekripsi dan komit di Git.
  2. Menggunakan pendekatan tarikan, Anda menemukan diri Anda terikat pada alat yang beroperasi pada tarikan. Ini membatasi kemampuan untuk menyesuaikan proses penyebaran penyebaran di cluster. Misalnya, bekerja dengan Kustomize menjadi rumit oleh fakta bahwa itu harus dijalankan sebelum templat terakhir tiba di Git. Saya tidak mengatakan bahwa Anda tidak dapat menggunakan alat individual, tetapi mereka lebih sulit untuk diintegrasikan ke dalam proses penyebaran.

Pendekatan Berbasis Push




Dalam pendekatan push, sistem eksternal (terutama jaringan pipa CD) mulai menyebar ke cluster setelah melakukan ke repositori Git atau dalam kasus keberhasilan pelaksanaan pipa CI sebelumnya. Dalam pendekatan ini, sistem memiliki akses ke cluster.

Pro :

  1. Keamanan ditentukan oleh repositori Git dan membangun saluran pipa.
  2. Menyebarkan grafik Helm lebih mudah, ada dukungan untuk plugin Helm.
  3. Rahasia lebih mudah dikelola, karena rahasia dapat digunakan dalam saluran pipa, serta disimpan di Git dalam bentuk terenkripsi (tergantung pada preferensi pengguna).
  4. Kurangnya pengikatan ke alat tertentu, karena salah satu dari tipenya dapat digunakan.
  5. Pembaruan versi kontainer dapat dipicu oleh jalur perakitan.

Cons :

  1. Data untuk mengakses cluster terletak di dalam sistem build.
  2. Memperbarui wadah penyebaran masih lebih mudah dilakukan dengan proses tarik.
  3. Ini sangat tergantung pada sistem CD, karena pipa yang kami butuhkan mungkin awalnya ditulis untuk Gitlab Runners, dan kemudian tim memutuskan untuk beralih ke Azure DevOps atau Jenkins ... dan Anda harus memigrasikan sejumlah besar saluran pipa bangunan.

Intinya: Dorong atau Tarik?


Seperti biasa, setiap pendekatan memiliki pro dan kontra. Beberapa tugas lebih mudah diselesaikan dengan satu dan lebih sulit dengan yang lain. Pada awalnya, saya menghabiskan penyebaran secara manual, tetapi setelah saya menemukan beberapa artikel tentang Weave Flux, saya memutuskan untuk mengimplementasikan proses GitOps untuk semua proyek. Untuk templat dasar, ini ternyata mudah, tetapi kemudian saya mulai menemui kesulitan dalam bekerja dengan grafik Helm. Pada saat itu, Weave Flux hanya menawarkan versi dasar dari Operator Helm Chart, tetapi bahkan sekarang beberapa tugas lebih rumit karena kebutuhan untuk secara manual membuat rahasia dan menerapkannya. Anda dapat mengatakan bahwa pendekatan tarikan jauh lebih aman, karena kredensial kluster tidak tersedia di luarnya, dan ini meningkatkan keamanan sehingga perlu usaha ekstra.

Setelah berpikir sedikit, saya sampai pada kesimpulan yang tidak terduga bahwa ini tidak benar. Jika kita berbicara tentang komponen yang membutuhkan perlindungan maksimal, daftar ini akan mencakup penyimpanan rahasia dan sistem CI / CD, repositori Git. Informasi di dalamnya sangat rentan dan membutuhkan perlindungan maksimal. Selain itu, jika seseorang memasuki repositori Git Anda dan dapat mendorong kode di sana, ia akan dapat menyebarkan apa pun yang ia inginkan (terlepas dari pendekatan yang dipilih, itu akan menarik atau mendorong) dan menyusup ke sistem cluster. Dengan demikian, komponen terpenting yang membutuhkan perlindungan adalah repositori Git dan sistem CI / CD, bukan kredensial cluster. Jika Anda memiliki kebijakan dan langkah-langkah keamanan yang disesuaikan untuk sistem jenis ini, dan kredensial cluster diambil dalam pipa hanya sebagai rahasia, keamanan tambahan dari pendekatan tarikan mungkin tidak sama berharganya seperti yang dimaksudkan semula.

Jadi, jika pendekatan tarikan lebih memakan waktu dan tidak memberikan keuntungan dalam keamanan, bukankah logis menggunakan hanya pendekatan dorong? Tetapi seseorang mungkin mengatakan bahwa dalam pendekatan push Anda terlalu terikat pada sistem CD dan, mungkin, lebih baik tidak melakukan ini untuk membuat migrasi lebih mudah di masa depan.

Menurut pendapat saya (seperti biasa), Anda harus menggunakan apa yang lebih cocok untuk kasus tertentu atau menggabungkan. Secara pribadi, saya menggunakan kedua pendekatan: Weave Flux untuk penyebaran berbasis pull yang sebagian besar mencakup layanan kami sendiri, dan pendekatan push dengan Helm dan plugin yang menyederhanakan penerapan grafik Helm ke cluster dan memungkinkan Anda untuk dengan mudah membuat rahasia. Saya pikir tidak akan pernah ada solusi tunggal yang cocok untuk semua kasus, karena selalu ada banyak nuansa dan mereka bergantung pada aplikasi spesifik. Pada saat yang sama, saya sangat merekomendasikan GitOps - ini sangat menyederhanakan hidup dan meningkatkan keamanan.

Saya harap pengalaman saya tentang topik ini akan membantu menentukan metode mana yang lebih cocok untuk jenis penempatan Anda, dan saya akan senang mengetahui pendapat Anda.

Catatan PS dari penerjemah


Dalam minus dari model tarikan ada poin tentang fakta bahwa sulit untuk menempatkan manifes yang diberikan dalam Git, namun tidak ada minus bahwa pipa CD dalam model tarikan hidup terpisah dari peluncuran dan, pada kenyataannya, menjadi pipa kategori Berlanjut Berlaku . Oleh karena itu, upaya lebih lanjut akan diperlukan untuk mengumpulkan status mereka dari semua penyebaran dan entah bagaimana memberikan akses ke log / status, dan lebih disukai dengan mengacu pada sistem CD.

Dalam hal ini, model dorong memungkinkan Anda untuk memberikan setidaknya beberapa peluncuran jaminan, karena masa pakai pipa dapat dibuat sama dengan masa pakai peluncuran.

Kami menguji kedua model dan sampai pada kesimpulan yang sama dengan penulis artikel:

  1. Model tarikan cocok bagi kami untuk mengatur pembaruan komponen sistem pada sejumlah besar cluster (lihat artikel tentang operator tambahan ).
  2. Model push berbasis GitLab CI sangat cocok untuk meluncurkan aplikasi menggunakan grafik Helm. Dalam peluncuran peluncuran ini di dalam pipa dipantau menggunakan alat werf . Ngomong-ngomong, dalam konteks proyek kami, kami mendengar "GitOps" yang konstan ketika kami membahas masalah-masalah mendesak para insinyur DevOps di gerai kami di KubeCon Europe'19.

PPS dari penerjemah


Baca juga di blog kami:

Source: https://habr.com/ru/post/id456754/

More articles:


All Articles