GitOps: satu lagi kata kunci atau kejayaan dalam automasi?

Kebanyakan daripada kita, melihat satu lagi istilah baharu dalam blogosphere atau persidangan IT, lambat laun bertanya soalan yang sama: “Apakah ini? Hanya satu lagi kata kunci, "kata kunci" atau sesuatu yang benar-benar patut diberi perhatian, kajian dan janji tentang cakrawala baharu?" Perkara yang sama berlaku kepada saya dengan istilah itu GitOps suatu ketika dahulu. Berbekalkan banyak artikel sedia ada, serta pengetahuan rakan sekerja dari syarikat GitLab, saya cuba memikirkan jenis binatang ini, dan rupa penggunaannya dalam amalan.

Dengan cara ini, tentang kebaharuan istilah itu GitOps Tinjauan terbaru kami juga mengatakan: lebih separuh daripada mereka yang ditinjau masih belum mula bekerja dengan prinsipnya.

Jadi, masalah pengurusan infrastruktur bukanlah perkara baru. Banyak penyedia awan telah tersedia untuk orang ramai selama berbelas tahun dan, nampaknya, sepatutnya menjadikan kerja pasukan yang bertanggungjawab untuk infrastruktur itu mudah dan mudah. Walau bagaimanapun, jika dibandingkan dengan proses pembangunan aplikasi (di mana automasi mencapai tahap baharu), projek infrastruktur masih sering melibatkan banyak tugas manual dan memerlukan pengetahuan dan kepakaran khusus, terutamanya memandangkan keperluan hari ini untuk toleransi kesalahan, fleksibiliti, skalabiliti dan keanjalan.

Perkhidmatan awan memenuhi keperluan ini dengan sangat berjaya dan merekalah yang memberi dorongan yang ketara kepada pembangunan pendekatan IaC. Ini boleh difahami. Lagipun, mereka memungkinkan untuk mengkonfigurasi pusat data maya sepenuhnya: tidak ada pelayan fizikal, rak atau komponen rangkaian; keseluruhan infrastruktur boleh diterangkan menggunakan skrip dan fail konfigurasi.

Jadi apa sebenarnya perbezaannya? GitOps daripada IaC? Dengan soalan inilah saya memulakan siasatan saya. Selepas bercakap dengan rakan sekerja, saya dapat membuat perbandingan berikut:

GitOps

IaC

Semua kod disimpan dalam repositori git

Versi kod adalah pilihan

Perihalan Kod Perisytiharan / Idempotensi

Kedua-dua huraian deklaratif dan imperatif boleh diterima

Perubahan berkuat kuasa menggunakan mekanisme Permintaan Gabung / Permintaan Tarik

Perjanjian, kelulusan dan kerjasama adalah pilihan

Proses pelancaran kemas kini adalah automatik

Proses pelancaran kemas kini tidak diseragamkan (automatik, manual, menyalin fail, menggunakan baris arahan, dsb.)

Dalam kata lain GitOps dilahirkan dengan tepat melalui penerapan prinsip IaC. Pertama, infrastruktur dan konfigurasi kini boleh disimpan dengan cara yang sama seperti aplikasi. Kod ini mudah disimpan, mudah dikongsi, membandingkan dan menggunakan keupayaan versi. Versi, cawangan, sejarah. Dan semua ini di tempat yang boleh diakses secara terbuka oleh seluruh pasukan. Oleh itu, penggunaan sistem kawalan versi menjadi pembangunan semula jadi sepenuhnya. Khususnya, git, sebagai yang paling popular.

Sebaliknya, ia menjadi mungkin untuk mengautomasikan proses pengurusan infrastruktur. Kini ini boleh dilakukan dengan lebih pantas, lebih dipercayai dan lebih murah. Lebih-lebih lagi, prinsip CI / CD telah pun diketahui dan popular di kalangan pembangun perisian. Ia hanya perlu untuk memindahkan dan menggunakan pengetahuan dan kemahiran yang telah diketahui ke kawasan baharu. Amalan ini, bagaimanapun, melangkaui takrifan piawai Infrastruktur sebagai kod, oleh itu konsepnya GitOps.

