Cathetan. nerjemahake.: Sawise publikasi anyar babagan cara narik lan push ing GitOps, kita weruh kapentingan ing model iki ing umum, nanging ana sawetara publikasi basa Rusia ing topik iki (mung ora ana ing Habré). Mulane, kita seneng menehi perhatian marang terjemahan artikel liyane - sanajan meh setahun kepungkur! - saka Weaveworks, kepala sing nggawe istilah "GitOps." Teks kasebut nerangake inti saka pendekatan lan prabédan utama saka sing wis ana.
Setaun kepungkur kita nerbitake . Ing wektu iku, kita nuduhake kepiye tim Weaveworks ngluncurake SaaS adhedhasar Kubernetes lan ngembangake seperangkat praktik paling apik sing preskriptif kanggo nyebarake, ngatur, lan ngawasi ing lingkungan asli awan.
Artikel kasebut dadi populer. Wong liya wiwit ngomong babagan GitOps lan wiwit nerbitake alat anyar kanggo , , , , lan liya-liyane. Katon ing situs web kita publikasi lan kasus panggunaan GitOps. Nanging sawetara wong isih duwe pitakonan. Kepiye model beda karo sing tradisional? lan pangiriman terus-terusan ()? Apa perlu nggunakake Kubernetes?
Kita langsung nyadari yen katrangan anyar dibutuhake, nawakake:
- A nomer akeh conto lan crita;
- Définisi spesifik GitOps;
- Dibandhingake karo pangiriman terus tradisional.
Ing artikel iki kita wis nyoba kanggo nutupi kabeh topik iki. Nyedhiyakake introduksi sing dianyari kanggo GitOps lan pangembang lan perspektif CI/CD. Kita utamane fokus ing Kubernetes, sanajan model kasebut bisa digeneralisasi.
Ketemu GitOps
Mbayangno Alice. Dheweke mbukak Asuransi Keluarga, sing nawakake asuransi kesehatan, mobil, omah, lan lelungan kanggo wong sing sibuk banget kanggo ngerti seluk beluk kontrak kasebut. Bisnise diwiwiti minangka proyek sampingan nalika Alice kerja ing bank minangka ilmuwan data. Sawijining dina dheweke nyadari yen dheweke bisa nggunakake algoritma komputer canggih kanggo nganalisa data kanthi luwih efektif lan ngramu paket asuransi. Investor mbiayai proyek kasebut, lan saiki perusahaan dheweke ngasilake luwih saka $ 20 yuta saben taun lan berkembang kanthi cepet. Saiki, makaryakke 180 wong ing macem-macem posisi. Iki kalebu tim teknologi sing ngembangake, njaga situs web, database, lan nganalisa basis pelanggan. Tim 60 wong dipimpin dening Bob, direktur teknis perusahaan.
Tim Bob masang sistem produksi ing awan. Aplikasi inti mlaku ing GKE, njupuk kauntungan saka Kubernetes ing Google Cloud. Kajaba iku, dheweke nggunakake macem-macem data lan alat analytics ing karyane.
Asuransi Kulawarga ora nggunakake wadhah, nanging kejiret ing semangat Docker. Perusahaan kasebut langsung nemokake manawa GKE nggampangake nyebarake kluster kanggo nyoba fitur-fitur anyar. Jenkins kanggo CI lan Quay ditambahake kanggo ngatur registri wadhah, skrip ditulis kanggo Jenkins sing nyurung wadhah lan konfigurasi anyar menyang GKE.
Sawetara wektu wis liwati. Alice lan Bob kuciwa karo kinerja pendekatan sing dipilih lan pengaruhe ing bisnis kasebut. Introduksi wadhah ora nambah produktivitas kaya sing dikarepake tim. Kadhangkala panyebaran bakal rusak, lan ora jelas manawa owah-owahan kode kudu disalahake. Iku uga dadi angel kanggo nglacak owah-owahan konfigurasi. Asring kudu nggawe kluster anyar lan mindhah aplikasi kasebut, amarga iki minangka cara paling gampang kanggo ngilangi kekacoan sistem kasebut. Alice wedi yen kahanan bakal saya elek nalika aplikasi dikembangake (saliyane, proyek anyar adhedhasar pembelajaran mesin lagi digawe). Bob wis ngotomatisasi sebagian besar karya lan ora ngerti sebabe pipa isih ora stabil, ukurane ora apik, lan mbutuhake intervensi manual kanthi periodik?
Banjur padha sinau babagan GitOps. Keputusan iki dadi persis sing dibutuhake kanggo maju kanthi yakin.
Alice lan Bob wis krungu babagan Git, DevOps, lan infrastruktur minangka alur kerja kode nganti pirang-pirang taun. Sing unik babagan GitOps yaiku nggawa seperangkat praktik paling apik — definitif lan normatif — kanggo ngetrapake ide kasebut ing konteks Kubernetes. Tema iki , kalebu ing .
Asuransi Keluarga mutusake kanggo ngetrapake GitOps. Perusahaan saiki duwe model operasi otomatis sing kompatibel karo Kubernetes lan gabungan kacepetan saka stabilitasamarga padha:
- ketemu sing produktivitas tim kang tikel kaping pindho tanpa wong dadi edan;
- mandhek porsi script. Nanging, saiki dheweke bisa fokus ing fitur-fitur anyar lan nambah cara teknik - contone, ngenalake rollout kenari lan nambah tes;
- kita wis nambah proses panyebaran supaya arang rusak;
- entuk kesempatan kanggo mulihake penyebaran sawise gagal parsial tanpa intervensi manual;
- dituku digunakakeоKapercayan sing luwih gedhe ing sistem pangiriman. Alice lan Bob nemokake yen dheweke bisa misahake tim kasebut dadi tim microservice sing makarya bebarengan;
- bisa nggawe 30-50 owah-owahan ing project saben dina liwat efforts saben klompok lan nyoba Techniques anyar;
- iku gampang kanggo narik kawigaten pangembang anyar kanggo project, sing duwe kesempatan kanggo muter metu nganyari kanggo produksi nggunakake panjalukan narik ing sawetara jam;
- gampang lulus audit ing kerangka SOC2 (kanggo netepi panyedhiya layanan karo syarat kanggo manajemen data sing aman; waca liyane, contone, - kira-kira. transl.).
Apa sing kedadeyan?
GitOps ana rong perkara:
- Model operasional kanggo Kubernetes lan cloud native. Nyedhiyakake seperangkat praktik paling apik kanggo nyebarake, ngatur, lan ngawasi kluster lan aplikasi kontaner. Definisi elegan ing wangun saka :
- Path kanggo nggawe lingkungan manajemen aplikasi pangembang-sentris. Kita ngetrapake alur kerja Git kanggo operasi lan pangembangan. Elinga yen iki ora mung babagan push Git, nanging babagan ngatur kabeh piranti CI / CD lan UI / UX.
Sawetara tembung babagan Git
Yen sampeyan ora kenal karo sistem kontrol versi lan alur kerja basis Git, disaranake sinau babagan iki. Nggarap cabang lan panjaluk narik bisa uga katon kaya sihir ireng ing wiwitan, nanging entuk manfaat sing kudu ditindakake. kene kanggo miwiti.
Carane Kubernetes dianggo
Ing crita kita, Alice lan Bob nguripake GitOps sawise nggarap Kubernetes sawetara wektu. Pancen, GitOps raket banget karo Kubernetes - iku model operasional kanggo infrastruktur lan aplikasi adhedhasar Kubernetes.
Apa sing diwenehake Kubernetes marang pangguna?
Ing ngisor iki sawetara fitur utama:
- Ing model Kubernetes, kabeh bisa diterangake ing wangun deklaratif.
- Server API Kubernetes njupuk deklarasi iki minangka input lan terus-terusan nyoba nggawa kluster menyang negara sing diterangake ing deklarasi kasebut.
- Pranyatan cukup kanggo njlèntrèhaké lan ngatur macem-macem beban kerja - "aplikasi."
- Akibaté, owah-owahan ing aplikasi lan kluster dumadi amarga:
- owah-owahan ing gambar wadhah;
- owah-owahan ing spesifikasi deklaratif;
- kesalahan ing lingkungan - contone, tubrukan wadhah.
Kapabilitas Konvergensi Agung Kubernetes
Nalika administrator nggawe owah-owahan konfigurasi, orkestra Kubernetes bakal nglebokake kluster kasebut sajrone status kasebut. ora bakal nyedhaki konfigurasi anyar. Model iki bisa digunakake kanggo sumber Kubernetes lan bisa ditambah karo Definisi Sumber Daya Khusus (CRD). Mula, panyebaran Kubernetes nduweni sifat apik ing ngisor iki:
- Otomasi: Nganyari Kubernetes nyedhiyakake mekanisme kanggo ngotomatisasi proses nglamar owah-owahan kanthi apik lan pas wektune.
- Konvergensi: Kubernetes bakal terus nyoba nganyari nganti sukses.
- Idempotensi: Aplikasi konvergensi sing bola-bali nyebabake asil sing padha.
- Determinisme: Nalika sumber daya cukup, kahanan kluster dianyari mung gumantung ing negara sing dikarepake.
Cara kerja GitOps
Kita wis cukup sinau babagan Kubernetes kanggo nerangake cara kerja GitOps.
Ayo bali menyang tim microservices Family Insurance. Apa sing biasane kudu ditindakake? Deleng dhaptar ing ngisor iki (yen ana barang sing katon aneh utawa ora pati ngerti, aja nganti ngritik lan tetep karo kita). Iki mung conto alur kerja adhedhasar Jenkins. Ana akeh proses liyane nalika nggarap piranti liyane.
Ingkang utama yaiku yen saben nganyari rampung kanthi owah-owahan ing file konfigurasi lan repositori Git. Owah-owahan ing Git iki nyebabake "operator GitOps" nganyari kluster:
1. Proses kerja: "Jenkins mbangun - cabang master".
Daftar tugas:
- Jenkins nyurung gambar sing diwenehi tag menyang Quay;
- Jenkins nyurung config lan Helm denah menyang ember panyimpenan master;
- Fungsi maya nyalin konfigurasi lan grafik saka ember panyimpenan master menyang repositori Git master;
- Operator GitOps nganyari kluster.
2. Jenkins mbangun - release utawa cabang hotfix:
- Jenkins nyurung gambar untagged kanggo Quay;
- Jenkins nyurung config lan Helm denah menyang ember panyimpenan pementasan;
- Fungsi maya nyalin konfigurasi lan grafik saka ember panyimpenan pementasan menyang repositori Git pementasan;
- Operator GitOps nganyari kluster.
3. Jenkins mbangun - berkembang utawa fitur cabang:
- Jenkins nyurung gambar untagged kanggo Quay;
- Jenkins nyurung config lan Helm denah menyang ngembangaken ember panyimpenan;
- Fungsi maya nyalin konfigurasi lan grafik saka ember panyimpenan ngembangake menyang gudang Git ngembangake;
- Operator GitOps nganyari kluster.
4. Nambahake klien anyar:
- Manajer utawa administrator (LCM/ops) nelpon Gradle kanggo miwiti masang lan ngatur pangimbang beban jaringan (NLB);
- LCM/ops nindakake konfigurasi anyar kanggo nyiapake penyebaran kanggo nganyari;
- Operator GitOps nganyari kluster.
Katrangan singkat babagan GitOps
- Njlèntrèhaké kahanan sing dikarepake saka kabeh sistem nggunakake spesifikasi deklaratif kanggo saben lingkungan (ing crita kita, tim Bob nemtokake kabeh konfigurasi sistem ing Git).
- Repositori Git minangka sumber siji bebener babagan kahanan sing dikarepake ing kabeh sistem.
- Kabeh owah-owahan menyang negara sing dikarepake digawe liwat komit ing Git.
- Kabeh paramèter kluster sing dikarepake uga bisa diamati ing kluster kasebut. Kanthi cara iki kita bisa nemtokake manawa padha pas (konvergen, konvergensi) utawa beda (beda, nyimpang) negara sing dikarepake lan diamati.
- Yen negara sing dikarepake lan diamati beda-beda, banjur:
- Ana mekanisme konvergensi sing cepet utawa mengko kanthi otomatis nyinkronake target lan negara sing diamati. Ing kluster, Kubernetes nindakake iki.
- Proses kasebut langsung diwiwiti kanthi tandha "pangowahan setya".
- Sawise sawetara wektu sing bisa dikonfigurasi, tandha "beda" bisa dikirim yen negara beda.
- Kanthi cara iki, kabeh komit ing Git nyebabake update sing bisa diverifikasi lan idempoten menyang kluster.
- Rollback minangka konvergensi menyang negara sing dikarepake sadurunge.
- Konvergensi punika final. Kedadeyane dituduhake dening:
- Ora ana tandha beda kanggo wektu tartamtu.
- Tandha "konvergen" (contone webhook, acara tulis maneh Git).
Apa sing divergensi?
Ayo mbaleni maneh: kabeh sifat kluster sing dikarepake kudu bisa diamati ing kluster kasebut.
Sawetara conto divergensi:
- Owah-owahan ing file konfigurasi amarga nggabungake cabang ing Git.
- Owah-owahan ing file konfigurasi amarga komit Git sing digawe dening klien GUI.
- Owah-owahan kaping pirang-pirang menyang negara sing dikarepake amarga PR ing Git diikuti kanthi mbangun gambar wadhah lan owah-owahan konfigurasi.
- Owah-owahan ing negara klompok amarga kesalahan, konflik sumber sing nyebabake "prilaku ala", utawa mung nyimpang kanthi acak saka negara asli.
Apa mekanisme konvergensi?
Sawetara conto:
- Kanggo wadhah lan kluster, mekanisme konvergensi diwenehake dening Kubernetes.
- Mekanisme sing padha bisa digunakake kanggo ngatur aplikasi lan desain adhedhasar Kubernetes (kayata Istio lan Kubeflow).
- Mekanisme kanggo ngatur interaksi operasional antarane Kubernetes, repositori gambar lan Git nyedhiyakake , kang bagean .
- Kanggo mesin dhasar, mekanisme konvergensi kudu deklaratif lan otonom. Saka pengalaman kita dhewe bisa ngomong paling cedhak karo definisi iki, nanging isih mbutuhake kontrol manungsa. Ing pangertèn iki, GitOps ngluwihi tradhisi Infrastruktur minangka Kode.
GitOps nggabungake Git karo mesin konvergensi Kubernetes sing apik kanggo nyedhiyakake model kanggo eksploitasi.
GitOps ngidini kita ngomong: Mung sistem sing bisa diterangake lan diamati bisa otomatis lan kontrol.
GitOps ditujokake kanggo kabeh tumpukan asli awan (contone, Terraform, lsp.)
GitOps ora mung Kubernetes. Kita pengin kabeh sistem didorong kanthi deklaratif lan nggunakake konvergensi. Miturut kabeh sistem, tegese kumpulan lingkungan sing bisa digunakake karo Kubernetes - contone, "dev cluster 1", "production", etc. Saben lingkungan kalebu mesin, kluster, aplikasi, uga antarmuka kanggo layanan eksternal sing nyedhiyakake data, ngawasi. lan lsp.
Elinga carane penting Terraform kanggo masalah bootstrap ing kasus iki. Kubernetes kudu disebarake ing endi wae, lan nggunakake Terraform tegese kita bisa ngetrapake alur kerja GitOps sing padha kanggo nggawe lapisan kontrol sing ndhukung Kubernetes lan aplikasi. Iki minangka praktik paling apik sing migunani.
Ana fokus sing kuat kanggo ngetrapake konsep GitOps menyang lapisan ing ndhuwur Kubernetes. Saiki, ana solusi jinis GitOps kanggo Istio, Helm, Ksonnet, OpenFaaS lan Kubeflow, uga, contone, kanggo Pulumi, sing nggawe lapisan kanggo ngembangake aplikasi kanggo cloud native.
Kubernetes CI / CD: mbandhingake GitOps karo pendekatan liyane
Kaya sing wis dingerteni, GitOps ana rong perkara:
- Model operasi kanggo Kubernetes lan cloud native sing diterangake ing ndhuwur.
- Path menyang lingkungan manajemen aplikasi pangembang-sentris.
Kanggo akeh, GitOps utamane minangka alur kerja adhedhasar push Git. Kita uga seneng karo dheweke. Nanging iku ora kabeh: ayo saiki katon ing CI / CD pipelines.
GitOps ngaktifake penyebaran terus (CD) kanggo Kubernetes
GitOps nawakake mekanisme panyebaran terus-terusan sing ngilangi kabutuhan "sistem manajemen penyebaran" sing kapisah. Kubernetes nindakake kabeh karya kanggo sampeyan.
- Nganyari aplikasi mbutuhake nganyari ing Git. Iki minangka nganyari transaksional menyang negara sing dikarepake. "Panyebaran" banjur ditindakake ing kluster dening Kubernetes dhewe adhedhasar katrangan sing dianyari.
- Amarga sifat cara kerja Kubernetes, nganyari iki dadi konvergen. Iki nyedhiyakake mekanisme kanggo panyebaran terus-terusan sing kabeh nganyari yaiku atom.
- Wigati: nawakake operator GitOps sing nggabungake Git lan Kubernetes lan ngidini CD bisa ditindakake kanthi nyelarasake kahanan kluster sing dikarepake lan saiki.
Tanpa kubectl lan skrip
Sampeyan kudu ngindhari nggunakake Kubectl kanggo nganyari kluster, lan utamane supaya ora nggunakake skrip kanggo nglumpukake perintah kubectl. Nanging, kanthi pipa GitOps, pangguna bisa nganyari kluster Kubernetes liwat Git.
Keuntungan kalebu:
- bener. Klompok nganyari bisa diterapake, digabung lan pungkasane divalidasi, nggawa kita luwih cedhak karo tujuan penyebaran atom. Ing kontras, nggunakake skrip ora menehi jaminan konvergensi (liyane ing ngisor iki).
- Keamanan. Kelsey Hightower: "Watesi akses menyang kluster Kubernetes menyang alat otomatis lan administrator sing tanggung jawab kanggo debugging utawa njaga." deloken sisan babagan safety lan selaras karo spesifikasi teknis, uga dening nyolong Diverifikasi saka script Jenkins carelessly ditulis.
- Pengalaman pangguna. Kubectl mbabarake mekanika model obyek Kubernetes, sing cukup rumit. Saenipun, pangguna kudu sesambungan karo sistem ing tingkat abstraksi sing luwih dhuwur. Ing kene aku bakal ngrujuk maneh Kelsey lan nyaranake nonton .
Bedane antarane CI lan CD
GitOps nambah model CI / CD sing ana.
Server CI modern minangka alat orkestrasi. Utamane, iki minangka alat kanggo ngatur pipa CI. Iki kalebu mbangun, tes, gabung menyang trunk, lsp. Server CI ngotomatisasi manajemen pipa multi-langkah sing kompleks. Godaan sing umum yaiku nulis sakumpulan nganyari Kubernetes lan mbukak minangka bagéan saka pipa kanggo push owah-owahan menyang kluster. Pancen, iki sing ditindakake dening akeh ahli. Nanging, iki ora optimal, lan iki sebabe.
CI kudu digunakake kanggo push nganyari kanggo trunk, lan kluster Kubernetes kudu ngganti dhewe adhedhasar nganyari kanggo ngatur CD internal. We nyebataken , ora kaya model push CI. CD minangka bagean orkestrasi runtime.
Napa Server CI Ora Bisa Nggawe CD liwat Nganyari Langsung ing Kubernetes
Aja nggunakake server CI kanggo orchestrate nganyari langsung menyang Kubernetes minangka pesawat saka proyek CI. Iki minangka anti-pola sing kita ngomong babagan ing blog sampeyan.
Ayo bali menyang Alice lan Bob.
Masalah apa sing diadhepi? server CI Bob ditrapake owah-owahan ing kluster, nanging yen tubrukan ing proses, Bob ora ngerti apa negara kluster (utawa kudu) utawa carane ndandani. Padha bener ing kasus sukses.
Ayo nganggep manawa tim Bob nggawe gambar anyar lan banjur nambal penyebarane kanggo nyebarake gambar kasebut (kabeh saka pipa CI).
Yen gambar dibangun kanthi normal, nanging pipa gagal, tim kudu ngerteni:
- Apa nganyari wis diluncurake?
- Apa kita ngluncurake bangunan anyar? Apa iki bakal nyebabake efek samping sing ora perlu - kanthi kemungkinan nggawe loro gambar sing ora bisa diganti?
- Apa kita kudu ngenteni nganyari sabanjure sadurunge mbukak mbangun?
- Apa sing salah? Langkah endi sing kudu diulang (lan sing aman kanggo diulang)?
Nggawe alur kerja basis Git ora njamin yen tim Bob ora bakal nemoni masalah kasebut. Dheweke isih bisa nggawe kesalahan karo push commit, tag, utawa sawetara parameter liyane; nanging, pendekatan iki isih luwih cedhak karo pendekatan eksplisit kabeh-utawa-ora ana.
Kanggo ngringkes, iki sebabe server CI ora kudu ngurus CD:
- Skrip nganyari ora tansah deterministik; Iku gampang kanggo nggawe kesalahan ing wong.
- server CI ora converge kanggo model kluster deklaratif.
- Iku angel kanggo njamin idempotensi. Pangguna kudu ngerti semantik jero sistem kasebut.
- Luwih angel pulih saka kegagalan parsial.
Cathetan babagan Helm: Yen sampeyan pengin nggunakake Helm, disaranake gabungke karo operator GitOps kayata . Iki bakal mbantu njamin konvergensi. Helm dhewe ora deterministik utawa atom.
GitOps minangka cara paling apik kanggo ngetrapake Pangiriman Terus-terusan kanggo Kubernetes
Tim Alice lan Bob ngetrapake GitOps lan nemokake manawa luwih gampang nggarap produk piranti lunak, njaga kinerja lan stabilitas sing dhuwur. Ayo mungkasi artikel iki kanthi ilustrasi sing nuduhake kepiye pendekatan anyar kasebut. Elinga yen kita biasane ngomong babagan aplikasi lan layanan, nanging GitOps bisa digunakake kanggo ngatur kabeh platform.
Model operasi kanggo Kubernetes
Delengen diagram ing ngisor iki. Iki nampilake Git lan repositori gambar wadhah minangka sumber daya sing dienggo bareng kanggo rong siklus urip sing diatur:
- Pipa integrasi terus-terusan sing maca lan nulis file menyang Git lan bisa nganyari repositori gambar wadhah.
- Pipa Runtime GitOps sing nggabungake penyebaran karo manajemen lan observasi. Maca lan nulis file menyang Git lan bisa ndownload gambar wadhah.
Apa temuan utama?
- Pamisahan uneg-uneg: Elinga yen loro pipa mung bisa komunikasi kanthi nganyari Git utawa gudang gambar. Ing tembung liyane, ana firewall antarane CI lan lingkungan runtime. Kita nyebat "firewall immutability" (firewall imutabilitas), amarga kabeh nganyari repositori nggawe versi anyar. Kanggo informasi luwih lengkap babagan topik iki, deleng slide 72-87 .
- Sampeyan bisa nggunakake server CI lan Git apa wae: GitOps dianggo karo komponen apa wae. Sampeyan bisa terus nggunakake server CI lan Git favorit, repositori gambar, lan suite tes. Meh kabeh alat Pangiriman Terus-terusan liyane ing pasar mbutuhake server CI / Git utawa gudang gambar dhewe. Iki bisa dadi faktor watesan ing pangembangan cloud native. Kanthi GitOps, sampeyan bisa nggunakake alat sing wis dikenal.
- Acara minangka alat integrasi: Sanalika data ing Git dianyari, Weave Flux (utawa operator Weave Cloud) ngabari runtime. Kapan Kubernetes nampa set pangowahan, Git dianyari. Iki nyedhiyakake model integrasi sing prasaja kanggo ngatur alur kerja kanggo GitOps, kaya sing kapacak ing ngisor iki.
kesimpulan
GitOps nyedhiyakake jaminan nganyari sing kuat sing dibutuhake dening alat CI/CD modern:
- otomatis;
- konvergensi;
- idempotensi;
- determinisme.
Iki penting amarga nawakake model operasional kanggo pangembang asli awan.
- Piranti tradisional kanggo ngatur lan ngawasi sistem digandhengake karo tim operasi sing beroperasi ing buku runbook (seperangkat prosedur lan operasi rutin - kira-kira transl.), disambungake menyang penyebaran tartamtu.
- Ing manajemen asli awan, alat observasi minangka cara paling apik kanggo ngukur asil penyebaran supaya tim pangembang bisa nanggapi kanthi cepet.
Bayangake akeh klompok sing kasebar ing macem-macem awan lan akeh layanan kanthi tim lan rencana penyebaran dhewe. GitOps nawakake model skala-invarian kanggo ngatur kabeh kelimpahan iki.
PS saka penerjemah
Waca uga ing blog kita:
- «";
- «";
- «".
Mung pangguna pangguna sing bisa melu survey. nggih.
Apa sampeyan ngerti babagan GitOps sadurunge rong terjemahan iki muncul ing Habré?
-
Ya, aku ngerti kabeh
-
Mung cethek
-
Ora
35 pangguna milih. 10 kedhaftar abstained.
Source: www.habr.com