Geekly articles weekly

Apa itu GitOps?

Catatan perev. : Setelah publikasi materi tentang metode pull and push baru-baru ini di GitOps, kami melihat minat pada model ini secara keseluruhan, namun, ada sangat sedikit publikasi berbahasa Rusia tentang topik ini (mereka tidak ada di hub). Oleh karena itu, kami dengan senang hati memberikan terjemahan dari artikel lain - meskipun hampir setahun yang lalu! - dari Weaveworks perusahaan, kepala yang menciptakan istilah "GitOps". Teks menjelaskan esensi dari pendekatan dan perbedaan utama dari yang ada.



Setahun yang lalu, kami menerbitkan pengantar untuk GitOps . Kemudian kami berbicara tentang bagaimana tim Weaveworks meluncurkan SaaS yang berbasis di Kubernetes, dan mengembangkan serangkaian praktik terbaik preskriptif untuk penggelaran, pengelolaan, dan pemantauan di lingkungan asli cloud.

Artikel itu ternyata populer. Orang lain mulai berbicara tentang GitOps, mulai menerbitkan alat baru untuk git push , pengembangan , rahasia , fungsi , integrasi berkelanjutan , dll. Sejumlah besar publikasi dan kasus penggunaan GitOps telah muncul di situs kami. Tetapi beberapa orang masih memiliki pertanyaan. Bagaimana model berbeda dari infrastruktur tradisional sebagai kode dan pengiriman berkelanjutan? Apakah wajib menggunakan Kubernetes?

Segera, kami menyadari bahwa diperlukan deskripsi baru, menawarkan:

  1. Sejumlah besar contoh dan cerita;
  2. Definisi spesifik GitOps;
  3. Perbandingan dengan pengiriman berkelanjutan tradisional.

Pada artikel ini, kami mencoba membahas semua topik ini. Di dalamnya Anda akan menemukan pengantar yang diperbarui untuk GitOps dan melihatnya dari sisi pengembang dan CI / CD. Kami terutama berfokus pada Kubernetes, meskipun modelnya dapat digeneralisasi.

Temui GitOps


Bayangkan Alice. Dia menjalankan Asuransi Keluarga, sebuah perusahaan yang menawarkan polis asuransi kesehatan, mobil, real estat, dan perjalanan untuk orang-orang yang terlalu sibuk untuk memahami nuansa kontrak mereka sendiri. Bisnisnya dimulai sebagai proyek sampingan ketika Alice bekerja di bank sebagai ilmuwan data. Setelah dia menyadari bahwa dia dapat menggunakan algoritma komputer canggih untuk menganalisis data dan membentuk paket asuransi dengan lebih efisien. Investor mendanai proyek tersebut, dan sekarang perusahaannya mendatangkan lebih dari $ 20 juta per tahun dan berkembang pesat. Saat ini, 180 orang bekerja di berbagai posisi di dalamnya. Di antara mereka, tim teknologi yang mengembangkan, memelihara situs, database, dan menganalisis basis klien. Sebuah tim yang terdiri dari 60 orang dipimpin oleh Bob, direktur teknis perusahaan.

Tim Bob sedang menyebarkan sistem produksi di cloud. Aplikasi utama mereka berjalan pada GKE, memanfaatkan Kubernetes di Google Cloud. Selain itu, mereka menggunakan berbagai alat untuk bekerja dengan data dan analitik dalam pekerjaan mereka.

Asuransi Keluarga tidak akan menggunakan wadah, tetapi terinfeksi dengan antusiasme untuk Docker. Segera, para ahli perusahaan menemukan bahwa GKE memudahkan dan mudah untuk menggunakan cluster untuk menguji fitur-fitur baru. Jenkins untuk CI dan Quay ditambahkan untuk mengatur registrasi kontainer, skrip untuk Jenkins ditulis yang mendorong atau kontainer baru dan konfigurasi di GKE.

Beberapa waktu telah berlalu. Alice dan Bob kecewa dengan kinerja pendekatan yang dipilih dan dampaknya pada bisnis. Pengenalan kontainer tidak meningkatkan produktivitas sebanyak yang diharapkan tim. Kadang-kadang penyebaran rusak, dan tidak jelas apakah perubahan kode harus disalahkan. Ternyata sulit melacak perubahan pada konfigurasi. Seringkali itu perlu untuk membuat cluster baru dan memindahkan aplikasi ke dalamnya, karena itu adalah cara termudah untuk menghilangkan kekacauan ke mana sistem berubah. Alice takut situasinya akan memburuk ketika aplikasi dikembangkan (selain itu, sebuah proyek baru berdasarkan pembelajaran mesin sedang dibuat). Bob mengotomatiskan sebagian besar pekerjaan dan tidak mengerti mengapa pipa masih tidak stabil, tidak skala dengan baik dan memerlukan intervensi manual dari waktu ke waktu?

