Kumbuka. tafsiri.: Baada ya kuchapishwa hivi majuzi kuhusu njia za kuvuta na kusukuma katika GitOps, tuliona kupendezwa na mtindo huu kwa ujumla, lakini kulikuwa na machapisho machache sana ya lugha ya Kirusi kwenye mada hii (hakuna tu kwenye Habre). Kwa hivyo, tunafurahi kukupa tafsiri ya nakala nyingine - angalau mwaka mmoja uliopita! - kutoka kwa Weaveworks, mkuu wake ambaye aliunda neno "GitOps." Nakala inaelezea kiini cha mbinu na tofauti kuu kutoka kwa zilizopo.
Mwaka mmoja uliopita tulichapisha . Hapo zamani, tulishiriki jinsi timu ya Weaveworks ilivyozindua SaaS kabisa kulingana na Kubernetes na kutengeneza seti ya kanuni bora za kupeleka, kudhibiti na ufuatiliaji katika mazingira asilia ya wingu.
Nakala hiyo iligeuka kuwa maarufu. Watu wengine walianza kuzungumza juu ya GitOps na wakaanza kuchapisha zana mpya za , , , , Nakadhalika. Ilionekana kwenye tovuti yetu machapisho na kesi za utumiaji za GitOps. Lakini watu wengine bado wana maswali. Mfano unatofautianaje na ule wa jadi? na utoaji endelevu ()? Je, ni muhimu kutumia Kubernetes?
Hivi karibuni tuligundua kuwa maelezo mapya yanahitajika, kutoa:
- Idadi kubwa ya mifano na hadithi;
- Ufafanuzi maalum wa GitOps;
- Kulinganisha na utoaji wa kawaida wa kawaida.
Katika makala hii tumejaribu kufunika mada hizi zote. Inatoa utangulizi uliosasishwa kwa GitOps na msanidi programu na mtazamo wa CI/CD. Kimsingi tunazingatia Kubernetes, ingawa modeli inaweza kuwa ya jumla.
Kutana na GitOps
Mfikirie Alice. Anaendesha Bima ya Familia, ambayo hutoa bima ya afya, magari, nyumba, na usafiri kwa watu ambao wana shughuli nyingi sana kuweza kubaini mambo ya ndani na nje ya mikataba wenyewe. Biashara yake ilianza kama mradi wa kando wakati Alice alipokuwa akifanya kazi katika benki kama mwanasayansi wa data. Siku moja aligundua kuwa angeweza kutumia algoriti za hali ya juu za kompyuta kuchambua data kwa ufanisi zaidi na kuunda vifurushi vya bima. Wawekezaji walifadhili mradi huo, na sasa kampuni yake inaleta zaidi ya dola milioni 20 kwa mwaka na inakua kwa kasi. Hivi sasa, inaajiri watu 180 katika nyadhifa mbalimbali. Hii inajumuisha timu ya teknolojia ambayo inakuza, kudumisha tovuti, hifadhidata, na kuchanganua msingi wa wateja. Timu hiyo ya watu 60 inaongozwa na Bob, mkurugenzi wa ufundi wa kampuni hiyo.
Timu ya Bob hutumia mifumo ya uzalishaji katika wingu. Maombi yao ya kimsingi yanaendeshwa kwenye GKE, ikitumia fursa ya Kubernetes kwenye Wingu la Google. Kwa kuongeza, hutumia zana mbalimbali za data na uchambuzi katika kazi zao.
Bima ya Familia haikukusudia kutumia kontena, lakini ilinaswa na shauku ya Docker. Hivi karibuni kampuni iligundua kuwa GKE ilifanya iwe rahisi kupeleka vikundi ili kujaribu vipengele vipya. Jenkins za CI na Quay ziliongezwa ili kupanga sajili ya kontena, hati ziliandikwa kwa Jenkins ambazo zilisukuma kontena mpya na usanidi hadi GKE.
Muda fulani umepita. Alice na Bob walikatishwa tamaa na utendaji wa mbinu waliyochagua na athari zake kwenye biashara. Kuanzishwa kwa makontena hakukuza tija kadri timu ilivyotarajia. Wakati mwingine upelekaji ungevunjika, na haikuwa wazi ikiwa mabadiliko ya msimbo yangesababisha lawama. Pia iligeuka kuwa ngumu kufuatilia mabadiliko ya usanidi. Mara nyingi ilihitajika kuunda nguzo mpya na kuhamisha programu kwake, kwani hii ilikuwa njia rahisi ya kuondoa fujo ambazo mfumo ulikuwa. Alice aliogopa kwamba hali ingezidi kuwa mbaya zaidi kadiri programu inavyoendelea (kwa kuongezea, mradi mpya unaotegemea ujifunzaji wa mashine ulikuwa ukitayarishwa). Bob alikuwa amejiendesha kiotomatiki sehemu kubwa ya kazi na hakuelewa ni kwa nini bomba bado halijaimarika, halikua vizuri, na alihitaji uingiliaji kati wa mikono mara kwa mara?
Kisha wakajifunza kuhusu GitOps. Uamuzi huu uligeuka kuwa kile walichohitaji ili kusonga mbele kwa ujasiri.
Alice na Bob wamekuwa wakisikia kuhusu Git, DevOps, na miundombinu kama utiririshaji wa kanuni kwa miaka. Kilicho cha kipekee kuhusu GitOps ni kwamba huleta seti ya mazoea boraβya uhakika na ya kawaidaβya kutekeleza mawazo haya katika muktadha wa Kubernetes. Mada hii , ikiwa ni pamoja na katika .
Bima ya Familia inaamua kutekeleza GitOps. Kampuni sasa ina modeli ya uendeshaji otomatiki ambayo inaoana na Kubernetes na inachanganya kasi na utulivukwa sababu wali:
- iligundua kuwa tija ya timu iliongezeka maradufu bila mtu yeyote kuwa kichaa;
- iliacha kutumikia hati. Badala yake, sasa wanaweza kuzingatia vipengele vipya na kuboresha mbinu za uhandisi - kwa mfano, kuanzisha uchapishaji wa canary na kuboresha majaribio;
- tumeboresha mchakato wa upelekaji ili usivunjike mara chache;
- alipata fursa ya kurejesha kupelekwa baada ya kushindwa kwa sehemu bila uingiliaji wa mwongozo;
- kununuliwa kutumikaΠΎKujiamini zaidi katika mifumo ya utoaji. Alice na Bob waligundua kwamba wanaweza kugawanya timu katika timu ndogo za huduma zinazofanya kazi kwa usawa;
- wanaweza kufanya mabadiliko 30-50 kwa mradi kila siku kupitia juhudi za kila kikundi na kujaribu mbinu mpya;
- ni rahisi kuvutia watengenezaji wapya kwenye mradi, ambao wana fursa ya kusambaza sasisho za uzalishaji kwa kutumia maombi ya kuvuta ndani ya saa chache;
- kupitisha ukaguzi kwa urahisi ndani ya mfumo wa SOC2 (kwa kufuata watoa huduma na mahitaji ya usimamizi salama wa data; soma zaidi, kwa mfano, - takriban. tafsiri.).
Nini kimetokea?
GitOps ni vitu viwili:
- Muundo wa uendeshaji wa Kubernetes na asili ya mtandaoni. Inatoa seti ya mbinu bora za kupeleka, kudhibiti, na kufuatilia makundi na programu zilizojumuishwa. Ufafanuzi wa kifahari katika fomu kutoka :
- Njia ya kuunda mazingira ya usimamizi wa programu inayozingatia msanidi programu. Tunatumia mtiririko wa kazi wa Git kwa utendakazi na ukuzaji. Tafadhali kumbuka kuwa hii sio tu juu ya kushinikiza kwa Git, lakini juu ya kupanga seti nzima ya zana za CI/CD na UI/UX.
Maneno machache kuhusu Git
Ikiwa hujui mifumo ya udhibiti wa matoleo na mtiririko wa kazi unaotegemea Git, tunapendekeza sana kujifunza kuihusu. Kufanya kazi na matawi na maombi ya kuvuta kunaweza kuonekana kama uchawi mweusi mwanzoni, lakini faida zinafaa kujitahidi. Hapa kuanza.
Jinsi Kubernetes inavyofanya kazi
Katika hadithi yetu, Alice na Bob waligeukia GitOps baada ya kufanya kazi na Kubernetes kwa muda. Hakika, GitOps inahusiana kwa karibu na Kubernetes - ni mfano wa uendeshaji wa miundombinu na programu kulingana na Kubernetes.
Kubernetes inawapa nini watumiaji?
Hapa kuna baadhi ya vipengele kuu:
- Katika mfano wa Kubernetes, kila kitu kinaweza kuelezewa kwa fomu ya kutangaza.
- Seva ya Kubernetes API inachukua tamko hili kama ingizo na kisha hujaribu kila mara kuleta kundi katika hali iliyoelezwa kwenye tamko.
- Matamko yanatosha kueleza na kudhibiti aina mbalimbali za mizigo ya kaziββprogramu.β
- Kama matokeo, mabadiliko katika programu na nguzo hufanyika kwa sababu ya:
- mabadiliko katika picha za chombo;
- mabadiliko katika maelezo ya kutangaza;
- makosa katika mazingira - kwa mfano, ajali za chombo.
Uwezo Mkubwa wa Muunganisho wa Kubernetes
Wakati msimamizi anafanya mabadiliko ya usanidi, orchestrator ya Kubernetes itazitumia kwenye nguzo mradi tu hali yake iko. haitakuja karibu na usanidi mpya. Muundo huu unafanya kazi kwa rasilimali yoyote ya Kubernetes na unaweza kupanuliwa kwa Ufafanuzi wa Rasilimali Maalum (CRDs). Kwa hivyo, upelekaji wa Kubernetes una mali zifuatazo nzuri:
- Operesheni: Masasisho ya Kubernetes hutoa utaratibu wa kubinafsisha mchakato wa kutumia mabadiliko kwa uzuri na kwa wakati ufaao.
- Muunganiko: Kubernetes itaendelea kujaribu masasisho hadi ifanikiwe.
- Upungufu: Utumizi unaorudiwa wa muunganisho husababisha matokeo sawa.
- Uamuzi: Wakati rasilimali zinatosha, hali ya nguzo iliyosasishwa inategemea tu hali inayotakiwa.
Jinsi GitOps inavyofanya kazi
Tumejifunza vya kutosha kuhusu Kubernetes kuelezea jinsi GitOps inavyofanya kazi.
Hebu turejee kwa timu za huduma ndogo za Bima ya Familia. Je, kwa kawaida wanapaswa kufanya nini? Tazama orodha iliyo hapa chini (ikiwa vitu vyovyote ndani yake vinaonekana kuwa vya kustaajabisha au visivyojulikana, tafadhali jizuie na ukosoaji na ubaki nasi). Hii ni mifano tu ya mtiririko wa kazi wa Jenkins. Kuna michakato mingine mingi wakati wa kufanya kazi na zana zingine.
Jambo kuu ni kwamba tunaona kwamba kila sasisho linaisha na mabadiliko ya faili za usanidi na hazina za Git. Mabadiliko haya kwa Git husababisha "mendeshaji wa GitOps" kusasisha nguzo:
1. Mchakato wa kufanya kazi: "Jenkins kujenga - bwana tawi'.
Orodha ya kazi:
- Jenkins anasukuma picha zilizowekwa alama kwenye Quay;
- Jenkins husukuma chati za usanidi na Helm kwenye ndoo kuu ya kuhifadhi;
- Kitendaji cha wingu kinakili usanidi na chati kutoka kwa ndoo kuu ya hifadhi hadi hazina kuu ya Git;
- Opereta wa GitOps husasisha nguzo.
2. Jenkins kujenga - kutolewa au hotfix tawi:
- Jenkins anasukuma picha ambazo hazijatambulishwa kwa Quay;
- Jenkins husukuma chati za usanidi na Helm kwenye ndoo ya kuhifadhi;
- Kitendaji cha wingu kinakili usanidi na chati kutoka kwa ndoo ya hifadhi hadi kwenye hazina ya jukwaa la Git;
- Opereta wa GitOps husasisha nguzo.
3. Jenkins kujenga - kuendeleza au kipengele tawi:
- Jenkins anasukuma picha ambazo hazijatambulishwa kwa Quay;
- Jenkins husukuma chati za usanidi na Helm kwenye ndoo ya kuhifadhi;
- Kitendaji cha wingu kunakili usanidi na chati kutoka kwa ndoo ya uhifadhi ya ukuzaji hadi hazina ya Git ya kukuza;
- Opereta wa GitOps husasisha nguzo.
4. Kuongeza mteja mpya:
- Meneja au msimamizi (LCM/ops) huita Gradle kupeleka na kusanidi visawazishi vya mzigo wa mtandao (NLBs);
- LCM/ops huweka usanidi mpya ili kuandaa utumaji kwa masasisho;
- Opereta wa GitOps husasisha nguzo.
Maelezo mafupi ya GitOps
- Eleza hali inayotakikana ya mfumo mzima kwa kutumia vipimo vya kubainisha kwa kila mazingira (katika hadithi yetu, timu ya Bob inafafanua usanidi mzima wa mfumo katika Git).
- Hifadhi ya Git ndio chanzo kimoja cha ukweli kuhusu hali inayotakikana ya mfumo mzima.
- Mabadiliko yote kwa hali inayotaka hufanywa kupitia ahadi katika Git.
- Vigezo vyote vya nguzo vinavyohitajika pia vinaonekana kwenye nguzo yenyewe. Kwa njia hii tunaweza kuamua ikiwa zinalingana (kuungana, kugeuza) au kutofautiana (tofautiana, pinduka) majimbo yanayotakiwa na kuzingatiwa.
- Ikiwa hali zinazohitajika na zilizozingatiwa zinatofautiana, basi:
- Kuna utaratibu wa muunganisho ambao mapema au baadaye husawazisha kiotomatiki lengo na hali zinazozingatiwa. Ndani ya nguzo, Kubernetes hufanya hivi.
- Mchakato huanza mara moja na arifa ya "mabadiliko yaliyofanywa".
- Baada ya kipindi fulani cha kusanidiwa, arifa ya "tofauti" inaweza kutumwa ikiwa majimbo ni tofauti.
- Kwa njia hii, ahadi zote katika Git husababisha sasisho zinazoweza kuthibitishwa na zisizo na maana kwa nguzo.
- Kurudisha nyuma ni muunganiko kwa hali iliyotarajiwa hapo awali.
- Muunganiko ni wa mwisho. Kutokea kwake kunaonyeshwa na:
- Hakuna arifa tofauti kwa muda fulani.
- tahadhari "iliyounganishwa" (kwa mfano, webhook, tukio la kuandika nyuma la Git).
Je, tofauti ni nini?
Wacha turudie tena: mali zote zinazohitajika za nguzo lazima zionekane kwenye nguzo yenyewe.
Baadhi ya mifano ya tofauti:
- Badilisha katika faili ya usanidi kwa sababu ya kuunganisha matawi kwenye Git.
- Mabadiliko katika faili ya usanidi kwa sababu ya ahadi ya Git iliyofanywa na mteja wa GUI.
- Mabadiliko mengi kwa hali inayotakiwa kwa sababu ya PR katika Git ikifuatiwa na kujenga picha ya chombo na mabadiliko ya usanidi.
- Mabadiliko katika hali ya kundi kutokana na hitilafu, mzozo wa rasilimali unaosababisha "tabia mbaya", au mkengeuko wa nasibu kutoka kwa hali asilia.
Nini utaratibu wa muunganisho?
Mifano chache:
- Kwa vyombo na makundi, utaratibu wa muunganisho hutolewa na Kubernetes.
- Mbinu sawa inaweza kutumika kudhibiti programu na miundo inayotokana na Kubernetes (kama vile Istio na Kubeflow).
- Utaratibu wa kudhibiti mwingiliano wa uendeshaji kati ya Kubernetes, hazina za picha na Git hutoa , ambayo ni sehemu .
- Kwa mashine za msingi, utaratibu wa muunganisho lazima uwe wa kutangaza na uhuru. Kutokana na uzoefu wetu wenyewe tunaweza kusema hivyo karibu na ufafanuzi huu, lakini bado inahitaji udhibiti wa kibinadamu. Kwa maana hii, GitOps inapanua utamaduni wa Miundombinu kama Kanuni.
GitOps inachanganya Git na injini bora ya muunganisho ya Kubernetes ili kutoa kielelezo cha unyonyaji.
GitOps inaruhusu sisi kusema: Mifumo hiyo tu inayoweza kuelezewa na kuzingatiwa inaweza kuwa otomatiki na kudhibitiwa.
GitOps imekusudiwa kwa mkusanyiko mzima wa asili wa wingu (kwa mfano, Terraform, n.k.)
GitOps sio Kubernetes pekee. Tunataka mfumo mzima uendeshwe kidhahiri na utumie muunganiko. Kwa mfumo mzima tunamaanisha mkusanyiko wa mazingira yanayofanya kazi na Kubernetes - kwa mfano, "dev cluster 1", "uzalishaji", n.k. Kila mazingira yanajumuisha mashine, makundi, programu, pamoja na violesura vya huduma za nje zinazotoa data, ufuatiliaji. na nk.
Tambua jinsi Terraform ilivyo muhimu kwa tatizo la bootstrapping katika kesi hii. Kubernetes inapaswa kutumwa mahali fulani, na kwa kutumia Terraform inamaanisha tunaweza kutumia utiririshaji sawa wa GitOps ili kuunda safu ya udhibiti ambayo inashikilia Kubernetes na programu. Hii ni mazoezi bora yenye manufaa.
Kuna mkazo mkubwa wa kutumia dhana za GitOps kwenye tabaka zilizo juu ya Kubernetes. Kwa sasa, kuna suluhisho za aina ya GitOps kwa Istio, Helm, Ksonnet, OpenFaaS na Kubeflow, na vile vile, kwa mfano, kwa Pulumi, ambayo huunda safu ya kukuza programu kwa asili ya wingu.
Kubernetes CI/CD: kulinganisha GitOps na mbinu zingine
Kama ilivyoelezwa, GitOps ni mambo mawili:
- Muundo wa uendeshaji wa Kubernetes na asili ya mtandaoni ulioelezwa hapo juu.
- Njia ya mazingira ya usimamizi wa programu inayozingatia msanidi programu.
Kwa wengi, GitOps kimsingi ni mtiririko wa kazi kulingana na msukumo wa Git. Tunampenda pia. Lakini sio hivyo tu: hebu sasa tuangalie mabomba ya CI/CD.
GitOps huwezesha usambazaji unaoendelea (CD) kwa Kubernetes
GitOps inatoa utaratibu endelevu wa kupeleka ambao huondoa hitaji la "mifumo tofauti ya usimamizi wa upelekaji." Kubernetes anakufanyia kazi yote.
- Kusasisha programu kunahitaji kusasishwa katika Git. Hili ni sasisho la shughuli kwa hali unayotaka. "Usambazaji" basi hufanywa ndani ya nguzo na Kubernetes yenyewe kulingana na maelezo yaliyosasishwa.
- Kutokana na hali ya jinsi Kubernetes inavyofanya kazi, masasisho haya yanaunganishwa. Hii hutoa utaratibu wa utumiaji unaoendelea ambapo masasisho yote ni ya atomiki.
- Kumbuka: inatoa GitOps opereta ambayo inaunganisha Git na Kubernetes na inaruhusu CD kutekelezwa kwa kupatanisha hali inayotakiwa na ya sasa ya nguzo.
Bila kubectl na maandishi
Unapaswa kuzuia kutumia Kubectl kusasisha nguzo yako, na haswa epuka kutumia hati kupanga maagizo ya kubectl. Badala yake, kwa kutumia bomba la GitOps, mtumiaji anaweza kusasisha nguzo yao ya Kubernetes kupitia Git.
Faida ni pamoja na:
- Haki. Kikundi cha masasisho kinaweza kutumika, kuunganishwa na hatimaye kuthibitishwa, na kutuleta karibu na lengo la uwekaji wa atomiki. Kinyume chake, kutumia hati hakutoi hakikisho lolote la muunganisho (zaidi kuhusu hili hapa chini).
- usalama. Kelsey Hightower: "Zuia ufikiaji wa nguzo yako ya Kubernetes kwa zana za otomatiki na wasimamizi ambao wana jukumu la kutatua au kutunza." Angalia pia kuhusu usalama na kufuata vipimo vya kiufundi, pamoja na kwa kuiba hati tambulishi kutoka kwa hati ya Jenkins iliyoandikwa kizembe.
- Uzoefu wa Mtumiaji. Kubectl anafichua mechanics ya modeli ya kitu cha Kubernetes, ambayo ni changamano kabisa. Kwa kweli, watumiaji wanapaswa kuingiliana na mfumo katika kiwango cha juu cha uondoaji. Hapa nitarejea tena kwa Kelsey na kupendekeza kutazama .
Tofauti kati ya CI na CD
GitOps inaboresha miundo iliyopo ya CI/CD.
Seva ya kisasa ya CI ni chombo cha orchestration. Hasa, ni chombo cha kupanga mabomba ya CI. Hizi ni pamoja na kujenga, kujaribu, kuunganisha hadi shina, n.k. Seva za CI huboresha usimamizi wa mabomba changamano ya hatua nyingi. Jaribio la kawaida ni kuandika seti ya masasisho ya Kubernetes na kuiendesha kama sehemu ya bomba ili kusukuma mabadiliko kwenye nguzo. Kwa kweli, hivi ndivyo wataalam wengi hufanya. Walakini, hii sio sawa, na hii ndio sababu.
CI inapaswa kutumiwa kusukuma masasisho kwenye shina, na nguzo ya Kubernetes inapaswa kujibadilisha yenyewe kulingana na masasisho hayo ili kudhibiti CD ndani. Tunaiita , tofauti na mfano wa kushinikiza wa CI. CD ni sehemu orchestration ya wakati wa kukimbia.
Kwa nini Seva za CI Hazipaswi Kufanya CD kupitia Usasisho wa Moja kwa moja katika Kubernetes
Usitumie seva ya CI kupanga sasisho za moja kwa moja kwa Kubernetes kama seti ya kazi za CI. Huu ndio muundo wa kupinga tunaozungumzia kwenye blogu yako.
Wacha turudi kwa Alice na Bob.
Walipata matatizo gani? Seva ya CI ya Bob itatumia mabadiliko kwenye nguzo, lakini ikiharibika katika mchakato, Bob hatajua nguzo hiyo iko katika hali gani (au inapaswa kuwa) au jinsi ya kuirekebisha. Vile vile ni kweli katika kesi ya mafanikio.
Wacha tuchukue kuwa timu ya Bob iliunda taswira mpya na kisha kuweka viraka upelekaji wao ili kupeleka picha (yote kutoka kwa bomba la CI).
Ikiwa picha itaundwa kawaida, lakini bomba itashindwa, timu italazimika kujua:
- Je, sasisho limetolewa?
- Je, tunazindua jengo jipya? Hii itasababisha athari zisizohitajika - na uwezekano wa kuwa na miundo miwili ya picha sawa isiyoweza kubadilika?
- Je, tungojee sasisho linalofuata kabla ya kuanza ujenzi?
- Nini hasa kiliharibika? Ni hatua gani zinahitaji kurudiwa (na ni zipi ambazo ni salama kurudia)?
Kuanzisha mtiririko wa kazi unaotegemea Git haihakikishi kuwa timu ya Bob haitakumbana na matatizo haya. Bado wanaweza kufanya makosa na kushinikiza ahadi, lebo, au parameta nyingine; hata hivyo, mbinu hii bado iko karibu zaidi na mbinu ya wazi ya yote au hakuna.
Kwa muhtasari, hii ndio sababu seva za CI hazipaswi kushughulika na CD:
- Hati za kusasisha sio za kuamua kila wakati; Ni rahisi kufanya makosa ndani yao.
- Seva za CI haziunganishi kwa muundo wa nguzo unaotangaza.
- Ni vigumu kuhakikisha utambulisho. Watumiaji lazima waelewe semantiki za kina za mfumo.
- Ni vigumu zaidi kupona kutokana na kushindwa kwa sehemu.
Kumbuka kuhusu Helm: Ikiwa unataka kutumia Helm, tunapendekeza kuichanganya na opereta wa GitOps kama vile . Hii itasaidia kuhakikisha muunganisho. Helm yenyewe sio ya kuamua wala ya atomiki.
GitOps kama njia bora ya kutekeleza Uwasilishaji Unaoendelea kwa Kubernetes
Timu ya Alice na Bob inatekeleza GitOps na kugundua kuwa imekuwa rahisi zaidi kufanya kazi na bidhaa za programu, kudumisha utendaji wa juu na utulivu. Wacha tumalizie nakala hii kwa kielelezo kinachoonyesha jinsi mbinu yao mpya inavyoonekana. Kumbuka kwamba tunazungumza zaidi kuhusu programu na huduma, lakini GitOps inaweza kutumika kudhibiti jukwaa zima.
Muundo wa uendeshaji wa Kubernetes
Angalia mchoro ufuatao. Inawasilisha Git na hazina ya picha ya chombo kama rasilimali iliyoshirikiwa kwa mizunguko miwili ya maisha iliyopangwa:
- Bomba la ujumuishaji endelevu ambalo husoma na kuandika faili kwa Git na linaweza kusasisha hazina ya picha za kontena.
- Bomba la Runtime GitOps linalochanganya uwekaji na usimamizi na uangalizi. Inasoma na kuandika faili kwa Git na inaweza kupakua picha za chombo.
Ni nini matokeo kuu?
- Mgawanyiko wa wasiwasi: Tafadhali kumbuka kuwa mabomba yote mawili yanaweza tu kuwasiliana kwa kusasisha Git au hazina ya picha. Kwa maneno mengine, kuna firewall kati ya CI na mazingira ya wakati wa kukimbia. Tunaiita "firewall isiyoweza kubadilika" (firewall isiyoweza kubadilika), kwani masasisho yote ya hazina huunda matoleo mapya. Kwa maelezo zaidi kuhusu mada hii, rejelea slaidi 72-87 .
- Unaweza kutumia seva yoyote ya CI na Git: GitOps inafanya kazi na sehemu yoyote. Unaweza kuendelea kutumia seva zako uzipendazo za CI na Git, hazina za picha, na vyumba vya majaribio. Takriban zana zingine zote za Utoaji Unaoendelea kwenye soko zinahitaji seva yao ya CI/Git au hazina ya picha. Hii inaweza kuwa kikwazo katika ukuzaji wa asili ya wingu. Ukiwa na GitOps, unaweza kutumia zana zinazojulikana.
- Matukio kama zana ya ujumuishaji: Mara tu data katika Git inaposasishwa, Weave Flux (au opereta wa Wingu la Weave) huarifu wakati wa utekelezaji. Wakati wowote Kubernetes inakubali seti ya mabadiliko, Git inasasishwa. Hii inatoa muundo rahisi wa ujumuishaji wa kupanga mtiririko wa kazi kwa GitOps, kama inavyoonyeshwa hapa chini.
Hitimisho
GitOps hutoa uhakikisho dhabiti wa sasisho unaohitajika na zana yoyote ya kisasa ya CI/CD:
- otomatiki;
- muunganiko;
- kutokuwa na uwezo;
- uamuzi.
Hii ni muhimu kwa sababu inatoa mfano wa uendeshaji kwa watengenezaji asili wa wingu.
- Zana za kitamaduni za kudhibiti na ufuatiliaji zinahusishwa na timu za uendeshaji zinazofanya kazi ndani ya kitabu cha rununu (seti ya taratibu na shughuli za kawaida - takriban. transl.), amefungwa kwa kupelekwa maalum.
- Katika usimamizi asilia wa wingu, zana za uangalizi ndio njia bora ya kupima matokeo ya utumaji ili timu ya usanidi iweze kujibu haraka.
Hebu fikiria makundi mengi yaliyotawanyika katika mawingu tofauti na huduma nyingi na timu zao wenyewe na mipango ya kupeleka. GitOps inatoa modeli isiyobadilika kwa kiwango cha kudhibiti wingi huu wote.
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«'.
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. tafadhali.
Je, ulijua kuhusu GitOps kabla ya tafsiri hizi mbili kuonekana kwenye Habre?
-
Ndiyo, nilijua kila kitu
-
Kwa juu juu tu
-
Hakuna
Watumiaji 35 walipiga kura. Watumiaji 10 walijizuia.
Chanzo: mapenzi.com