Rasa ingin tahu GitOps, sudah tentu, juga dalam fakta bahawa ia bukan produk, pemalam atau platform yang dikaitkan dengan mana-mana vendor. Ia lebih kepada paradigma dan satu set prinsip, serupa dengan istilah lain yang kita kenali: DevOps.

Dalam syarikat GitLab kami telah membangunkan dua definisi istilah baharu ini: teori dan praktikal. Mari kita mulakan dengan teori:

GitOps ialah metodologi yang mengambil prinsip DevOps terbaik yang digunakan untuk pembangunan aplikasi, seperti kawalan versi, kerjasama, orkestrasi, CI/CD dan menggunakannya untuk cabaran mengautomasikan pengurusan infrastruktur.

Semua proses GitOps Saya bekerja menggunakan alatan sedia ada. Semua kod infrastruktur disimpan dalam repositori git yang sudah biasa, perubahan melalui proses kelulusan yang sama seperti mana-mana kod program lain, dan proses pelancaran adalah automatik, yang membolehkan kami meminimumkan ralat manusia, meningkatkan kebolehpercayaan dan kebolehulangan.

Dari sudut praktikal, kami menerangkan GitOps seperti berikut:

Kami telah membincangkan infrastruktur sebagai kod sebagai salah satu komponen utama formula ini. Mari kita perkenalkan peserta yang lain.

Permintaan Gabung (nama alternatif Pull Request). Dari segi proses, MR ialah permintaan untuk menggunakan perubahan kod dan kemudian menggabungkan cawangan. Tetapi dari segi alat yang kami gunakan, ini lebih kepada peluang untuk mendapatkan gambaran lengkap tentang semua perubahan yang dibuat: bukan sahaja kod berbeza yang dikumpul daripada bilangan komit tertentu, tetapi juga konteks, keputusan ujian dan keputusan akhir yang dijangkakan. Jika kita bercakap tentang kod infrastruktur, maka kita berminat dengan bagaimana tepatnya infrastruktur akan berubah, berapa banyak sumber baharu akan ditambah atau dialih keluar, diubah. Sebaik-baiknya dalam format yang lebih mudah dan mudah dibaca. Bagi penyedia awan, adalah idea yang baik untuk mengetahui kesan kewangan daripada perubahan ini.

Tetapi MR juga merupakan cara kerjasama, interaksi dan komunikasi. Tempat di mana sistem semak dan imbangan berlaku. Daripada ulasan ringkas kepada kelulusan dan kelulusan rasmi.

Nah, komponen terakhir: CI/CD, seperti yang telah kita ketahui, memungkinkan untuk mengautomasikan proses membuat perubahan dan ujian infrastruktur (daripada semakan sintaks mudah kepada analisis kod statik yang lebih kompleks). Dan juga dalam pengesanan hanyut berikutnya: perbezaan antara keadaan sebenar dan yang dikehendaki sistem. Contohnya, akibat perubahan manual yang tidak dibenarkan atau kegagalan sistem.

Ya, istilahnya GitOps tidak memperkenalkan kita kepada sesuatu yang benar-benar baru, tidak mencipta semula roda, tetapi hanya menggunakan pengalaman yang sudah terkumpul di kawasan baharu. Tetapi di sinilah kekuatannya.

Dan jika anda tiba-tiba menjadi berminat dengan bagaimana semua ini kelihatan dalam amalan, maka saya menjemput anda untuk melihat kami kelas induk, di mana saya memberitahu anda langkah demi langkah cara menggunakan GitLab:

• Laksanakan prinsip asas GitOps

• Buat dan buat perubahan pada infrastruktur awan (menggunakan contoh Yandex Cloud)

• Automatikkan pengesanan hanyut sistem dari keadaan yang dikehendaki menggunakan pemantauan aktif

https://bit.ly/34tRpwZ

Sumber: www.habr.com