Kemudian mereka belajar tentang GitOps. Keputusan ini ternyata persis seperti yang mereka butuhkan untuk maju dengan percaya diri.

Alice dan Bob telah mendengar tentang alur kerja berdasarkan Git, DevOps, dan infrastruktur sebagai kode selama bertahun-tahun. Keunikan GitOps adalah bahwa ia membawa sejumlah praktik terbaik - kategoris dan normatif - untuk mengimplementasikan ide-ide ini dalam konteks Kubernetes. Topik ini telah diangkat berulang kali , termasuk di blog Weaveworks .

Asuransi Keluarga memutuskan untuk menerapkan GitOps. Perusahaan sekarang memiliki model operasi otomatis yang kompatibel dengan Kubernetes yang menggabungkan kecepatan dengan stabilitas , karena mereka:

  • menemukan bahwa tim tersebut menggandakan produktivitas dan tidak ada yang menjadi gila;
  • menghentikan skrip servis. Sebaliknya, mereka sekarang dapat berkonsentrasi pada fitur-fitur baru dan meningkatkan metode teknik - misalnya, memperkenalkan peluncuran kenari dan meningkatkan pengujian;
  • proses penyebaran yang lebih baik - sekarang jarang putus;
  • mendapat kesempatan untuk memulihkan penyebaran setelah kegagalan parsial tanpa intervensi manual;
  • memperoleh kepercayaan yang lebih besar dalam sistem pasokan. Alice dan Bob menemukan bahwa tim dapat dibagi menjadi kelompok-kelompok yang bekerja dalam layanan mikro dan bekerja secara paralel;
  • dapat membuat 30-50 perubahan pada proyek setiap hari dengan upaya masing-masing kelompok dan mencoba teknik baru;
  • mereka mudah tertarik pada proyek oleh pengembang baru yang memiliki kemampuan untuk meluncurkan pembaruan pada produksi menggunakan permintaan tarik dalam beberapa jam;
  • mudah diaudit dalam SOC2 (untuk kepatuhan penyedia layanan dengan persyaratan untuk manajemen data yang aman; baca lebih lanjut, misalnya, di sini - sekitar terjemahan) .

Apa yang terjadi


GitOps adalah dua hal:

  1. Model operasi untuk Kubernet dan cloud asli. Ini memberikan seperangkat praktik terbaik untuk mengerahkan, mengelola, dan memantau kelompok dan aplikasi kemas. Definisi elegan dalam satu slide dari Luis Faceira :

  2. Jalur untuk menciptakan lingkungan yang berorientasi pengembang untuk mengelola aplikasi. Kami menerapkan alur kerja Git untuk eksploitasi 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 tidak terbiasa dengan sistem kontrol versi dan alur kerja berbasis Git, kami sangat menyarankan agar Anda mempelajarinya. Pada awalnya, bekerja dengan cabang dan menarik permintaan mungkin tampak seperti ilmu hitam, tetapi para profesional sepadan dengan usaha tersebut. Berikut ini adalah artikel yang bagus untuk membantu Anda memulai.

Cara Kerja Kubernetes


Dalam cerita kami, Alice dan Bob menoleh ke GitOps setelah bekerja dengan Kubernetes untuk sementara waktu. Memang, GitOps terkait erat dengan Kubernetes - ini adalah model operasional untuk infrastruktur dan aplikasi berdasarkan Kubernetes.

Apa yang diberikan Kubernet kepada pengguna?


Berikut adalah beberapa fitur utama:

  1. Dalam model Kubernetes, semuanya dapat dijelaskan dalam bentuk deklaratif.
  2. Server API Kubernetes menerima deklarasi seperti itu sebagai input, dan kemudian terus-menerus mencoba untuk membawa cluster ke negara yang dijelaskan dalam deklarasi.
  3. Deklarasi cukup untuk menggambarkan dan mengelola berbagai macam beban kerja - "aplikasi."
  4. Akibatnya, perubahan pada aplikasi dan cluster disebabkan oleh:
    • perubahan pada gambar kontainer;
    • perubahan spesifikasi deklaratif;
    • kesalahan di lingkungan - misalnya, wadah macet.

Kemampuan konvergensi Kubernet yang hebat


