Piraniya me, ku di blogosfera IT an konferansê de têgehek nû ya din dibînin, zû an dereng pirsek wusa dipirsin: "Ev çi ye? Tenê peyvek din, "gotinek" an tiştek bi rastî hêjayî baldarî, lêkolîn û soza asoyên nû ye?" Li ser termê jî heman tişt hat serê min GitOps berî demekê. Çekdar bi gelek gotarên heyî, û her weha zanîna hevkarên pargîdaniyê
Bi awayê, li ser nûbûna termê GitOps Rapirsiya me ya vê dawiyê jî dibêje: pitir ji nîvê wan lêkolînan hîn bi prensîbên wê dest bi xebatê nekirine.
Ji ber vê yekê, pirsgirêka rêveberiya binesaziyê ne nû ye. Gelek pêşkêşkerên ewr bi dehan sal in ku ji raya giştî re peyda bûne û, wusa dixuye, divê xebata tîmên berpirsiyar ên binesaziyê sade û sade bikira. Lêbelê, dema ku bi pêvajoya pêşkeftina serîlêdanê re (ku otomasyon digihîje astên nû) têne berhev kirin, projeyên binesaziyê hîna jî pir caran gelek peywirên destan vedihewîne û pêdivî bi zanîn û pisporiya pispor heye, nemaze ku hewcedariyên îroyîn ên ji bo tolerasyona xeletiyê, nermbûn, pîvanbûn û elastîkbûnê têne dayîn.
Karûbarên Cloud van hewcedariyên pir serketî bicîh anîn û ew bûn ku hêzek girîng dan pêşkeftina nêzîkbûnê. IaC. Ev tê fêmkirin. Beriya her tiştî, wan mimkun kir ku meriv navendek daneya bi tevahî virtual mîheng bike: serverek laşî, rakêş, an hêmanên torê tune; tevahî binesaziya bi karanîna nivîsar û pelên mîhengê dikare were vegotin.
Ji ber vê yekê bi rastî cûdahî çi ye? GitOps ji IaC? Bi vê pirsê min dest bi lêkolîna xwe kir. Piştî ku bi hevalbendan re peyivî, min karî berhevoka jêrîn derxim holê:
GitOps
IaC
Hemî kod di depoyek git de têne hilanîn
Guhertoya kodê vebijarkî ye
Daxuyaniya Koda Daxuyaniyê / Nerazîbûn
Hem ravekirinên diyarker û hem jî yên ferzî têne qebûlkirin
Guhertin bi karanîna mekanîzmayên Daxwaza Merge / Daxwaza Bikişîne bandor dibin
Peyman, pejirandin û hevkarî vebijarkî ne
Pêvajoya derxistina nûvekirinê otomatîk e
Pêvajoya nûvekirina nûvekirinê ne standardkirî ye (xweber, destan, kopîkirina pelan, karanîna rêzika fermanê, hwd.)
Bi gotineke din GitOps tam bi sepandina prensîban çêbûye IaC. Pêşîn, binesaz û veavakirin naha dikarin bi heman awayê serlêdanan werin hilanîn. Kod hilanîn, parvekirin, berhevkirin û karanîna guhertoyên hêsan hêsan e. Versiyon, şax, dîrok. Û ev hemî li cîhek ku bi gelemperî ji tevahiya tîmê re tê gihîştin. Ji ber vê yekê, karanîna pergalên kontrolkirina guhertoyê bû pêşkeftinek bi tevahî xwezayî. Bi taybetî, git, wekî ya herî populer.
Ji hêla din ve, gengaz bû ku pêvajoyên rêveberiya binesaziyê otomatîk bikin. Naha ev dikare zûtir, pêbawertir û erzantir were kirin. Wekî din, prensîbên CI / CD-ê di nav pêşdebirên nermalavê de jixwe nas û populer bûn. Tenê pêdivî bû ku zanyarî û jêhatîbûna berê ya naskirî li herêmek nû were veguheztin û sepandin. Lêbelê, van pratîkan ji pênaseya standard ya Binesaziyê wekî kod derbas bûn, ji ber vê yekê têgîn GitOps.
Miraq GitOps, bê guman, di heman demê de ew ne hilberek, pêvek an platformek e ku bi tu firoşkarê ve girêdayî ye. Ew bêtir paradîgmayek û komek prensîban e, mîna termek din a ku em pê re nas dikin: DevOps.
Di şirketê de
GitOps metodolojîyek e ku prensîbên çêtirîn DevOps-ê yên ku ji bo pêşkeftina serîlêdanê têne bikar anîn, wekî kontrolkirina guhertoyê, hevkarî, orkestrasyon, CI / CD digire, û wan li ser kêşeyên rêveberiya binesaziya otomatîkî bicîh tîne.
Hemû pêvajoyên GitOps Ez bi karanîna amûrên heyî dixebitim. Hemî koda binesaziyê di depoya git-ê ya jixwe naskirî de tête hilanîn, guhertin di heman pêvajoya pejirandinê de wekî kodek bernameyek din derbas dibe, û pêvajoya avêtinê otomatîk e, ku rê dide me ku em xeletiyên mirovî kêm bikin, pêbawerî û dubarebûnê zêde bikin.
Ji hêla pratîkî ve, em rave dikin GitOps wiha ye:
Me berê binesaziyê wekî kodê wekî yek ji hêmanên sereke yên vê formulê nîqaş kiriye. Werin em beşdarên mayî bidin nasîn.
Daxwaza Hevgirtinê (navê alternatîf Daxwaza Bikişîne). Di şertên pêvajoyê de, MR daxwazek e ku meriv guhertinên kodê bicîh bike û dûv re şaxên hev bike. Lê di warê amûrên ku em bikar tînin de, ev bêtir derfetek e ku em wêneyek bêkêmasî ya hemî guhertinên ku têne çêkirin bistînin: ne tenê koda ku ji hejmareke diyarkirî hatî berhev kirin cûda dibe, lê di heman demê de çarçove, encamên testê û encama dawî ya hêvîkirî. Ger em behsa koda binesaziyê dikin, wê hingê em eleqedar dibin ka dê binesaziya tam çawa biguhezîne, dê çend çavkaniyên nû werin zêdekirin an jêbirin, biguhezin. Bi tercîhî di formek hêsantir û xwendinê de hêsan e. Ji bo pêşkêşkerên ewr, ramanek baş e ku hûn zanibin ka dê bandora darayî ya vê guherînê çi be.
Lê MR di heman demê de navgînek hevkarî, têkilî û ragihandinê ye. Cihê ku pergala kontrol û hevsengiyê tê de ye. Ji şîroveyên hêsan bigire heya pejirandin û pejirandinên fermî.
Welê, pêkhateya paşîn: CI/CD, wekî ku em jixwe dizanin, otomatîzekirina pêvajoya çêkirina guhertinên binesaziyê û ceribandinê gengaz dike (ji kontrolkirina hevoksaziya hêsan heya analîza koda statîk a tevlihev). Û her weha di paşerojê de tespîtkirina driftê: cûdahiyên di navbera rewşa rastîn û xwestina pergalê de. Mînakî, wekî encama guhertinên destan ên bêdestûr an têkçûna pergalê.
Erê, term GitOps tiştek bi tevahî nû bi me nade nasîn, çerxê ji nû ve îcad nake, lê tenê ezmûna jixwe berhevkirî li deverek nû bicîh tîne. Lê hêza wî li vir e.
Û heger hûn ji nişkê ve eleqedar bibin ka ev hemî di pratîkê de çawa xuya dike, wê hingê ez we vedixwînim ku hûn li me binêrin
-
Prensîbên bingehîn ên GitOps bicîh bikin
-
Binesaziya cloudê biafirînin û guhertinan bikin (bi mînaka Yandex Cloud bikar bînin)
-
Bi karanîna çavdêriya çalak, vekêşana pergalê ji rewşek xwestî veqetînin
https://bit.ly/34tRpwZ
Source: www.habr.com