Wengi wetu, tukigundua neno lingine jipya katika ulimwengu wa blogu au mkutano wa IT, mapema au baadaye huuliza swali kama hilo: "Hii ni nini? Neno lingine tu, "buzzword" au kitu kinachostahili kuzingatiwa kwa karibu, kusoma na kuahidi upeo mpya?" Kitu kimoja kilinitokea kwa muda GitOps muda fulani uliopita. Silaha na makala nyingi zilizopo, pamoja na ujuzi wa wenzake kutoka kampuni , nilijaribu kujua ni aina gani ya mnyama huyu, na matumizi yake yanaweza kuonekanaje katika mazoezi.
Kwa njia, juu ya riwaya ya neno hilo GitOps Utafiti wetu wa hivi majuzi pia unasema: zaidi ya nusu ya wale waliohojiwa bado hawajaanza kufanya kazi na kanuni zake.
Kwa hiyo, tatizo la usimamizi wa miundombinu si geni. Watoa huduma wengi wa wingu wamepatikana kwa umma kwa jumla kwa miaka kadhaa nzuri na, inaweza kuonekana, wangefanya kazi ya timu zinazohusika na miundombinu kuwa rahisi na moja kwa moja. Hata hivyo, ikilinganishwa na mchakato wa ukuzaji maombi (ambapo otomatiki hufikia viwango vipya), miradi ya miundombinu bado mara nyingi huhusisha kazi nyingi za mikono na huhitaji ujuzi na utaalamu maalumu, hasa ikizingatiwa mahitaji ya leo ya uvumilivu wa hitilafu, kunyumbulika, kubadilika na kunyumbulika.
Huduma za wingu zilitimiza mahitaji haya kwa mafanikio sana na ni wao ambao walitoa msukumo mkubwa kwa maendeleo ya mbinu IaC. Hii inaeleweka. Baada ya yote, walifanya iwezekane kusanidi kituo cha data cha kawaida kabisa: hakuna seva halisi, rafu, au vifaa vya mtandao; miundombinu yote inaweza kuelezewa kwa kutumia hati na faili za usanidi.
Kwa hivyo tofauti ni nini hasa? GitOps kutoka IaC? Ilikuwa kwa swali hili kwamba nilianza uchunguzi wangu. Baada ya kuzungumza na wenzangu, niliweza kupata ulinganisho ufuatao:
GitOps
IaC
Nambari zote zimehifadhiwa kwenye hazina ya git
Utoaji wa msimbo ni wa hiari
Ufafanuzi wa Msimbo wa Kutangaza / Kutokuwa na uwezo
Maelezo ya kutangaza na ya lazima yanakubalika
Mabadiliko yanatekelezwa kwa kutumia mbinu za Unganisha Ombi / Vuta
Makubaliano, idhini na ushirikiano ni chaguo
Mchakato wa kutoa sasisho ni otomatiki
Mchakato wa uchapishaji wa sasisho haujasanifishwa (otomatiki, mwongozo, kunakili faili, kwa kutumia safu ya amri, n.k.)
Kwa maneno mengine GitOps alizaliwa kwa usahihi kupitia matumizi ya kanuni IaC. Kwanza, miundombinu na usanidi sasa vinaweza kuhifadhiwa kwa njia sawa na programu. Nambari ni rahisi kuhifadhi, ni rahisi kushiriki, kulinganisha, na kutumia uwezo wa uchapishaji. Matoleo, matawi, historia. Na haya yote katika sehemu inayopatikana hadharani kwa timu nzima. Kwa hiyo, matumizi ya mifumo ya udhibiti wa toleo ikawa maendeleo ya asili kabisa. Hasa, git, kama maarufu zaidi.
Kwa upande mwingine, iliwezekana kubinafsisha michakato ya usimamizi wa miundombinu. Sasa hii inaweza kufanyika kwa kasi zaidi, kwa uhakika zaidi na kwa bei nafuu. Kwa kuongezea, kanuni za CI / CD zilikuwa tayari zinajulikana na maarufu kati ya watengenezaji wa programu. Ilikuwa ni lazima tu kuhamisha na kutumia ujuzi na ujuzi tayari unaojulikana kwa eneo jipya. Mazoea haya, hata hivyo, yalikwenda zaidi ya ufafanuzi wa kawaida wa Miundombinu kama kanuni, kwa hivyo dhana GitOps.
Udadisi GitOps, bila shaka, pia katika ukweli kwamba sio bidhaa, programu-jalizi au jukwaa linalohusishwa na muuzaji yeyote. Ni zaidi ya dhana na seti ya kanuni, sawa na neno lingine tunalolifahamu: DevOps.
Katika kampuni tumeanzisha fasili mbili za neno hili jipya: kinadharia na vitendo. Wacha tuanze na nadharia:
GitOps ni mbinu ambayo inachukua kanuni bora zaidi za DevOps zinazotumiwa kwa uundaji wa programu, kama vile udhibiti wa toleo, ushirikiano, okestration, CI/CD, na kuzitumia kwa changamoto za usimamizi wa miundombinu kiotomatiki.
Michakato yote GitOps Ninafanya kazi kwa kutumia zana zilizopo. Msimbo wote wa miundombinu huhifadhiwa kwenye hazina inayojulikana ya git, mabadiliko hupitia mchakato wa uidhinishaji sawa na msimbo mwingine wowote wa programu, na mchakato wa uchapishaji ni wa kiotomatiki, ambao hupunguza makosa ya kibinadamu na huongeza kutegemewa na uzalishaji tena.
Kutoka kwa mtazamo wa vitendo, tunaelezea GitOps kama ifuatavyo:
Tayari tumejadili miundombinu kama kanuni kama mojawapo ya vipengele muhimu vya fomula hii. Wacha tuwatambulishe washiriki wengine.
Unganisha Ombi (jina mbadala la Kuvuta Ombi). Katika suala la mchakato, MR ni ombi la kutumia mabadiliko ya msimbo na kisha kuunganisha matawi. Lakini kwa upande wa zana tunazotumia, hii ni fursa zaidi ya kupata picha kamili ya mabadiliko yote yanayofanywa: sio tu nambari tofauti zilizokusanywa kutoka kwa idadi fulani ya ahadi, lakini pia muktadha, matokeo ya mtihani, na matokeo ya mwisho yanayotarajiwa. Ikiwa tunazungumza juu ya nambari ya miundombinu, basi tunavutiwa na jinsi miundombinu itabadilika, ni rasilimali ngapi mpya zitaongezwa au kuondolewa, kubadilishwa. Ikiwezekana katika umbizo rahisi zaidi na rahisi kusoma. Kwa watoa huduma za wingu, ni vyema kujua athari ya kifedha ya mabadiliko haya itakuwaje.
Lakini MR pia ni njia ya ushirikiano, mwingiliano, na mawasiliano. Mahali ambapo mfumo wa hundi na mizani hutumika. Kutoka kwa maoni rahisi hadi idhini rasmi na idhini.
Kweli, sehemu ya mwisho: CI/CD, kama tunavyojua tayari, hurahisisha mchakato wa kufanya mabadiliko ya miundombinu na upimaji otomatiki (kutoka kwa ukaguzi rahisi wa sintaksia hadi uchanganuzi mgumu zaidi wa nambari tuli). Na pia katika kugundua baadae ya drift: tofauti kati ya hali halisi na taka ya mfumo. Kwa mfano, kama matokeo ya mabadiliko ya mwongozo yasiyoidhinishwa au kushindwa kwa mfumo.
Ndiyo, neno GitOps haitutambui kwa kitu chochote kipya kabisa, haitoi tena gurudumu, lakini inatumika tu uzoefu uliokusanywa katika eneo jipya. Lakini hapa ndipo nguvu zake ziko.
Na ikiwa ghafla unapendezwa na jinsi hii yote inavyoonekana katika mazoezi, basi ninakualika uangalie yetu , ambayo ninakuambia hatua kwa hatua jinsi ya kutumia GitLab:
-
Tekeleza kanuni za msingi za GitOps
-
Unda na ufanye mabadiliko kwenye miundombinu ya wingu (kwa mfano wa Yandex Cloud)
-
Ugunduzi wa kiotomatiki wa kusogea kwa mfumo kutoka kwa hali inayotakiwa kwa kutumia ufuatiliaji amilifu
https://bit.ly/34tRpwZ
Chanzo: mapenzi.com