Ketika seorang administrator membuat perubahan konfigurasi, orkestra Kubernetes akan menerapkannya ke kluster sampai keadaannya mendekati konfigurasi baru . Model ini berfungsi untuk setiap sumber daya Kubernetes dan diperluas dengan Custom Resource Definition (CRDs). Karenanya, penyebaran Kubernetes memiliki sifat-sifat luar biasa berikut:

  • Otomatisasi : Pembaruan Kubernetes menyediakan mekanisme untuk mengotomatiskan proses penerapan perubahan dengan benar dan tepat waktu.
  • Konvergensi : Kubernetes akan terus mencoba pembaruan hingga berhasil.
  • Idempotensi : aplikasi konvergensi yang diulang menghasilkan hasil yang sama.
  • Determinisme : dengan sumber daya yang memadai, keadaan gugus yang diperbarui hanya bergantung pada keadaan yang diinginkan.

Cara Kerja GitOps


Kami telah cukup belajar tentang Kubernetes untuk menjelaskan cara kerja GitOps.

Mari kita kembali ke tim Asuransi Keluarga yang terkait dengan layanan mikro. Apa yang biasanya mereka lakukan? Lihatlah daftar di bawah ini (jika ada poin di dalamnya yang tampak aneh atau asing - silakan tunda kritik dan tetap bersama kami). Ini hanya contoh alur kerja berbasis Jenkins. Ada banyak proses lain saat bekerja dengan alat lain.

Yang utama adalah kita melihat bahwa setiap pembaruan berakhir dengan perubahan pada file konfigurasi dan repositori Git. Perubahan pada Git ini menyebabkan "pernyataan GitOps" memperbarui cluster:

1. Alur Kerja: " Jenkins Build - master branch ".
Daftar tugas:

  • Jenkins mendorong gambar yang ditandai di Quay;
  • Jenkins push'it config dan grafik Helm ke ember penyimpanan utama;
  • Fungsi cloud menyalin konfigurasi dan bagan dari bucket penyimpanan master ke repositori master git;
  • Pernyataan GitOps memperbarui cluster.

2. Jenkins build - release atau cabang perbaikan terbaru :

  • Jenkins mendorong 'gambar tanpa tanda di Quay;
  • Jenkins mendorong grafik konfigurasi dan Helm ke ember penyimpanan staging;
  • Fungsi cloud menyalin konfigurasi dan grafik dari ember penyimpanan staging ke staging repositori Git;
  • Pernyataan GitOps memperbarui cluster.

3. Jenkins build - mengembangkan atau fitur cabang :

  • Jenkins mendorong 'gambar tanpa tanda di Quay;
  • Jenkins mendorong grafik konfigurasi dan Helm ke ember penyimpanan yang dikembangkan;
  • Fungsi cloud menyalin konfigurasi dan bagan dari ember penyimpanan yang dikembangkan ke gudang git yang dikembangkan;
  • Pernyataan GitOps memperbarui cluster.

4. Menambahkan klien baru :

  • Manajer atau administrator (LCM / ops) memanggil Gradle untuk awalnya menyebarkan dan mengkonfigurasi penyeimbang beban jaringan (NLB);
  • LCM / ops melakukan konfigurasi baru untuk menyiapkan penyebaran pembaruan;
  • Pernyataan GitOps memperbarui cluster.

Deskripsi Singkat GitOps


  1. Jelaskan keadaan yang diinginkan dari seluruh sistem menggunakan spesifikasi deklaratif untuk setiap lingkungan (dalam sejarah kami, tim Bob mendefinisikan seluruh konfigurasi sistem di Git).

    • Repositori git adalah satu-satunya sumber kebenaran mengenai keadaan yang diinginkan dari seluruh sistem.
    • Semua perubahan pada status yang diinginkan dilakukan melalui commit di Git.
    • Semua parameter cluster yang diinginkan juga dapat diamati dalam cluster itu sendiri. Dengan demikian, kita dapat menentukan apakah keadaan yang diinginkan dan diamati bertepatan (konvergen, konvergen ) atau berbeda ( diverge , diverge ).
  2. Jika keadaan yang diinginkan dan diamati berbeda, maka:

    • Ada mekanisme konvergensi yang cepat atau lambat menyinkronkan target dan status yang diamati. Di dalam cluster, Kubernetes melakukan ini.
    • Proses dimulai segera dengan pemberitahuan "ubah komitmen".
    • Setelah beberapa periode waktu yang dapat dikonfigurasi, peringatan diff dapat dikirim jika statusnya berbeda.
  3. Dengan demikian, semua komitmen di Git memicu pembaruan yang dapat diverifikasi dan idempoten di kluster.

    • Kembalikan adalah konvergensi ke kondisi yang diinginkan sebelumnya.
  4. Konvergensi adalah final. Tentang permulaannya bersaksi:

    • Kurangnya peringatan "berbeda" untuk jangka waktu tertentu.
    • Peringatan terkonvergensi (misalnya, webhook, acara Git writeback).

