Catatan. terjemah: Selepas penerbitan baru-baru ini mengenai kaedah tarik dan tolak dalam GitOps, kami melihat minat terhadap model ini secara umum, tetapi terdapat sangat sedikit penerbitan berbahasa Rusia mengenai topik ini (hanya tiada pada Habré). Oleh itu, kami berbesar hati untuk menawarkan kepada perhatian anda terjemahan artikel lain - walaupun hampir setahun yang lalu! — daripada Weaveworks, ketua yang mencipta istilah “GitOps.” Teks menerangkan intipati pendekatan dan perbezaan utama daripada yang sedia ada.
Setahun yang lalu kami menerbitkan . Pada masa itu, kami berkongsi cara pasukan Weaveworks melancarkan SaaS sepenuhnya berdasarkan Kubernetes dan membangunkan satu set amalan terbaik preskriptif untuk mengatur, mengurus dan memantau dalam persekitaran asli awan.
Artikel itu ternyata popular. Orang lain mula bercakap tentang GitOps dan mula menerbitkan alatan baharu untuk , , , , dan sebagainya. Muncul di laman web kami penerbitan dan kes penggunaan GitOps. Tetapi sesetengah orang masih mempunyai soalan. Bagaimanakah model berbeza daripada yang tradisional? dan penghantaran berterusan ()? Adakah perlu menggunakan Kubernetes?
Kami tidak lama lagi menyedari bahawa penerangan baharu diperlukan, menawarkan:
- Sebilangan besar contoh dan cerita;
- Takrifan khusus GitOps;
- Perbandingan dengan penghantaran berterusan tradisional.
Dalam artikel ini kami telah cuba membincangkan semua topik ini. Ia menyediakan pengenalan terkini kepada GitOps dan pembangun serta perspektif CI/CD. Kami memberi tumpuan terutamanya pada Kubernetes, walaupun model itu boleh digeneralisasikan.
Temui GitOps
Bayangkan Alice. Dia menjalankan Insurans Keluarga, yang menawarkan insurans kesihatan, kereta, rumah dan perjalanan kepada orang yang terlalu sibuk untuk memikirkan selok-belok kontrak itu sendiri. Perniagaannya bermula sebagai projek sampingan semasa Alice bekerja di sebuah bank sebagai saintis data. Suatu hari dia menyedari bahawa dia boleh menggunakan algoritma komputer canggih untuk menganalisis data dan merumuskan pakej insurans dengan lebih berkesan. Pelabur membiayai projek itu, dan kini syarikatnya membawa masuk lebih daripada $20 juta setahun dan berkembang pesat. Pada masa ini, ia menggaji 180 orang dalam pelbagai jawatan. Ini termasuk pasukan teknologi yang membangun, menyelenggara tapak web, pangkalan data dan menganalisis pangkalan pelanggan. Pasukan 60 orang diketuai oleh Bob, pengarah teknikal syarikat.
Pasukan Bob menggunakan sistem pengeluaran dalam awan. Aplikasi teras mereka dijalankan pada GKE, mengambil kesempatan daripada Kubernetes di Google Cloud. Selain itu, mereka menggunakan pelbagai alat data dan analitik dalam kerja mereka.
Insurans Keluarga tidak mahu menggunakan bekas, tetapi terperangkap dalam keghairahan Docker. Syarikat itu tidak lama kemudian mendapati bahawa GKE menjadikannya mudah dan mudah untuk menggunakan kluster untuk menguji ciri baharu. Jenkins untuk CI dan Quay telah ditambahkan untuk mengatur pendaftaran kontena, skrip telah ditulis untuk Jenkins yang menolak bekas dan konfigurasi baharu kepada GKE.
Beberapa masa telah berlalu. Alice dan Bob kecewa dengan prestasi pendekatan pilihan mereka dan kesannya terhadap perniagaan. Pengenalan kontena tidak meningkatkan produktiviti seperti yang diharapkan oleh pasukan. Kadangkala penempatan akan rosak, dan tidak jelas sama ada perubahan kod harus dipersalahkan. Ia juga ternyata sukar untuk menjejaki perubahan konfigurasi. Selalunya adalah perlu untuk mencipta kluster baru dan memindahkan aplikasi kepadanya, kerana ini adalah cara paling mudah untuk menghapuskan kekacauan yang telah berlaku pada sistem. Alice takut keadaan akan menjadi lebih teruk apabila aplikasi dibangunkan (selain itu, projek baharu berdasarkan pembelajaran mesin sedang dibuat). Bob telah mengautomasikan kebanyakan kerja dan tidak faham mengapa saluran paip masih tidak stabil, tidak berskala dengan baik dan memerlukan campur tangan manual secara berkala?
Kemudian mereka belajar tentang GitOps. Keputusan ini ternyata betul-betul apa yang mereka perlukan untuk maju dengan yakin.
Alice dan Bob telah mendengar tentang Git, DevOps dan infrastruktur sebagai aliran kerja kod selama bertahun-tahun. Apa yang unik tentang GitOps ialah ia membawa satu set amalan terbaik—kedua-dua definitif dan normatif—untuk melaksanakan idea ini dalam konteks Kubernetes. Tema ini , termasuk dalam .
Insurans Keluarga memutuskan untuk melaksanakan GitOps. Syarikat itu kini mempunyai model operasi automatik yang serasi dengan Kubernetes dan digabungkan kelajuan dengan kestabilankerana mereka:
- mendapati bahawa produktiviti pasukan meningkat dua kali ganda tanpa sesiapa menjadi gila;
- berhenti melayan skrip. Sebaliknya, mereka kini boleh menumpukan pada ciri baharu dan menambah baik kaedah kejuruteraan - contohnya, memperkenalkan pelancaran kenari dan menambah baik ujian;
- kami telah menambah baik proses penempatan supaya ia jarang rosak;
- mendapat peluang untuk memulihkan penempatan selepas kegagalan separa tanpa campur tangan manual;
- dibeli terpakaiоKeyakinan yang lebih tinggi dalam sistem penyampaian. Alice dan Bob mendapati bahawa mereka boleh membahagikan pasukan kepada pasukan perkhidmatan mikro yang bekerja secara selari;
- boleh membuat 30-50 perubahan pada projek setiap hari melalui usaha setiap kumpulan dan mencuba teknik baru;
- adalah mudah untuk menarik pemaju baharu kepada projek itu, yang berpeluang melancarkan kemas kini kepada pengeluaran menggunakan permintaan tarik dalam beberapa jam;
- lulus audit dengan mudah dalam rangka kerja SOC2 (untuk pematuhan penyedia perkhidmatan dengan keperluan untuk pengurusan data selamat; baca lebih lanjut, sebagai contoh, - lebih kurang terjemah.).
Apa yang berlaku?
GitOps ialah dua perkara:
- Model operasi untuk Kubernetes dan cloud native. Ia menyediakan satu set amalan terbaik untuk menggunakan, mengurus dan memantau kluster dan aplikasi kontena. Definisi elegan dalam bentuk daripada :
- Laluan untuk mewujudkan persekitaran pengurusan aplikasi berpusatkan pembangun. Kami menggunakan aliran kerja Git pada kedua-dua operasi dan pembangunan. Sila ambil perhatian bahawa ini bukan hanya tentang Git push, tetapi tentang mengatur keseluruhan set alat CI/CD dan UI/UX.
Beberapa perkataan tentang Git
Jika anda tidak biasa dengan sistem kawalan versi dan aliran kerja berasaskan Git, kami amat mengesyorkan mempelajarinya. Bekerja dengan cawangan dan permintaan tarik mungkin kelihatan seperti sihir pada mulanya, tetapi faedahnya berbaloi dengan usaha. Di sini untuk mula.
Cara Kubernetes berfungsi
Dalam cerita kami, Alice dan Bob beralih kepada GitOps selepas bekerja dengan Kubernetes untuk seketika. Memang, GitOps berkait rapat dengan Kubernetes - ia adalah model operasi untuk infrastruktur dan aplikasi berdasarkan Kubernetes.
Apakah yang Kubernetes berikan kepada pengguna?
Berikut adalah beberapa ciri utama:
- Dalam model Kubernetes, semuanya boleh diterangkan dalam bentuk deklaratif.
- Pelayan API Kubernetes mengambil pengisytiharan ini sebagai input dan kemudian terus mencuba untuk membawa kluster ke dalam keadaan yang diterangkan dalam perisytiharan.
- Pengisytiharan adalah mencukupi untuk menerangkan dan mengurus pelbagai jenis beban kerja—"aplikasi."
- Akibatnya, perubahan pada aplikasi dan kelompok berlaku disebabkan oleh:
- perubahan dalam imej bekas;
- perubahan kepada spesifikasi deklaratif;
- ralat dalam persekitaran - contohnya, ranap kontena.
Keupayaan Penumpuan Hebat Kubernetes
Apabila pentadbir membuat perubahan konfigurasi, pengatur Kubernetes akan menggunakannya pada kluster selagi keadaannya tidak akan mendekati konfigurasi baharu. Model ini berfungsi untuk mana-mana sumber Kubernetes dan boleh dikembangkan dengan Definisi Sumber Tersuai (CRD). Oleh itu, penggunaan Kubernetes mempunyai ciri-ciri menarik berikut:
- Automasi: Kemas kini Kubernetes menyediakan mekanisme untuk mengautomasikan proses menerapkan perubahan dengan anggun dan tepat pada masanya.
- penumpuan: Kubernetes akan terus mencuba kemas kini sehingga berjaya.
- Idempotensi: Aplikasi penumpuan yang berulang membawa kepada hasil yang sama.
- Determinisme: Apabila sumber mencukupi, keadaan kluster yang dikemas kini hanya bergantung pada keadaan yang dikehendaki.
Cara GitOps berfungsi
Kami telah belajar cukup tentang Kubernetes untuk menerangkan cara GitOps berfungsi.
Mari kembali ke pasukan perkhidmatan mikro Insurans Keluarga. Apa yang biasanya mereka perlu lakukan? Lihat senarai di bawah (jika ada item di dalamnya kelihatan pelik atau tidak dikenali, sila berhenti mengkritik dan kekal bersama kami). Ini hanyalah contoh aliran kerja berasaskan Jenkins. Terdapat banyak proses lain apabila bekerja dengan alat lain.
Perkara utama ialah kita melihat bahawa setiap kemas kini berakhir dengan perubahan pada fail konfigurasi dan repositori Git. Perubahan kepada Git ini menyebabkan "operator GitOps" mengemas kini kluster:
1. Proses kerja: "Binaan Jenkins - cawangan induk'.
Senarai tugas:
- Jenkins menolak imej bertanda ke Quay;
- Jenkins menolak carta konfigurasi dan Helm ke baldi storan induk;
- Fungsi awan menyalin konfigurasi dan carta daripada baldi storan induk ke repositori Git induk;
- Pengendali GitOps mengemas kini kluster.
2. Binaan Jenkins - cawangan keluaran atau pembaikan terbaru:
- Jenkins menolak imej tidak bertanda ke Quay;
- Jenkins menolak carta konfigurasi dan Helm ke baldi storan pementasan;
- Fungsi awan menyalin konfigurasi dan carta daripada baldi storan pementasan ke repositori Git pementasan;
- Pengendali GitOps mengemas kini kluster.
3. Binaan Jenkins - bangunkan atau cawangan ciri:
- Jenkins menolak imej tidak bertanda ke Quay;
- Jenkins menolak carta konfigurasi dan Helm ke dalam baldi storan pembangunan;
- Fungsi awan menyalin konfigurasi dan carta daripada baldi storan pembangunan ke repositori Git yang dibangunkan;
- Pengendali GitOps mengemas kini kluster.
4. Menambah pelanggan baharu:
- Pengurus atau pentadbir (LCM/ops) memanggil Gradle untuk menggunakan dan mengkonfigurasi pengimbang beban rangkaian (NLB) pada mulanya;
- LCM/ops melakukan konfigurasi baharu untuk menyediakan penggunaan untuk kemas kini;
- Pengendali GitOps mengemas kini kluster.
Penerangan ringkas tentang GitOps
- Terangkan keadaan yang dikehendaki bagi keseluruhan sistem menggunakan spesifikasi pengisytiharan untuk setiap persekitaran (dalam cerita kami, pasukan Bob mentakrifkan keseluruhan konfigurasi sistem dalam Git).
- Repositori Git ialah satu-satunya sumber kebenaran mengenai keadaan yang dikehendaki bagi keseluruhan sistem.
- Semua perubahan kepada keadaan yang dikehendaki dibuat melalui komit dalam Git.
- Semua parameter kluster yang dikehendaki juga boleh diperhatikan dalam kluster itu sendiri. Dengan cara ini kita boleh menentukan sama ada ia sepadan (menumpu, berkumpul) atau berbeza (berbeza, menyimpang) keadaan yang dikehendaki dan diperhatikan.
- Jika keadaan yang dikehendaki dan yang diperhatikan berbeza, maka:
- Terdapat mekanisme penumpuan yang lambat laun menyegerakkan sasaran dan keadaan yang diperhatikan secara automatik. Di dalam kelompok, Kubernetes melakukan ini.
- Proses bermula serta-merta dengan amaran "perubahan dilakukan".
- Selepas beberapa tempoh masa yang boleh dikonfigurasikan, makluman "perbezaan" boleh dihantar jika keadaan berbeza.
- Dengan cara ini, semua komit dalam Git menyebabkan kemas kini yang boleh disahkan dan idempoten kepada kluster.
- Rollback ialah penumpuan kepada keadaan yang diingini sebelum ini.
- Konvergensi adalah muktamad. Kejadiannya ditunjukkan oleh:
- Tiada makluman perbezaan untuk tempoh masa tertentu.
- Makluman "bertumpu" (cth. webhook, acara tulis balik Git).
Apakah perbezaan?
Mari kita ulang lagi: semua sifat kluster yang dikehendaki mesti boleh diperhatikan dalam kluster itu sendiri.
Beberapa contoh perbezaan:
- Perubahan dalam fail konfigurasi kerana penggabungan cawangan dalam Git.
- Perubahan dalam fail konfigurasi disebabkan oleh komit Git yang dibuat oleh klien GUI.
- Berbilang perubahan kepada keadaan yang dikehendaki disebabkan oleh PR dalam Git diikuti dengan membina imej bekas dan perubahan konfigurasi.
- Perubahan dalam keadaan gugusan disebabkan ralat, konflik sumber yang mengakibatkan "tingkah laku buruk", atau hanya sisihan rawak daripada keadaan asal.
Apakah mekanisme penumpuan?
Beberapa contoh:
- Untuk bekas dan kelompok, mekanisme penumpuan disediakan oleh Kubernetes.
- Mekanisme yang sama boleh digunakan untuk mengurus aplikasi dan reka bentuk berasaskan Kubernetes (seperti Istio dan Kubeflow).
- Mekanisme untuk mengurus interaksi operasi antara Kubernetes, repositori imej dan Git menyediakan , yang merupakan sebahagian .
- Untuk mesin asas, mekanisme penumpuan mestilah deklaratif dan autonomi. Dari pengalaman kita sendiri, kita boleh mengatakan bahawa paling hampir dengan definisi ini, tetapi masih memerlukan kawalan manusia. Dalam pengertian ini, GitOps memperluaskan tradisi Infrastruktur sebagai Kod.
GitOps menggabungkan Git dengan enjin penumpuan terbaik Kubernetes untuk menyediakan model untuk eksploitasi.
GitOps membolehkan kami berkata: Hanya sistem yang boleh diterangkan dan diperhatikan boleh diautomasikan dan dikawal.
GitOps bertujuan untuk keseluruhan timbunan asli awan (contohnya, Terraform, dll.)
GitOps bukan hanya Kubernetes. Kami mahu keseluruhan sistem didorong secara deklaratif dan menggunakan penumpuan. Dengan keseluruhan sistem yang kami maksudkan adalah koleksi persekitaran yang berfungsi dengan Kubernetes - contohnya, "dev cluster 1", "production", dll. Setiap persekitaran termasuk mesin, kluster, aplikasi, serta antara muka untuk perkhidmatan luaran yang menyediakan data, pemantauan dan sebagainya.
Perhatikan betapa pentingnya Terraform kepada masalah bootstrap dalam kes ini. Kubernetes perlu digunakan di suatu tempat, dan menggunakan Terraform bermakna kita boleh menggunakan aliran kerja GitOps yang sama untuk mencipta lapisan kawalan yang menyokong Kubernetes dan aplikasi. Ini adalah amalan terbaik yang berguna.
Terdapat tumpuan yang kuat untuk menggunakan konsep GitOps pada lapisan di atas Kubernetes. Pada masa ini, terdapat penyelesaian jenis GitOps untuk Istio, Helm, Ksonnet, OpenFaaS dan Kubeflow, serta, sebagai contoh, untuk Pulumi, yang mencipta lapisan untuk membangunkan aplikasi untuk awan asli.
Kubernetes CI/CD: membandingkan GitOps dengan pendekatan lain
Seperti yang dinyatakan, GitOps ialah dua perkara:
- Model pengendalian untuk Kubernetes dan cloud native yang diterangkan di atas.
- Laluan ke persekitaran pengurusan aplikasi berpusatkan pembangun.
Bagi kebanyakan orang, GitOps adalah terutamanya aliran kerja berdasarkan dorongan Git. Kami pun suka dia. Tetapi bukan itu sahaja: mari kita lihat saluran paip CI/CD.
GitOps mendayakan penggunaan berterusan (CD) untuk Kubernetes
GitOps menawarkan mekanisme penggunaan berterusan yang menghapuskan keperluan untuk "sistem pengurusan penempatan" yang berasingan. Kubernetes melakukan semua kerja untuk anda.
- Mengemas kini aplikasi memerlukan pengemaskinian dalam Git. Ini ialah kemas kini transaksi kepada keadaan yang dikehendaki. "Pengerahan" kemudiannya dilakukan dalam kelompok oleh Kubernetes sendiri berdasarkan perihalan yang dikemas kini.
- Disebabkan sifat cara Kubernetes berfungsi, kemas kini ini bertumpu. Ini menyediakan mekanisme untuk penggunaan berterusan di mana semua kemas kini adalah atom.
- Nota: menawarkan pengendali GitOps yang menyepadukan Git dan Kubernetes dan membenarkan CD dilakukan dengan menyelaraskan keadaan kluster yang dikehendaki dan semasa.
Tanpa kubectl dan skrip
Anda harus mengelak daripada menggunakan Kubectl untuk mengemas kini kluster anda, dan terutamanya elakkan menggunakan skrip untuk mengumpulkan perintah kubectl. Sebaliknya, dengan saluran paip GitOps, pengguna boleh mengemas kini kelompok Kubernetes mereka melalui Git.
Faedah termasuk:
- Betul. Sekumpulan kemas kini boleh digunakan, disatukan dan akhirnya disahkan, membawa kita lebih dekat kepada matlamat penggunaan atom. Sebaliknya, menggunakan skrip tidak memberikan sebarang jaminan penumpuan (lebih lanjut mengenai perkara ini di bawah).
- keselamatan. Kelsey Hightower: "Hadkan akses kepada kelompok Kubernetes anda kepada alat automasi dan pentadbir yang bertanggungjawab untuk menyahpepijat atau menyelenggaranya." lihat juga tentang keselamatan dan pematuhan dengan spesifikasi teknikal, serta dengan mencuri bukti kelayakan daripada skrip Jenkins yang ditulis secara sembarangan.
- Pengalaman pengguna. Kubectl mendedahkan mekanik model objek Kubernetes, yang agak rumit. Sebaik-baiknya, pengguna harus berinteraksi dengan sistem pada tahap abstraksi yang lebih tinggi. Di sini saya sekali lagi akan merujuk kepada Kelsey dan mengesyorkan menonton .
Perbezaan antara CI dan CD
GitOps menambah baik model CI/CD sedia ada.
Pelayan CI moden ialah alat orkestrasi. Khususnya, ia adalah alat untuk mengatur saluran paip CI. Ini termasuk membina, menguji, bergabung ke batang, dll. Pelayan CI mengautomasikan pengurusan saluran paip berbilang langkah yang kompleks. Godaan biasa adalah untuk menskrip satu set kemas kini Kubernetes dan menjalankannya sebagai sebahagian daripada saluran paip untuk menolak perubahan pada kluster. Memang inilah yang dilakukan oleh ramai pakar. Walau bagaimanapun, ini tidak optimum, dan inilah sebabnya.
CI harus digunakan untuk menolak kemas kini ke trunk, dan gugusan Kubernetes harus menukar sendiri berdasarkan kemas kini tersebut untuk mengurus CD secara dalaman. Kami memanggilnya , tidak seperti model tolak CI. CD adalah sebahagian orkestrasi masa larian.
Mengapa Pelayan CI Tidak Harus Membuat CD melalui Kemas Kini Langsung dalam Kubernetes
Jangan gunakan pelayan CI untuk mengatur kemas kini terus kepada Kubernetes sebagai satu set tugas CI. Ini adalah anti-corak yang kita bincangkan pada blog anda.
Mari kita kembali kepada Alice dan Bob.
Apakah masalah yang mereka hadapi? Pelayan CI Bob menggunakan perubahan pada kluster, tetapi jika ia ranap dalam proses, Bob tidak akan mengetahui keadaan kluster itu (atau sepatutnya) atau cara membetulkannya. Perkara yang sama berlaku dalam kes kejayaan.
Mari kita anggap bahawa pasukan Bob membina imej baharu dan kemudian menampal penempatan mereka untuk menggunakan imej (semuanya daripada saluran paip CI).
Jika imej dibina seperti biasa, tetapi saluran paip gagal, pasukan perlu memikirkan:
- Adakah kemas kini telah dilancarkan?
- Adakah kita melancarkan binaan baharu? Adakah ini akan membawa kepada kesan sampingan yang tidak perlu - dengan kemungkinan mempunyai dua binaan imej tidak berubah yang sama?
- Patutkah kita menunggu kemas kini seterusnya sebelum menjalankan binaan?
- Apa yang silap sebenarnya? Langkah manakah yang perlu diulang (dan yang manakah selamat untuk diulang)?
Mewujudkan aliran kerja berasaskan Git tidak menjamin bahawa pasukan Bob tidak akan menghadapi masalah ini. Mereka masih boleh membuat kesilapan dengan tolakan komit, teg atau beberapa parameter lain; walau bagaimanapun, pendekatan ini masih lebih dekat dengan pendekatan semua-atau-tiada yang eksplisit.
Untuk meringkaskan, inilah sebabnya pelayan CI tidak sepatutnya berurusan dengan CD:
- Skrip kemas kini tidak selalunya deterministik; Sangat mudah untuk membuat kesilapan dalam mereka.
- Pelayan CI tidak menumpu kepada model kelompok deklaratif.
- Sukar untuk menjamin mati pucuk. Pengguna mesti memahami semantik sistem yang mendalam.
- Lebih sukar untuk pulih daripada kegagalan separa.
Nota tentang Helm: Jika anda ingin menggunakan Helm, kami mengesyorkan anda menggabungkannya dengan operator GitOps seperti . Ini akan membantu memastikan penumpuan. Helm itu sendiri bukan deterministik mahupun atom.
GitOps sebagai cara terbaik untuk melaksanakan Penghantaran Berterusan untuk Kubernetes
Pasukan Alice dan Bob melaksanakan GitOps dan mendapati bahawa ia telah menjadi lebih mudah untuk bekerja dengan produk perisian, mengekalkan prestasi tinggi dan kestabilan. Mari kita akhiri artikel ini dengan ilustrasi yang menunjukkan rupa pendekatan baharu mereka. Perlu diingat bahawa kami kebanyakannya bercakap tentang aplikasi dan perkhidmatan, tetapi GitOps boleh digunakan untuk mengurus seluruh platform.
Model pengendalian untuk Kubernetes
Lihat rajah berikut. Ia membentangkan Git dan repositori imej kontena sebagai sumber kongsi untuk dua kitaran hayat yang dirancang:
- Saluran paip penyepaduan berterusan yang membaca dan menulis fail ke Git dan boleh mengemas kini repositori imej kontena.
- Saluran paip Runtime GitOps yang menggabungkan penggunaan dengan pengurusan dan kebolehmerhatian. Ia membaca dan menulis fail ke Git dan boleh memuat turun imej bekas.
Apakah penemuan utama?
- Pengasingan kebimbangan: Sila ambil perhatian bahawa kedua-dua saluran paip hanya boleh berkomunikasi dengan mengemas kini Git atau repositori imej. Dalam erti kata lain, terdapat tembok api antara CI dan persekitaran masa jalan. Kami memanggilnya "firewall kebolehubah" (firewall kebolehubahan), kerana semua kemas kini repositori mencipta versi baharu. Untuk maklumat lanjut tentang topik ini, rujuk slaid 72-87 .
- Anda boleh menggunakan mana-mana pelayan CI dan Git: GitOps berfungsi dengan mana-mana komponen. Anda boleh terus menggunakan pelayan CI dan Git kegemaran anda, repositori imej dan suite ujian. Hampir semua alatan Penghantaran Berterusan lain di pasaran memerlukan pelayan CI/Git atau repositori imej mereka sendiri. Ini mungkin menjadi faktor pengehad dalam pembangunan awan asli. Dengan GitOps, anda boleh menggunakan alat biasa.
- Acara sebagai alat penyepaduan: Sebaik sahaja data dalam Git dikemas kini, Weave Flux (atau operator Weave Cloud) memberitahu masa jalan. Setiap kali Kubernetes menerima set perubahan, Git dikemas kini. Ini menyediakan model penyepaduan mudah untuk mengatur aliran kerja untuk GitOps, seperti yang ditunjukkan di bawah.
Kesimpulan
GitOps menyediakan jaminan kemas kini kukuh yang diperlukan oleh mana-mana alat CI/CD moden:
- automasi;
- penumpuan;
- mati pucuk;
- determinisme.
Ini penting kerana ia menawarkan model operasi untuk pembangun asli awan.
- Alat tradisional untuk mengurus dan memantau sistem dikaitkan dengan pasukan operasi yang beroperasi dalam buku panduan (satu set prosedur dan operasi rutin - lebih kurang transl.), terikat pada penempatan tertentu.
- Dalam pengurusan asli awan, alat kebolehmerhatian ialah cara terbaik untuk mengukur hasil penempatan supaya pasukan pembangunan boleh bertindak balas dengan cepat.
Bayangkan banyak kluster bertaburan merentasi awan yang berbeza dan banyak perkhidmatan dengan pasukan dan rancangan penempatan mereka sendiri. GitOps menawarkan model skala-invarian untuk mengurus semua kelimpahan ini.
PS daripada penterjemah
Baca juga di blog kami:
- «»;
- «»;
- «'.
Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. , Sama-sama.
Adakah anda tahu tentang GitOps sebelum kedua-dua terjemahan ini muncul di Habré?
-
Ya, saya tahu segala-galanya
-
Secara dangkal sahaja
-
Tiada
35 pengguna mengundi. 10 pengguna berpantang.
Sumber: www.habr.com