Catetan. narjamahkeun.: Saatos publikasi panganyarna ngeunaan pull jeung push métode di GitOps, urang nempo minat model ieu sacara umum, tapi aya saeutik pisan publikasi Rusia-basa dina topik ieu (aya ngan teu aya dina Habré). Ku alatan éta, kami resep nawiskeun ka perhatian anjeun tarjamahan tina artikel séjén - sanajan ampir sataun katukang! - ti Weaveworks, pamimpin anu nyiptakeun istilah "GitOps." Téks ngajelaskeun hakekat pendekatan sareng bédana konci tina anu aya.
Sataun katukang urang diterbitkeun . Jaman harita, urang ngabagi kumaha tim Weaveworks ngaluncurkeun SaaS sapinuhna dumasar kana Kubernetes sareng ngembangkeun sakumpulan prakték preskriptif pangsaéna pikeun nyebarkeun, ngatur, sareng ngawaskeun dina lingkungan asli awan.
Artikel tétéla jadi populér. jalma séjén mimiti ngobrol ngeunaan GitOps sarta mimiti medarkeun parabot anyar pikeun , , , , teras salajengna. Nembongan dina ramatloka kami publikasi sarta kasus pamakéan GitOps. Tapi sababaraha urang masih gaduh patarosan. Kumaha modél béda ti anu tradisional? sareng pangiriman kontinyu ()? Naha perlu ngagunakeun Kubernetes?
Urang geura-giru sadar yén pedaran anyar diperlukeun, nawarkeun:
- Sajumlah ageung conto sareng carita;
- Definisi husus tina GitOps;
- Ngabandingkeun sareng pangiriman kontinyu tradisional.
Dina artikel ieu kami geus diusahakeun nutupan sakabeh jejer ieu. Éta nyayogikeun perkenalan anu diropéa pikeun GitOps sareng pamekar sareng sudut pandang CI / CD. Urang utamana difokuskeun Kubernetes, sanajan model bisa digeneralisasi.
Minuhan GitOps
Bayangkeun Alice. Anjeunna ngajalankeun Asuransi Kulawarga, anu nawiskeun asuransi kaséhatan, mobil, bumi, sareng perjalanan ka jalma-jalma anu sibuk teuing pikeun terangkeun seluk beluk kontrak sorangan. Usahana dimimitian salaku proyék samping nalika Alice damel di bank salaku élmuwan data. Hiji poé manéhna sadar yén manéhna bisa ngagunakeun algoritma komputer canggih pikeun leuwih éféktif nganalisa data jeung ngarumuskeun bungkusan asuransi. Investor ngabiayaan proyék éta, sareng ayeuna perusahaanna kéngingkeun langkung ti $ 20 juta sataun sareng ngembang pesat. Ayeuna, éta employs 180 urang dina sagala rupa posisi. Ieu kalebet tim téknologi anu ngembangkeun, ngajaga situs wéb, pangkalan data, sareng nganalisa basis palanggan. Tim 60 urang dipingpin ku Bob, diréktur teknis parusahaan.
Tim Bob nyebarkeun sistem produksi dina méga. Aplikasi inti maranéhanana dijalankeun dina GKE, ngamangpaatkeun Kubernetes dina Google Cloud. Salaku tambahan, aranjeunna ngagunakeun rupa-rupa data sareng alat analitik dina padamelan na.
Asuransi Kulawarga henteu badé nganggo wadah, tapi kajebak dina sumanget Docker. Pausahaan enggal mendakan yén GKE ngagampangkeun nyebarkeun klaster pikeun nguji fitur anyar. Jenkins pikeun CI jeung darmaga ieu ditambahkeun pikeun ngatur pendaptaran wadahna, naskah ditulis pikeun Jenkins nu kadorong peti anyar jeung konfigurasi ka GKE.
Sababaraha waktu geus kaliwat. Alice sareng Bob kuciwa ku kinerja pendekatan anu dipilih sareng dampakna dina bisnis. Perkenalan wadah henteu ningkatkeun produktivitas saloba anu dipiharep tim. Kadang-kadang panyebaran bakal rusak, sareng éta henteu écés naha parobihan kode anu disalahkeun. Tétéla ogé hésé pikeun ngalacak parobahan konfigurasi. Seringna kedah nyiptakeun klaster énggal sareng mindahkeun aplikasi ka dinya, sabab ieu mangrupikeun cara anu paling gampang pikeun ngaleungitkeun kekacauan anu sistemna janten. Alice sieun yén kaayaan bakal parah nalika aplikasi dikembangkeun (sajaba ti éta, hiji proyék anyar dumasar kana mesin learning ieu brewing). Bob parantos ngajadikeun otomatis seueur padamelan sareng henteu ngartos naha saluran pipa masih teu stabil, skala henteu saé, sareng peryogi campur tangan manual sacara périodik?
Teras aranjeunna diajar ngeunaan GitOps. Kaputusan ieu tétéla janten naon anu diperyogikeun pikeun yakin maju.
Alice sareng Bob parantos ngupingkeun ngeunaan Git, DevOps, sareng infrastruktur salaku alur kerja kode salami mangtaun-taun. Anu unik ngeunaan GitOps nyaéta yén éta nyayogikeun sakumpulan prakték pangsaéna — boh definitif sareng normatif — pikeun ngalaksanakeun ideu ieu dina konteks Kubernetes. Téma ieu , kaasup dina .
Asuransi kulawarga mutuskeun pikeun nerapkeun GitOps. Perusahaan ayeuna gaduh modél operasi otomatis anu cocog sareng Kubernetes sareng ngagabungkeun kagancangan jeung stabilitassabab maranéhna:
- kapanggih yén produktivitas tim urang dua kali tanpa saha gé gélo;
- dieureunkeun porsi Aksara. Sabalikna, aranjeunna ayeuna tiasa difokuskeun fitur anyar sareng ningkatkeun metode rékayasa - contona, ngenalkeun rollout kanaria sareng ningkatkeun tés;
- kami geus ningkat prosés deployment meh jarang ngarecah;
- ngagaduhan kasempetan pikeun mulangkeun panyebaran saatos gagal parsial tanpa campur tangan manual;
- dibeuli dipakéоKapercayaan anu langkung ageung dina sistem pangiriman. Alice jeung Bob manggihan yén maranéhna bisa dibeulah tim kana tim microservice gawe dina paralel;
- bisa nyieun 30-50 parobahan proyék unggal poé ngaliwatan usaha unggal grup na coba téhnik anyar;
- éta gampang pikeun narik pamekar anyar pikeun proyék, anu boga kasempetan pikeun gulung kaluar apdet pikeun produksi ngagunakeun requests tarikan dina sababaraha jam;
- gampang lulus audit dina kerangka SOC2 (pikeun patuh panyadia ladenan kana sarat pikeun ngokolakeun data anu aman; baca deui, contona, - kira-kira. tarjamah.).
Aya naon?
GitOps nyaéta dua hal:
- Modél operasional pikeun Kubernetes sareng cloud native. Éta nyayogikeun sakumpulan prakték pangsaéna pikeun nyebarkeun, ngatur, sareng ngawaskeun klaster sareng aplikasi wadahna. Definisi elegan dina bentuk от :
- Jalan pikeun nyiptakeun lingkungan manajemén aplikasi anu dipusatkeun ku pamekar. Kami nerapkeun alur kerja Git pikeun operasi sareng pamekaran. Punten dicatet yén ieu sanés ngan ukur ngeunaan push Git, tapi ngeunaan ngatur sadaya set alat CI / CD sareng UI / UX.
Sababaraha kecap ngeunaan Git
Upami anjeun teu wawuh sareng sistem kontrol versi sareng alur kerja berbasis Git, kami nyarankeun pisan diajar ngeunaan éta. Gawe sareng dahan sarta narik requests bisa sigana kawas black magic dina mimitina, tapi mangpaat anu patut usaha. Ieuh pikeun ngamimitian.
Kumaha Kubernetes jalan
Dina carita urang, Alice sareng Bob tos ka GitOps saatos damel sareng Kubernetes sakedap. Mémang, GitOps raket patalina sareng Kubernetes - éta mangrupikeun modél operasional pikeun infrastruktur sareng aplikasi dumasar kana Kubernetes.
Naon anu dipasihkeun ku Kubernetes ka pangguna?
Ieu sababaraha fitur utama:
- Dina modél Kubernetes, sadayana tiasa dijelaskeun dina bentuk déklaratif.
- Pangladén API Kubernetes nyandak deklarasi ieu salaku input teras teras-terasan nyobian mawa klaster kana kaayaan anu dijelaskeun dina deklarasi.
- Déklarasi cukup pikeun ngajelaskeun sareng ngatur rupa-rupa beban kerja - "aplikasi".
- Hasilna, parobihan kana aplikasi sareng klaster lumangsung kusabab:
- parobahan dina gambar wadahna;
- parobahan spésifikasi déklaratif;
- kasalahan dina lingkungan - contona, wadahna ngadat.
Kamampuhan Konvergénsi Agung Kubernetes
Nalika kuncén nyieun parobahan konfigurasi, orkestra Kubernetes bakal nerapkeunana kana klaster salami kaayaanana moal datangna deukeut konfigurasi anyar. Modél ieu lumaku pikeun sagala sumberdaya Kubernetes sarta extensible kalawan Custom Resource Definitions (CRDs). Ku alatan éta, panyebaran Kubernetes ngagaduhan sipat anu saé ieu:
- Automation: Pembaruan Kubernetes nyadiakeun mékanisme pikeun ngajadikeun otomatis prosés nerapkeun parobahan anggun sareng dina waktosna.
- Konvergénsi: Kubernetes bakal terus nyobian apdet nepi ka suksés.
- Idémpotensi: Aplikasi konvergénsi anu diulang-ulang ngakibatkeun hasil anu sami.
- Determinisme: Lamun sumberdaya cukup, kaayaan klaster diropéa ngan gumantung kana kaayaan dipikahoyong.
Kumaha GitOps jalan
Urang geus cukup diajar ngeunaan Kubernetes pikeun ngajelaskeun kumaha GitOps jalan.
Hayu urang uih deui ka tim microservices Asuransi Kulawarga. Naon anu biasana aranjeunna kedah laksanakeun? Tingali daptar di handap ieu (upami aya barang anu sigana anéh atanapi teu biasa, punten tahan kana kritik sareng tetep sareng kami). Ieu ngan conto workflows dumasar Jenkins. Aya seueur prosés anu sanés nalika damel sareng alat anu sanés.
Hal utama nyaéta yén urang ningali yén unggal pembaruan ditungtungan ku parobihan kana file konfigurasi sareng repositori Git. Parobihan ieu kana Git nyababkeun "operator GitOps" ngapdet kluster:
1. Prosés gawé: "Jenkins ngawangun - master cabang".
Daptar tugas:
- Jenkins ngadorong gambar tagged ka Quay;
- Jenkins ngadorong config na Helm grafik kana ember gudang master;
- Fungsi awan nyalin konfigurasi sareng bagan tina ember gudang master ka gudang master Git;
- Operator GitOps ngamutahirkeun klaster.
2. Jenkins ngawangun - ngaleupaskeun atanapi hotfix cabang:
- Jenkins ngadorong gambar untagged mun Quay;
- Jenkins ngadorong config na Helm grafik kana ember gudang pementasan;
- Fungsi awan nyalin konfigurasi sareng bagan tina ember gudang pementasan ka gudang Git pementasan;
- Operator GitOps ngamutahirkeun klaster.
3. Jenkins ngawangun - ngamekarkeun atanapi fitur cabang:
- Jenkins ngadorong gambar untagged mun Quay;
- Jenkins ngadorong config na Helm grafik kana ember gudang ngamekarkeun;
- Fungsi awan nyalin konfigurasi sareng bagan tina ember gudang ngembangkeun ka gudang Git ngembang;
- Operator GitOps ngamutahirkeun klaster.
4. Nambahkeun klien anyar:
- Manajer atanapi administrator (LCM / ops) nyauran Gradle pikeun mimiti nyebarkeun sareng ngonpigurasikeun kasaimbangan beban jaringan (NLBs);
- LCM / ops commits a config anyar pikeun nyiapkeun deployment pikeun apdet;
- Operator GitOps ngamutahirkeun klaster.
Katerangan ringkes ngeunaan GitOps
- Nerangkeun kaayaan anu dipikahoyong tina sakabéh sistem ngagunakeun spésifikasi déklaratif pikeun tiap lingkungan (dina carita urang, tim Bob nangtukeun sakabéh konfigurasi sistem di Git).
- Repositori Git mangrupikeun sumber tunggal bebeneran ngeunaan kaayaan anu dipikahoyong tina sakabéh sistem.
- Sadaya parobihan kana kaayaan anu dipikahoyong dilakukeun ku commits di Git.
- Sadaya parameter klaster anu dipikahoyong ogé tiasa ditingali dina kluster sorangan. Ku cara kieu urang bisa nangtukeun naha éta coincide (konvergen, konvergénsi) atawa béda (diverge, nyimpang) kaayaan nu dipikahoyong tur observasi.
- Upami kaayaan anu dipikahoyong sareng anu dititénan béda, maka:
- Aya mékanisme konvergénsi nu sooner atanapi engké otomatis nyingkronkeun udagan jeung kaayaan observasi. Di jero kluster, Kubernetes ngalakukeun ieu.
- Prosésna dimimitian geuwat ku "robah komitmen" ngageter.
- Saatos sababaraha waktos anu tiasa dikonpigurasikeun, waspada "diff" tiasa dikirim upami nagara-nagara béda.
- Ku cara ieu, sadaya komitmen dina Git nyababkeun apdet anu tiasa diverifikasi sareng idempoten kana kluster.
- Rollback nyaéta konvergénsi kana kaayaan anu dipikahoyong.
- Konvergénsi nyaéta final. Kajadianna dituduhkeun ku:
- Henteu aya béwara bénten pikeun sababaraha waktos.
- "konvergen" waspada (misalna webhook, acara writeback Git).
Naon ari divergénsi?
Hayu urang malikan deui: sagala sipat klaster dipikahoyong kudu observasi dina klaster sorangan.
Sababaraha conto divergénsi:
- Parobihan dina file konfigurasi kusabab ngahijikeun cabang di Git.
- Parobihan dina file konfigurasi kusabab komitmen Git anu dilakukeun ku klien GUI.
- Sababaraha parobihan kana kaayaan anu dipikahoyong kusabab PR di Git dituturkeun ku ngawangun gambar wadah sareng parobihan konfigurasi.
- Parobahan dina kaayaan klaster alatan kasalahan, konflik sumberdaya hasilna "kalakuan goréng", atawa ngan saukur simpangan acak tina kaayaan aslina.
Naon mékanisme konvergénsi?
Sababaraha conto:
- Pikeun wadah sareng klaster, mékanisme konvergénsi disayogikeun ku Kubernetes.
- Mékanisme anu sami tiasa dianggo pikeun ngatur aplikasi sareng desain berbasis Kubernetes (sapertos Istio sareng Kubeflow).
- Mékanisme pikeun ngatur interaksi operasional antara Kubernetes, repositori gambar sareng Git nyayogikeun , anu mangrupa bagian .
- Pikeun mesin dasar, mékanisme konvergénsi kedah deklaratif sareng otonom. Ti pangalaman urang sorangan bisa disebutkeun yen pangdeukeutna kana harti ieu, tapi masih merlukeun kontrol manusa. Dina hal ieu, GitOps ngalegaan tradisi Infrastruktur salaku Kode.
GitOps ngagabungkeun Git sareng mesin konvergénsi unggulan Kubernetes pikeun nyayogikeun modél pikeun eksploitasi.
GitOps ngamungkinkeun urang nyarios: Ngan ukur sistem anu tiasa dijelaskeun sareng dititénan tiasa otomatis sareng dikawasa.
GitOps dimaksudkeun pikeun sakabéh tumpukan asli awan (contona, Terraform, jsb.)
GitOps sanés ngan ukur Kubernetes. Kami hoyong sadayana sistem didorong sacara déklaratif sareng nganggo konvergénsi. Ku sakabéh sistem kami hartosna kumpulan lingkungan gawé bareng Kubernetes - contona, "dev cluster 1", "produksi", jsb Unggal lingkungan ngawengku mesin, klaster, aplikasi, kitu ogé interfaces pikeun layanan éksternal anu nyadiakeun data, monitoring. jeung sajabana.
Perhatikeun kumaha pentingna Terraform pikeun masalah bootstrapping dina hal ieu. Kubernetes kedah disebarkeun dimana waé, sareng nganggo Terraform hartosna urang tiasa nerapkeun alur kerja GitOps anu sami pikeun nyiptakeun lapisan kontrol anu ngadukung Kubernetes sareng aplikasi. Ieu prakték pangalusna mangpaat.
Aya fokus anu kuat pikeun nerapkeun konsép GitOps kana lapisan di luhur Kubernetes. Ayeuna, aya solusi tipe GitOps pikeun Istio, Helm, Ksonnet, OpenFaaS sareng Kubeflow, kitu ogé, contona, pikeun Pulumi, anu nyiptakeun lapisan pikeun ngembangkeun aplikasi pikeun awan asli.
Kubernetes CI / CD: ngabandingkeun GitOps kalawan pendekatan séjén
Sakumaha anu dinyatakeun, GitOps mangrupikeun dua hal:
- Model operasi pikeun Kubernetes sareng cloud native ditétélakeun di luhur.
- Jalur ka lingkungan manajemén aplikasi-centric pamekar.
Pikeun seueur, GitOps utamina mangrupikeun alur kerja dumasar kana dorongan Git. Urang ogé resep anjeunna. Tapi éta henteu sadayana: hayu urang tingali jalur pipa CI / CD.
GitOps ngamungkinkeun panyebaran kontinyu (CD) pikeun Kubernetes
GitOps nawiskeun mékanisme panyebaran kontinyu anu ngaleungitkeun kabutuhan "sistem manajemén penyebaran" anu misah. Kubernetes ngalakukeun sagala pagawean pikeun anjeun.
- Ngamutahirkeun aplikasi merlukeun apdet di Git. Ieu mangrupikeun pembaruan transaksional kana kaayaan anu dipikahoyong. "Panyebaran" teras dilakukeun dina kluster ku Kubernetes sorangan dumasar kana pedaran anu diropéa.
- Kusabab sifat kumaha Kubernetes jalan, apdet ieu konvergen. Ieu nyadiakeun mékanisme pikeun deployment kontinyu nu sagala apdet anu atom.
- Catetan: nawarkeun hiji operator GitOps nu integrates Git na Kubernetes tur ngamungkinkeun CD bisa dipigawé ku reconciling kaayaan dipikahoyong tur ayeuna tina klaster.
Tanpa kubectl sareng skrip
Anjeun kedah ngahindarkeun ngagunakeun Kubectl pikeun ngapdet klaster anjeun, sareng khususna ulah ngagunakeun skrip pikeun ngagolongkeun paréntah kubectl. Sabalikna, kalayan pipa GitOps, pangguna tiasa ngapdet klaster Kubernetes na via Git.
Mangpaat ngawengku:
- Leres. Grup apdet tiasa diterapkeun, konvergen sareng tungtungna disahkeun, ngadeukeutkeun urang kana tujuan panyebaran atom. Sabalikna, ngagunakeun skrip henteu masihan jaminan konvergénsi (langkung seueur ngeunaan ieu di handap).
- kasalametan. Kelsey Hightower: "Batesan aksés ka klaster Kubernetes anjeun pikeun alat otomatis sareng pangurus anu tanggung jawab pikeun debugging atanapi ngajaga éta." tingali ogé ngeunaan kaamanan sareng patuh spésifikasi téknis, ogé ku maok credentials tina naskah Jenkins carelessly ditulis.
- Pangalaman pamaké. Kubectl ngungkabkeun mékanika modél obyék Kubernetes, anu cukup rumit. Ideally, pamaké kudu berinteraksi sareng sistem dina tingkat luhur abstraksi. Di dieu kuring bakal ngarujuk deui ka Kelsey sareng nyarankeun nonton .
Beda antara CI jeung CD
GitOps ningkatkeun model CI/CD anu tos aya.
Server CI modern mangrupikeun alat orkestrasi. Khususna, éta mangrupikeun alat pikeun ngatur saluran pipa CI. Ieu kalebet ngawangun, uji, ngagabung ka batang, jsb. server CI ngajadikeun otomatis manajemén pipa multi-hambalan anu kompleks. Godaan umum nyaéta skrip sakumpulan apdet Kubernetes sareng ngajalankeunana salaku bagian tina pipa pikeun nyorong parobahan kana kluster. Mémang, ieu anu dilakukeun ku seueur ahli. Nanging, ieu henteu optimal, sareng ieu sababna.
CI kedah dianggo pikeun nyorong apdet kana trunk, sareng klaster Kubernetes kedah ngarobih sorangan dumasar kana apdet éta pikeun ngatur CD sacara internal. Urang sebut wae , Teu kawas modél push CI. CD mangrupa bagian orkestrasi runtime.
Naha Server CI Henteu Kedah Ngadamel CD ngalangkungan Pembaruan Langsung di Kubernetes
Ulah make server CI pikeun orchestrate apdet langsung ka Kubernetes salaku susunan jobs CI. Ieu mangrupikeun pola anti anu urang bahas dina blog anjeun.
Hayu urang balik ka Alice jeung Bob.
Masalah naon anu aranjeunna nyanghareupan? server CI Bob urang nerapkeun parobahan klaster, tapi lamun eta ngadat dina prosés, Bob moal nyaho naon kaayaan kluster nyaeta (atawa kudu) atawa kumaha carana ngalereskeun eta. Sarua bener bisi sukses.
Hayu urang nganggap yén tim Bob urang ngawangun gambar anyar lajeng patched deployments maranéhna pikeun nyebarkeun gambar (sadayana tina pipa CI).
Lamun gambar ngawangun normal, tapi pipa gagal, tim kudu angka kaluar:
- Naha pembaruan parantos diluncurkeun?
- Naha urang ngaluncurkeun wangunan anyar? Naha ieu bakal ngakibatkeun efek samping anu teu dipikabutuh - kalayan kamungkinan gaduh dua ngawangun gambar anu teu tiasa dirobih?
- Naha urang kedah ngantosan pembaruan salajengna sateuacan ngajalankeun ngawangun?
- Naon kahayang nu salah? Léngkah mana anu kedah diulang (sareng mana anu aman pikeun diulang)?
Ngadegkeun alur kerja basis Git henteu ngajamin yén tim Bob moal mendakan masalah ieu. Éta kénéh bisa nyieun kasalahan jeung commit push, tag, atawa sababaraha parameter séjén; kumaha oge, pendekatan ieu masih leuwih deukeut ka hiji eksplisit sagala-atawa-euweuh pendekatan.
Pikeun nyimpulkeun, ieu naha server CI henteu kedah ngurus CD:
- Aksara Update henteu salawasna deterministik; Gampang nyieun kasalahan dina aranjeunna.
- server CI teu konvergen kana model klaster déklaratif.
- Hese ngajamin idémpotensi. Pamaké kedah ngartos semantik jero sistem.
- Leuwih hese cageur tina gagal parsial.
Catetan ngeunaan Helm: Upami anjeun hoyong nganggo Helm, kami nyarankeun anjeun ngagabungkeun sareng operator GitOps sapertos . Ieu bakal ngabantu mastikeun konvergénsi. Helm sorangan henteu deterministik atanapi atom.
GitOps salaku cara anu pangsaéna pikeun nerapkeun Pangiriman Terus-terusan pikeun Kubernetes
Tim Alice sareng Bob ngalaksanakeun GitOps sareng mendakan yén éta parantos langkung gampil damel sareng produk parangkat lunak, ngajaga kinerja anu luhur sareng stabilitas. Hayu urang mungkas tulisan ieu ku ilustrasi anu nunjukkeun kumaha pendekatan anyarna. Émut yén kami biasana ngobrol ngeunaan aplikasi sareng jasa, tapi GitOps tiasa dianggo pikeun ngatur sadaya platform.
Model operasi pikeun Kubernetes
Tingali dina diagram di handap ieu. Éta nampilkeun Git sareng gudang gambar wadahna salaku sumber daya anu dibagikeun pikeun dua siklus hirup anu disusun:
- Pipa integrasi kontinyu anu maca sareng nyerat file ka Git sareng tiasa ngapdet gudang gambar wadahna.
- Pipa Runtime GitOps anu ngagabungkeun panyebaran sareng manajemén sareng observasi. Éta maca sareng nyerat file ka Git sareng tiasa ngaunduh gambar wadahna.
Naon papanggihan utama?
- Pisahkeun kahariwang: Perhatikeun yén duanana pipelines ngan bisa komunikasi ku ngamutahirkeun Git atawa gudang gambar. Dina basa sejen, aya firewall antara CI jeung lingkungan runtime. Kami nyebatna "firewall immutability" (firewall imutability), saprak sadaya apdet gudang nyieun versi anyar. Kanggo inpo nu langkung lengkep ihwal topik ieu, tingal slides 72-87 .
- Anjeun tiasa nganggo server CI sareng Git naon waé: GitOps jalan kalawan komponén naon. Anjeun tiasa teras-terasan nganggo server CI sareng Git karesep anjeun, repositori gambar, sareng suite tés. Ampir kabéh parabot Pangiriman Kontinyu séjén dina pasaran merlukeun server CI / Git sorangan atawa gudang gambar. Ieu tiasa janten faktor ngawatesan dina pamekaran awan asli. Kalayan GitOps, anjeun tiasa nganggo alat anu biasa.
- Kajadian salaku alat integrasi: Pas data di Git diropéa, Weave Flux (atawa operator Weave Cloud) ngabéjaan runtime. Iraha waé Kubernetes nampi set parobihan, Git diropéa. Ieu nyadiakeun modél integrasi basajan pikeun ngatur workflows pikeun GitOps, sakumaha ditémbongkeun di handap ieu.
kacindekan
GitOps nyayogikeun jaminan pembaruan anu kuat anu diperyogikeun ku alat CI/CD modern:
- otomatis;
- konvergénsi;
- idémpotensi;
- determinisme.
Ieu penting sabab nawiskeun model operasional pikeun pamekar asli awan.
- Alat tradisional pikeun ngatur sareng ngawaskeun sistem pakait sareng tim operasi anu beroperasi dina buku runbook (sakumpulan prosedur sareng operasi rutin - kira-kira transl.), dihijikeun ka deployment husus.
- Dina manajemén pribumi awan, alat observasi mangrupikeun cara anu pangsaéna pikeun ngukur hasil panyebaran supados tim pangembangan tiasa ngaréspon gancang.
Bayangkeun seueur klaster anu sumebar di awan anu béda sareng seueur jasa sareng tim sareng rencana panyebaran sorangan. GitOps nawiskeun modél skala-invarian pikeun ngatur sadaya kaayaanana ieu.
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «".
Ngan pamaké nu kadaptar bisa ilubiung dina survey. , Punten.
Naha anjeun terang ngeunaan GitOps sateuacan dua tarjamahan ieu muncul dina Habré?
-
Sumuhun, abdi terang sagalana
-
Ukur deet
-
teu
35 pamaké milih. 10 pamaké abstained.
sumber: www.habr.com