Catatan. terjemahan: Setelah publikasi terbaru tentang metode tarik dan dorong di GitOps, kami melihat minat terhadap model ini secara umum, tetapi hanya ada sedikit publikasi berbahasa Rusia tentang topik ini (tidak ada satu pun di Habré). Oleh karena itu, kami dengan senang hati menyampaikan kepada Anda terjemahan artikel lain - meskipun hampir setahun yang lalu! — dari Weaveworks, yang pertama kali menciptakan istilah “GitOps.” Teks tersebut menjelaskan esensi pendekatan dan perbedaan utama dari pendekatan yang sudah ada.
Setahun yang lalu kami menerbitkan . Saat itu, kami berbagi bagaimana tim Weaveworks meluncurkan SaaS yang sepenuhnya berbasis Kubernetes dan mengembangkan serangkaian praktik terbaik preskriptif untuk penerapan, pengelolaan, dan pemantauan di lingkungan cloud native.
Artikel itu ternyata populer. Orang lain mulai membicarakan GitOps dan mulai menerbitkan alat baru untuk itu , , , , dan seterusnya. Muncul di situs web kami publikasi dan kasus penggunaan GitOps. Namun beberapa orang masih memiliki pertanyaan. Apa perbedaan modelnya dengan model tradisional? dan pengiriman berkelanjutan ()? Apakah perlu menggunakan Kubernetes?
Kami segera menyadari bahwa diperlukan deskripsi baru, yang menawarkan:
- Banyak contoh dan cerita;
- Definisi khusus GitOps;
- Perbandingan dengan pengiriman berkelanjutan tradisional.
Pada artikel ini kami telah mencoba membahas semua topik ini. Ini memberikan pengenalan terbaru tentang GitOps dan perspektif pengembang dan CI/CD. Kami terutama fokus pada Kubernetes, meskipun modelnya dapat digeneralisasikan.
Temui GitOps
Bayangkan Alice. Dia menjalankan Asuransi Keluarga, yang menawarkan asuransi kesehatan, mobil, rumah, dan perjalanan kepada orang-orang yang terlalu sibuk untuk memikirkan sendiri seluk beluk kontrak. Bisnisnya dimulai sebagai proyek sampingan ketika Alice bekerja di bank sebagai data scientist. Suatu hari dia menyadari bahwa dia dapat menggunakan algoritma komputer canggih untuk menganalisis data dan merumuskan paket asuransi dengan lebih efektif. Investor mendanai proyek tersebut, dan kini perusahaannya menghasilkan lebih dari $20 juta per tahun dan berkembang pesat. Saat ini mempekerjakan 180 orang di berbagai posisi. Ini termasuk tim teknologi yang mengembangkan, memelihara situs web, database, dan menganalisis basis pelanggan. Tim yang terdiri dari 60 orang ini dipimpin oleh Bob, direktur teknis perusahaan.
Tim Bob menerapkan sistem produksi di cloud. Aplikasi inti mereka berjalan di GKE, memanfaatkan Kubernetes di Google Cloud. Selain itu, mereka menggunakan berbagai data dan alat analisis dalam pekerjaan mereka.
Asuransi Keluarga tidak bermaksud menggunakan container, namun terjebak dalam antusiasme Docker. Perusahaan segera mengetahui bahwa GKE mempermudah penerapan cluster untuk menguji fitur baru. Jenkins untuk CI dan Quay ditambahkan untuk mengatur registry container, skrip ditulis untuk Jenkins yang mendorong container dan konfigurasi baru ke GKE.
Beberapa waktu telah berlalu. Alice dan Bob kecewa dengan kinerja pendekatan yang mereka pilih dan dampaknya terhadap bisnis. Pengenalan kontainer tidak meningkatkan produktivitas sebanyak yang diharapkan tim. Terkadang penerapan akan terhenti, dan tidak jelas apakah perubahan kode adalah penyebabnya. Ternyata sulit juga melacak perubahan konfigurasi. Seringkali perlu membuat cluster baru dan memindahkan aplikasi ke dalamnya, karena ini adalah cara termudah untuk menghilangkan kekacauan yang terjadi pada sistem. Alice takut situasinya akan menjadi lebih buruk seiring dengan berkembangnya aplikasi (selain itu, proyek baru berdasarkan pembelajaran mesin sedang dibuat). Bob telah mengotomatiskan sebagian besar pekerjaan dan tidak memahami mengapa saluran pipa masih tidak stabil, tidak dapat diukur dengan baik, dan memerlukan intervensi manual secara berkala?
Kemudian mereka belajar tentang GitOps. Keputusan ini ternyata merupakan hal yang mereka butuhkan untuk maju dengan percaya diri.
Alice dan Bob telah mendengar tentang Git, DevOps, dan infrastruktur sebagai alur kerja kode selama bertahun-tahun. Yang unik dari GitOps adalah ia menghadirkan serangkaian praktik terbaik—baik yang definitif maupun normatif—untuk mengimplementasikan ide-ide ini dalam konteks Kubernetes. Tema ini , termasuk di .
Asuransi Keluarga memutuskan untuk menerapkan GitOps. Perusahaan sekarang memiliki model operasi otomatis yang kompatibel dengan Kubernetes dan gabungannya kecepatan dengan stabilitaskarena mereka:
- menemukan bahwa produktivitas tim meningkat dua kali lipat tanpa ada yang menjadi gila;
- berhenti menyajikan skrip. Sebaliknya, mereka kini dapat fokus pada fitur-fitur baru dan meningkatkan teknik teknis - misalnya, menerapkan peluncuran canary dan meningkatkan pengujian;
- kami telah meningkatkan proses penerapan sehingga jarang terjadi kegagalan;
- mendapat kesempatan untuk memulihkan penerapan setelah kegagalan sebagian tanpa intervensi manual;
- dibeli bekasоKepercayaan yang lebih besar pada sistem pengiriman. Alice dan Bob menemukan bahwa mereka dapat membagi tim menjadi tim layanan mikro yang bekerja secara paralel;
- dapat membuat 30-50 perubahan pada proyek setiap hari melalui upaya masing-masing kelompok dan mencoba teknik baru;
- mudah untuk menarik pengembang baru ke proyek, yang memiliki kesempatan untuk meluncurkan pembaruan produksi menggunakan permintaan tarik dalam beberapa jam;
- dengan mudah lulus audit dalam kerangka SOC2 (untuk kepatuhan penyedia layanan terhadap persyaratan pengelolaan data yang aman; baca lebih lanjut, misalnya, - kira-kira. terjemahkan).
Apa yang terjadi?
GitOps adalah dua hal:
- Model operasional untuk Kubernetes dan cloud native. Ini memberikan serangkaian praktik terbaik untuk menerapkan, mengelola, dan memantau klaster dan aplikasi dalam container. Definisi elegan dalam bentuk dari :
- Jalur untuk menciptakan lingkungan manajemen aplikasi yang berpusat pada pengembang. Kami menerapkan alur kerja Git untuk operasi dan pengembangan. Harap dicatat bahwa ini bukan hanya tentang Git push, tetapi tentang mengatur seluruh rangkaian alat CI/CD dan UI/UX.
Beberapa kata tentang Git
Jika Anda belum terbiasa dengan sistem kontrol versi dan alur kerja berbasis Git, kami sangat menyarankan untuk mempelajarinya. Bekerja dengan cabang dan permintaan tarik mungkin tampak seperti ilmu hitam pada awalnya, namun manfaatnya sepadan dengan usaha yang dilakukan. Di Sini untuk memulai.
Cara kerja Kubernetes
Dalam cerita kami, Alice dan Bob beralih ke GitOps setelah bekerja dengan Kubernetes selama beberapa waktu. Memang benar, GitOps terkait erat dengan Kubernetes - ini adalah model operasional untuk infrastruktur dan aplikasi berdasarkan Kubernetes.
Apa yang diberikan Kubernetes kepada pengguna?
Berikut adalah beberapa fitur utama:
- Dalam model Kubernetes, segala sesuatu dapat digambarkan dalam bentuk deklaratif.
- Server API Kubernetes mengambil deklarasi ini sebagai input dan kemudian terus berupaya untuk membawa cluster ke keadaan yang dijelaskan dalam deklarasi.
- Deklarasi cukup untuk mendeskripsikan dan mengelola berbagai macam beban kerja—“aplikasi”.
- Akibatnya terjadi perubahan pada aplikasi dan cluster yang disebabkan oleh:
- perubahan pada gambar kontainer;
- perubahan spesifikasi deklaratif;
- kesalahan di lingkungan - misalnya, kontainer mogok.
Kemampuan Konvergensi Kubernetes yang Luar Biasa
Ketika administrator membuat perubahan konfigurasi, orkestrator Kubernetes akan menerapkannya ke cluster selama statusnya berlaku tidak akan mendekati konfigurasi baru. Model ini berfungsi untuk semua sumber daya Kubernetes dan dapat diperluas dengan Definisi Sumber Daya Kustom (CRD). Oleh karena itu, penerapan Kubernetes memiliki properti luar biasa berikut:
- Otomasi: Pembaruan Kubernetes menyediakan mekanisme untuk mengotomatiskan proses penerapan perubahan dengan baik dan tepat waktu.
- Konvergensi: Kubernetes akan terus mencoba pembaruan hingga berhasil.
- Idempotensi: Penerapan konvergensi berulang kali menghasilkan hasil yang sama.
- Determinisme: Ketika sumber daya mencukupi, status klaster yang diperbarui hanya bergantung pada status yang diinginkan.
Cara kerja GitOps
Kami telah cukup belajar tentang Kubernetes untuk menjelaskan cara kerja GitOps.
Mari kembali ke tim layanan mikro Asuransi Keluarga. Apa yang biasanya harus mereka lakukan? Lihatlah daftar di bawah ini (jika ada item di dalamnya yang terasa aneh atau familier, harap berhenti mengkritik dan tetap bersama kami). Ini hanyalah contoh alur kerja berbasis Jenkins. Ada banyak proses lain saat bekerja dengan alat lain.
Hal utama adalah kita melihat bahwa setiap pembaruan diakhiri dengan perubahan pada file konfigurasi dan repositori Git. Perubahan pada Git ini menyebabkan "operator GitOps" memperbarui klaster:
1.Proses kerja: "Jenkins build - cabang master'.
Daftar tugas:
- Jenkins mendorong gambar yang diberi tag ke Quay;
- Jenkins memasukkan diagram konfigurasi dan Helm ke bucket penyimpanan utama;
- Fungsi cloud menyalin konfigurasi dan bagan dari bucket penyimpanan utama ke repositori master Git;
- Operator GitOps memperbarui cluster.
2. Jenkins build - cabang rilis atau perbaikan terbaru:
- Jenkins mengirimkan gambar yang tidak diberi tag ke Quay;
- Jenkins mendorong diagram konfigurasi dan Helm ke bucket penyimpanan pementasan;
- Fungsi cloud menyalin konfigurasi dan bagan dari bucket penyimpanan staging ke repositori Git staging;
- Operator GitOps memperbarui cluster.
3. Jenkins build - mengembangkan atau menampilkan cabang:
- Jenkins mengirimkan gambar yang tidak diberi tag ke Quay;
- Jenkins memasukkan diagram konfigurasi dan Helm ke dalam keranjang penyimpanan pengembangan;
- Fungsi cloud menyalin konfigurasi dan bagan dari bucket penyimpanan pengembangan ke repositori Git pengembangan;
- Operator GitOps memperbarui cluster.
4. Menambahkan klien baru:
- Manajer atau administrator (LCM/ops) memanggil Gradle untuk menerapkan dan mengonfigurasi penyeimbang beban jaringan (NLB) terlebih dahulu;
- LCM/ops melakukan konfigurasi baru untuk mempersiapkan penerapan pembaruan;
- Operator GitOps memperbarui cluster.
Deskripsi singkat tentang GitOps
- Jelaskan keadaan yang diinginkan dari keseluruhan sistem menggunakan spesifikasi deklaratif untuk setiap lingkungan (dalam cerita kita, tim Bob mendefinisikan seluruh konfigurasi sistem di Git).
- Repositori Git adalah satu-satunya sumber kebenaran mengenai keadaan yang diinginkan dari keseluruhan sistem.
- Semua perubahan pada keadaan yang diinginkan dilakukan melalui penerapan di Git.
- Semua parameter cluster yang diinginkan juga dapat diamati di cluster itu sendiri. Dengan cara ini kita dapat menentukan apakah keduanya berhimpitan (konvergen, bertemu) atau berbeda (menyimpang, menyimpang) keadaan yang diinginkan dan diamati.
- Jika keadaan yang diinginkan dan yang diamati berbeda, maka:
- Ada mekanisme konvergensi yang cepat atau lambat secara otomatis menyinkronkan target dan keadaan yang diamati. Di dalam cluster, Kubernetes melakukan hal ini.
- Prosesnya segera dimulai dengan peringatan “perubahan yang dilakukan”.
- Setelah beberapa periode waktu yang dapat dikonfigurasi, peringatan "diff" dapat dikirim jika statusnya berbeda.
- Dengan cara ini, semua penerapan di Git menyebabkan pembaruan yang dapat diverifikasi dan idempoten pada klaster.
- Rollback adalah konvergensi ke keadaan yang diinginkan sebelumnya.
- Konvergensi ini bersifat final. Kemunculannya ditunjukkan oleh:
- Tidak ada peringatan perbedaan untuk jangka waktu tertentu.
- peringatan "terkonvergensi" (misalnya webhook, acara tulis balik Git).
Apa itu divergensi?
Mari kita ulangi lagi: semua properti cluster yang diinginkan harus dapat diamati di cluster itu sendiri.
Beberapa contoh divergensi:
- Perubahan file konfigurasi karena penggabungan cabang di Git.
- Perubahan pada file konfigurasi karena penerapan Git yang dilakukan oleh klien GUI.
- Beberapa perubahan pada keadaan yang diinginkan karena PR di Git diikuti dengan pembuatan gambar container dan perubahan konfigurasi.
- Perubahan keadaan cluster karena kesalahan, konflik sumber daya yang mengakibatkan "perilaku buruk", atau sekadar penyimpangan acak dari keadaan semula.
Bagaimana mekanisme konvergensi?
Beberapa contoh:
- Untuk container dan cluster, mekanisme konvergensi disediakan oleh Kubernetes.
- Mekanisme yang sama dapat digunakan untuk mengelola aplikasi dan desain berbasis Kubernetes (seperti Istio dan Kubeflow).
- Mekanisme untuk mengelola interaksi operasional antara Kubernetes, repositori image, dan Git disediakan , yang merupakan bagian .
- Untuk mesin dasar, mekanisme konvergensi harus bersifat deklaratif dan otonom. Dari pengalaman kami sendiri, kami dapat mengatakan itu paling dekat dengan definisi ini, namun masih memerlukan kendali manusia. Dalam hal ini, GitOps memperluas tradisi Infrastruktur sebagai Kode.
GitOps menggabungkan Git dengan mesin konvergensi Kubernetes yang luar biasa untuk menyediakan model eksploitasi.
GitOps memungkinkan kami mengatakan: Hanya sistem yang dapat dijelaskan dan diamati yang dapat diotomatisasi dan dikendalikan.
GitOps ditujukan untuk seluruh tumpukan cloud native (misalnya, Terraform, dll.)
GitOps bukan hanya Kubernetes. Kami ingin seluruh sistem dijalankan secara deklaratif dan menggunakan konvergensi. Yang kami maksud dengan keseluruhan sistem adalah kumpulan lingkungan yang bekerja dengan Kubernetes - misalnya, "dev cluster 1", "produksi", dll. Setiap lingkungan mencakup mesin, cluster, aplikasi, serta antarmuka untuk layanan eksternal yang menyediakan data, pemantauan dan sebagainya.
Perhatikan betapa pentingnya Terraform terhadap masalah bootstrap dalam kasus ini. Kubernetes harus di-deploy di suatu tempat, dan dengan menggunakan Terraform berarti kita dapat menerapkan alur kerja GitOps yang sama untuk membuat lapisan kontrol yang mendukung Kubernetes dan aplikasi. Ini adalah praktik terbaik yang berguna.
Ada fokus yang kuat dalam penerapan konsep GitOps pada lapisan di atas Kubernetes. Saat ini, terdapat solusi tipe GitOps untuk Istio, Helm, Ksonnet, OpenFaaS dan Kubeflow, serta, misalnya, untuk Pulumi, yang membuat lapisan untuk mengembangkan aplikasi untuk cloud native.
Kubernetes CI/CD: membandingkan GitOps dengan pendekatan lain
Seperti yang dinyatakan, GitOps adalah dua hal:
- Model operasi untuk Kubernetes dan cloud native dijelaskan di atas.
- Jalan menuju lingkungan manajemen aplikasi yang berpusat pada pengembang.
Bagi banyak orang, GitOps pada dasarnya adalah alur kerja yang didasarkan pada dorongan Git. Kami juga menyukainya. Namun bukan itu saja: sekarang mari kita lihat pipeline CI/CD.
GitOps memungkinkan penerapan berkelanjutan (CD) untuk Kubernetes
GitOps menawarkan mekanisme penerapan berkelanjutan yang menghilangkan kebutuhan akan “sistem manajemen penerapan” terpisah. Kubernetes melakukan semua pekerjaan untuk Anda.
- Memperbarui aplikasi memerlukan pembaruan di Git. Ini adalah pembaruan transaksional ke keadaan yang diinginkan. "Deployment" kemudian dilakukan di dalam cluster oleh Kubernetes sendiri berdasarkan deskripsi yang diperbarui.
- Karena sifat cara kerja Kubernetes, pembaruan ini bersifat konvergen. Ini menyediakan mekanisme untuk penerapan berkelanjutan di mana semua pembaruan bersifat atomik.
- Catatan: menawarkan operator GitOps yang mengintegrasikan Git dan Kubernetes dan memungkinkan CD dijalankan dengan merekonsiliasi status cluster yang diinginkan dan saat ini.
Tanpa kubectl dan skrip
Anda harus menghindari penggunaan Kubectl untuk memperbarui klaster Anda, dan terutama menghindari penggunaan skrip untuk mengelompokkan perintah kubectl. Sebaliknya, dengan pipeline GitOps, pengguna dapat memperbarui cluster Kubernetes mereka melalui Git.
Manfaat meliputi:
- Benar. Sekelompok pembaruan dapat diterapkan, dikonvergensi, dan akhirnya divalidasi, sehingga membawa kita lebih dekat ke tujuan penerapan atom. Sebaliknya, penggunaan skrip tidak memberikan jaminan konvergensi (lebih lanjut tentang ini di bawah).
- keamanan. Kelsey Hightower: “Batasi akses ke klaster Kubernetes Anda hanya pada alat otomatisasi dan administrator yang bertanggung jawab untuk melakukan debug atau memeliharanya.” Lihat juga tentang keselamatan dan kepatuhan terhadap spesifikasi teknis, serta dengan mencuri kredensial dari skrip Jenkins yang ditulis secara sembarangan.
- Pengalaman pengguna. Kubectl memaparkan mekanisme model objek Kubernetes yang cukup kompleks. Idealnya, pengguna harus berinteraksi dengan sistem pada tingkat abstraksi yang lebih tinggi. Di sini saya akan kembali merujuk ke Kelsey dan merekomendasikan menonton .
Perbedaan CI dan CD
GitOps meningkatkan model CI/CD yang ada.
Server CI modern adalah alat orkestrasi. Secara khusus, ini adalah alat untuk mengatur pipeline CI. Ini termasuk pembuatan, pengujian, penggabungan ke trunk, dll. Server CI mengotomatiskan pengelolaan pipeline multi-langkah yang kompleks. Godaan yang umum adalah membuat skrip serangkaian pembaruan Kubernetes dan menjalankannya sebagai bagian dari pipeline untuk mendorong perubahan pada cluster. Memang, inilah yang dilakukan banyak ahli. Namun, hal ini tidak optimal, dan inilah alasannya.
CI harus digunakan untuk mendorong pembaruan ke trunk, dan cluster Kubernetes harus mengubah dirinya sendiri berdasarkan pembaruan tersebut untuk mengelola CD secara internal. Kami menyebutnya , tidak seperti model dorongan CI. CD adalah bagian orkestrasi waktu proses.
Mengapa Server CI Tidak Harus Melakukan CD melalui Pembaruan Langsung di Kubernetes
Jangan gunakan server CI untuk mengatur pembaruan langsung ke Kubernetes sebagai serangkaian tugas CI. Ini adalah anti-pola yang sedang kita bicarakan di blog Anda.
Mari kita kembali ke Alice dan Bob.
Masalah apa yang mereka hadapi? Server CI Bob menerapkan perubahan pada cluster, tetapi jika crash dalam prosesnya, Bob tidak akan mengetahui status cluster tersebut (atau seharusnya) atau bagaimana cara memperbaikinya. Hal yang sama berlaku jika berhasil.
Mari kita asumsikan bahwa tim Bob membuat image baru dan kemudian melakukan patch penerapannya untuk menyebarkan image tersebut (semuanya dari pipeline CI).
Jika gambar dibuat secara normal, tetapi alurnya gagal, tim harus mencari tahu:
- Apakah pembaruan sudah diluncurkan?
- Apakah kita meluncurkan bangunan baru? Apakah ini akan menimbulkan efek samping yang tidak perlu - dengan kemungkinan memiliki dua build dari gambar yang sama dan tidak dapat diubah?
- Haruskah kita menunggu pembaruan berikutnya sebelum menjalankan build?
- Apa sebenarnya yang salah? Langkah mana yang perlu diulangi (dan langkah mana yang aman untuk diulangi)?
Menetapkan alur kerja berbasis Git tidak menjamin bahwa tim Bob tidak akan menghadapi masalah ini. Mereka masih bisa membuat kesalahan dengan commit push, tag, atau parameter lainnya; namun, pendekatan ini masih lebih mendekati pendekatan eksplisit semua atau tidak sama sekali.
Ringkasnya, inilah alasan server CI tidak boleh berurusan dengan CD:
- Skrip pembaruan tidak selalu bersifat deterministik; Sangat mudah untuk membuat kesalahan di dalamnya.
- Server CI tidak menyatu dengan model cluster deklaratif.
- Sulit untuk menjamin idempotensi. Pengguna harus memahami semantik mendalam dari sistem.
- Lebih sulit untuk pulih dari kegagalan sebagian.
Catatan tentang Helm: Jika Anda ingin menggunakan Helm, kami sarankan untuk menggabungkannya dengan operator GitOps seperti . Hal ini akan membantu memastikan konvergensi. Helm sendiri tidak bersifat deterministik atau atomik.
GitOps sebagai cara terbaik untuk mengimplementasikan Pengiriman Berkelanjutan untuk Kubernetes
Tim Alice dan Bob mengimplementasikan GitOps dan menemukan bahwa bekerja dengan produk perangkat lunak menjadi lebih mudah, menjaga kinerja dan stabilitas tinggi. Mari akhiri artikel ini dengan ilustrasi yang menunjukkan seperti apa pendekatan baru mereka. Ingatlah bahwa kita kebanyakan berbicara tentang aplikasi dan layanan, tetapi GitOps dapat digunakan untuk mengelola seluruh platform.
Model operasi untuk Kubernetes
Lihatlah diagram berikut. Ini menyajikan Git dan repositori gambar kontainer sebagai sumber daya bersama untuk dua siklus hidup yang diatur:
- Alur integrasi berkelanjutan yang membaca dan menulis file ke Git dan dapat memperbarui repositori gambar kontainer.
- Pipeline Runtime GitOps yang menggabungkan penerapan dengan manajemen dan observabilitas. Ia membaca dan menulis file ke Git dan dapat mengunduh gambar container.
Apa temuan utamanya?
- Pemisahan kekhawatiran: Harap dicatat bahwa kedua saluran pipa hanya dapat berkomunikasi dengan memperbarui Git atau repositori gambar. Dengan kata lain, terdapat firewall antara CI dan lingkungan runtime. Kami menyebutnya "firewall kekekalan" (firewall kekekalan), karena semua pembaruan repositori membuat versi baru. Untuk informasi lebih lanjut mengenai topik ini, lihat slide 72-87 .
- Anda dapat menggunakan server CI dan Git apa pun: GitOps berfungsi dengan komponen apa pun. Anda dapat terus menggunakan server CI dan Git favorit Anda, repositori gambar, dan rangkaian pengujian. Hampir semua alat Pengiriman Berkelanjutan lainnya di pasaran memerlukan server CI/Git atau repositori gambarnya sendiri. Hal ini mungkin menjadi faktor pembatas dalam pengembangan cloud native. Dengan GitOps, Anda dapat menggunakan alat yang sudah dikenal.
- Acara sebagai alat integrasi: Segera setelah data di Git diperbarui, Weave Flux (atau operator Weave Cloud) memberi tahu waktu proses. Setiap kali Kubernetes menerima kumpulan perubahan, Git akan diperbarui. Ini memberikan model integrasi sederhana untuk mengatur alur kerja untuk GitOps, seperti yang ditunjukkan di bawah ini.
Kesimpulan
GitOps memberikan jaminan pembaruan kuat yang diperlukan oleh alat CI/CD modern apa pun:
- otomatisasi;
- konvergensi;
- idempotensi;
- determinisme.
Hal ini penting karena menawarkan model operasional untuk pengembang cloud native.
- Alat tradisional untuk mengelola dan memantau sistem dikaitkan dengan tim operasi yang beroperasi dalam runbook (seperangkat prosedur dan operasi rutin - kira-kira terjemahan), terkait dengan penerapan tertentu.
- Dalam pengelolaan cloud native, alat observabilitas adalah cara terbaik untuk mengukur hasil penerapan sehingga tim pengembangan dapat merespons dengan cepat.
Bayangkan banyak cluster yang tersebar di berbagai cloud dan banyak layanan dengan tim dan rencana penerapannya sendiri. GitOps menawarkan model invarian skala untuk mengelola semua kelimpahan ini.
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «'.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Tahukah Anda tentang GitOps sebelum kedua terjemahan ini muncul di Habré?
-
Ya, saya tahu segalanya
-
Hanya secara dangkal
-
Tidak
35 pengguna memilih. 10 pengguna abstain.
Sumber: www.habr.com