Umume kita, ngerteni istilah anyar liyane ing blogosphere utawa konferensi IT, cepet-cepet takon pitakonan sing padha: "Apa iki? Mung tembung geguritan liyane, "tembung geguritan" utawa apa wae sing kudu digatekake, ditliti lan dijanjekake babagan cakrawala anyar?" Bab sing padha karo aku karo istilah kasebut GitOps sawetara wektu kepungkur. Bersenjata karo akeh artikel sing wis ana, uga kawruh saka kolega saka perusahaan , Aku nyoba kanggo tokoh metu apa jenis kewan iki, lan apa nggunakake bisa katon kaya ing laku.
Miturut cara, bab anyar saka istilah GitOps Survei anyar kita uga ujar: luwih saka setengah saka sing ditliti durung miwiti nggarap prinsip.
Dadi, masalah manajemen infrastruktur ora anyar. Akeh panyedhiya maya wis kasedhiya kanggo masarakat umum sajrone pirang-pirang taun lan, mesthine kudu nggawe karya tim sing tanggung jawab kanggo infrastruktur kasebut gampang lan gampang. Nanging, yen dibandhingake karo proses pangembangan aplikasi (ing ngendi otomatisasi wis tekan tingkat anyar), proyek infrastruktur isih asring nglibatake akeh tugas manual lan mbutuhake kawruh lan keahlian khusus, utamane diwenehi syarat saiki kanggo toleransi kesalahan, keluwesan, skalabilitas lan elastisitas.
Layanan awan ngrampungake syarat kasebut kanthi sukses lan dheweke sing menehi dorongan penting kanggo pangembangan pendekatan kasebut IaC. Iki bisa dingerteni. Sawise kabeh, dheweke bisa ngatur pusat data virtual sing lengkap: ora ana server fisik, rak, utawa komponen jaringan; kabeh infrastruktur bisa diterangake nggunakake skrip lan file konfigurasi.
Dadi apa sejatine bedane? GitOps saka IaC? Kanthi pitakonan iki aku miwiti investigasi. Sawise ngobrol karo kanca-kanca, aku bisa nggawe perbandingan ing ngisor iki:
GitOps
IaC
Kabeh kode disimpen ing repositori git
Versi kode iku opsional
Deskripsi Kode Deklaratif / Idempotensi
Katrangan deklaratif lan imperatif bisa ditampa
Owah-owahan ditrapake kanthi nggunakake mekanisme Gabung Panyuwunan / Tarik
Persetujuan, persetujuan lan kolaborasi iku opsional
Proses nganyari nganyari otomatis
Proses nganyari nganyari ora standar (otomatis, manual, nyalin file, nggunakake baris perintah, lsp.)
Ing tembung liyane GitOps lair sabenere liwat aplikasi saka prinsip IaC. Kaping pisanan, infrastruktur lan konfigurasi saiki bisa disimpen kanthi cara sing padha karo aplikasi. Kode kasebut gampang disimpen, gampang dienggo bareng, mbandhingake, lan nggunakake kemampuan versi. Versi, cabang, sajarah. Lan kabeh iki ing papan sing bisa diakses umum kanggo kabeh tim. Mulane, nggunakake sistem kontrol versi dadi pembangunan rampung alam. Utamane, git, minangka sing paling populer.
Ing sisih liya, bisa ngotomatisasi proses manajemen infrastruktur. Saiki iki bisa ditindakake kanthi luwih cepet, luwih andal lan luwih murah. Kajaba iku, prinsip CI / CD wis dikenal lan populer ing antarane pangembang piranti lunak. Sampeyan mung kudu nransfer lan ngetrapake kawruh lan katrampilan sing wis dingerteni menyang wilayah anyar. Nanging, praktik kasebut ngluwihi definisi standar Infrastruktur minangka kode, mula konsep kasebut GitOps.
Penasaran GitOps, mesthi, uga ing kasunyatan sing ora produk, plugin utawa platform gadhah vendor sembarang. Iku luwih saka paradigma lan seperangkat prinsip, padha karo istilah liyane sing kita kenal: DevOps.
Ing perusahaan kita wis ngembangake rong definisi istilah anyar iki: teoritis lan praktis. Ayo diwiwiti kanthi teoritis:
GitOps minangka metodologi sing njupuk prinsip DevOps paling apik sing digunakake kanggo pangembangan aplikasi, kayata kontrol versi, kolaborasi, orkestrasi, CI/CD, lan ditrapake kanggo tantangan ngotomatisasi manajemen infrastruktur.
Kabeh proses GitOps Aku kerja nggunakake alat sing wis ana. Kabeh kode infrastruktur disimpen ing repositori git sing wis akrab, owah-owahan liwat proses persetujuan sing padha karo kode program liyane, lan proses rollout otomatis, sing ngidini kita nyilikake kesalahan manungsa, nambah linuwih lan reproduksi.
Saka sudut pandang praktis, kita njlèntrèhaké GitOps kaya mangkene:
Kita wis ngrembug infrastruktur minangka kode minangka salah sawijining komponen utama rumus iki. Ayo padha ngenalake para peserta liyane.
Gabung Request (jeneng alternatif Pull Request). Ing istilah proses, MR minangka panyuwunan kanggo ngganti kode lan banjur nggabungake cabang. Nanging babagan alat sing digunakake, iki luwih minangka kesempatan kanggo entuk gambaran lengkap babagan kabeh owah-owahan sing ditindakake: ora mung beda kode sing diklumpukake saka sawetara komitmen, nanging uga konteks, asil tes, lan asil samesthine pungkasan. Yen kita ngomong babagan kode infrastruktur, mula kita kepengin weruh kepiye infrastruktur bakal diganti, jumlah sumber daya anyar sing bakal ditambah utawa dibusak, diganti. Luwih becik ing sawetara format sing luwih trep lan gampang diwaca. Kanggo panyedhiya awan, luwih becik ngerti apa pengaruh finansial saka owah-owahan iki.
Nanging MR uga minangka sarana kolaborasi, interaksi, lan komunikasi. Panggonan ngendi sistem mriksa lan imbangan teka menyang muter. Saka komentar prasaja kanggo persetujuan resmi lan persetujuan.
Inggih, komponen pungkasan: CI / CD, kaya sing wis dingerteni, ndadekake bisa ngotomatisasi proses pangowahan lan pangujian infrastruktur (saka pamriksan sintaksis sing prasaja nganti analisis kode statis sing luwih rumit). Lan uga ing deteksi drift sakteruse: beda antarane negara nyata lan sing dikarepake saka sistem. Contone, minangka asil saka owah-owahan manual ora sah utawa gagal sistem.
Ya, istilahe GitOps ora introduce kita apa rampung anyar, ora reinvent setir, nanging mung ditrapake pengalaman wis nambah ing wilayah anyar. Nanging ing kene ana kekuwatane.
Lan yen dumadakan dadi kasengsem ing carane iki kabeh katon ing laku, banjur aku ngajak sampeyan ndeleng kita , ing ngendi aku ngandhani langkah demi langkah carane nggunakake GitLab:
-
Ngleksanakake prinsip dhasar GitOps
-
Gawe lan owah-owahan ing infrastruktur awan (nggunakake conto Yandex Cloud)
-
Otomatis deteksi drift sistem saka negara sing dikarepake nggunakake pemantauan aktif
https://bit.ly/34tRpwZ
Source: www.habr.com