Apa itu divergensi?


Kami ulangi lagi: semua properti yang diinginkan dari cluster harus dapat diamati di dalam cluster itu sendiri .

Beberapa contoh perbedaan:

  • Ubah file konfigurasi karena menggabungkan cabang di Git.
  • Perubahan pada file konfigurasi karena komit di Git yang dibuat oleh klien GUI.
  • Beberapa perubahan dalam kondisi yang diinginkan karena PR di Git dengan perakitan gambar wadah berikutnya dan perubahan ke konfigurasi.
  • Perubahan status kelompok karena kesalahan, konflik sumber daya yang mengarah ke "perilaku buruk", atau hanya penyimpangan tidak sengaja dari kondisi awal.

Apa itu mekanisme konvergensi?


Beberapa contoh:

  • Untuk kontainer dan cluster, mekanisme konvergensi menyediakan Kubernetes.
  • Mekanisme yang sama dapat digunakan untuk mengelola aplikasi dan desain berbasis Kubernetes (mis., Istio dan Kubeflow).
  • Mekanisme untuk mengelola interaksi kerja antara Kubernetes, repositori gambar dan Git disediakan oleh operator Weave Flux GitOps , yang merupakan bagian dari Weave Cloud .
  • Untuk mesin dasar, mekanisme konvergensi harus bersifat deklaratif dan otonom. Dari pengalaman kami sendiri, kami dapat mengatakan bahwa Terraform paling dekat dengan definisi ini, tetapi masih membutuhkan kontrol manusia. Dalam hal ini, GitOps memperluas tradisi Infrastruktur sebagai Kode.

GitOps menggabungkan Git dengan mesin konvergensi Kubernet yang sangat baik, menawarkan model untuk operasi.

GitOps memungkinkan kita untuk menyatakan bahwa hanya sistem yang dapat dijelaskan dan diamati yang dapat diotomatisasi dan dikendalikan .

GitOps adalah untuk seluruh tumpukan cloud asli (mis. Terraform, dll.)


GitOps bukan hanya Kubernetes. Kami ingin seluruh sistem dikelola secara deklaratif dan menggunakan konvergensi. Yang kami maksud dengan seluruh sistem adalah seperangkat lingkungan yang bekerja dengan Kubernetes - misalnya, "dev cluster 1", "produksi", dll. Setiap lingkungan mencakup mesin, kluster, aplikasi, serta antarmuka untuk layanan eksternal yang menyediakan data, pemantauan, dan dll.

Perhatikan bagaimana Terraform penting dalam kasus ini untuk masalah bootstrap. Kubernet perlu dikerahkan di suatu tempat, dan menggunakan Terraform berarti kita dapat menggunakan alur kerja GitOps yang sama untuk membuat lapisan kontrol yang mendasari Kubernet dan aplikasi. Ini adalah praktik terbaik yang baik.

Banyak perhatian diberikan untuk menerapkan konsep GitOps ke lapisan di atas Kubernetes. Saat ini ada solusi tipe GitOps untuk Istio, Helm, Ksonnet, OpenFaaS dan Kubeflow, serta, misalnya, Pulumi, yang membuat lapisan untuk mengembangkan aplikasi untuk cloud asli.

Kubernetes CI / CD: membandingkan GitOps dengan pendekatan lain


Seperti yang dinyatakan, GitOps adalah dua hal:

  1. Model operasional untuk Kubernet dan cloud asli yang dijelaskan di atas.
  2. Jalur untuk mengatur lingkungan manajemen aplikasi yang berpusat pada pengembang.

Bagi banyak orang, GitOps terutama alur kerja berbasis push Git. Kami juga menyukainya. Tapi ini belum semuanya: sekarang mari kita lihat jalur pipa CI / CD.

GitOps Menyediakan Penyebaran Berkelanjutan (CD) untuk Kubernetes


GitOps menawarkan mekanisme penyebaran berkelanjutan yang menghilangkan kebutuhan akan "sistem manajemen penempatan" yang terpisah. Kubernetes melakukan semua pekerjaan untuk Anda.

  • Memperbarui aplikasi memerlukan pembaruan di Git. Ini adalah peningkatan transaksional ke kondisi yang diinginkan. "Penyebaran" kemudian dilakukan di dalam cluster oleh Kubernetes sendiri berdasarkan deskripsi yang diperbarui.
  • Karena kekhasan Kubernetes, pembaruan ini bersifat konvergen. Ini memberikan mekanisme untuk penerapan berkelanjutan di mana semua pembaruan bersifat atomik.
  • Catatan: Weave Cloud menawarkan operator GitOps yang mengintegrasikan Git dan Kubernetes dan memungkinkan Anda untuk menjalankan CD dengan mencocokkan kondisi cluster yang diinginkan dan saat ini.

Tanpa kubectl dan skrip


Hindari menggunakan Kubectl untuk meningkatkan cluster, dan terutama skrip untuk mengelompokkan perintah kubectl. Sebagai gantinya, dengan pipa GitOps, pengguna dapat memutakhirkan kluster Kubernetes mereka melalui Git.

Manfaat meliputi:

  1. Kebenaran . Sekelompok pembaruan dapat diterapkan, konvergen dan akhirnya divalidasi, yang membawa kita lebih dekat ke tujuan penyebaran atom. Sebaliknya, penggunaan skrip tidak memberikan jaminan konvergensi (lebih lanjut tentang ini di bawah).
  2. Keamanan Mengutip Kelsey Hightower: "Batasi akses ke kluster Kubernetes ke alat otomatisasi dan administrator yang bertanggung jawab atas debugging atau pemeliharaannya." Lihat juga publikasi saya tentang keamanan dan kepatuhan, serta artikel tentang meretas Homebrew dengan mencuri kredensial dari skrip Jenkins yang ditulis dengan ceroboh.
  3. 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 melihat resume seperti itu .

Perbedaan antara CI dan CD


GitOps meningkat pada model CI / CD yang ada.

Server CI modern adalah instrumen untuk orkestrasi. Secara khusus, ini adalah instrumen untuk mengatur jaringan pipa CI. Mereka termasuk membangun, menguji, menggabungkan ke trunk, dll. Server CI mengotomatiskan pengelolaan jaringan pipa multi-langkah yang kompleks. Godaan yang umum adalah membuat skrip untuk kumpulan pembaruan Kubernetes dan menjalankannya sebagai elemen pipa untuk mendorong perubahan pada cluster. Memang, inilah yang dilakukan banyak ahli. Namun, ini tidak optimal, dan inilah alasannya.

CI harus digunakan untuk membuat pembaruan ke trunk, dan kluster Kubernetes harus berubah sendiri berdasarkan pembaruan ini untuk mengelola CD “secara internal”. Kami menyebutnya model tarik untuk CD , tidak seperti model push CI. CD adalah bagian dari orkestrasi runtime .

Mengapa Server CI Tidak Harus Membuat CD Melalui Pembaruan Langsung di Kubernetes


Jangan gunakan server CI untuk mengatur pembaruan langsung di Kubernetes sebagai serangkaian tugas CI. Ini adalah anti-pola yang sudah kita bicarakan di blog kita.

Mari kita kembali ke Alice dan Bob.

Masalah apa yang mereka hadapi? Server CI Bob menerapkan perubahan pada cluster, tetapi jika crash selama proses, Bob tidak akan tahu status cluster mana (atau seharusnya) dan bagaimana cara memperbaikinya. Hal yang sama berlaku jika berhasil.

Mari kita asumsikan bahwa tim Bob mengumpulkan gambar baru dan kemudian menambal penyebaran mereka untuk menyebarkan gambar (semua dari pipa CI).

Jika gambar dibangun secara normal, tetapi pipa jatuh, tim harus mencari tahu:

  • Apakah pembaruan telah digunakan?
  • Apakah kita memulai bangunan baru? — ?
  • , ?
  • ? ( )?

Git' , . - push' , - ; --.

, CI- CD:

  • ; .
  • CI- .
  • . .
  • .

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes


GitOps , , . , , . , , GitOps .

Kubernetes


. Git :

  • , Git .
  • Runtime GitOps, . Git .



?


  1. : , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
  2. CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
  3. : Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .



Kesimpulan


GitOps , CI/CD:

  • ;
  • ;
  • ;
  • .

, cloud native.

  • , runbook' ( — . .) , deployment'.
  • cloud native- , .

, . GitOps - .

PS dari penerjemah


Baca juga di blog kami:

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

More articles:


All Articles