Programmēšanas pēdējā desmitgadē ir notikušas vairākas revolucionāras pārmaiņas. Viens ir radies no prakses kopas ap devops, kas saskaņo izstrādes un operāciju komandas par kopīgu darba procesu, un no nepārtrauktas integrācijas un nepārtrauktas piegādes (CI / CD), kurā devops komandas nodrošina koda bāzes nemitīgus pakāpeniskus atjauninājumus. Vēl viena transformācija ir saistīta ar saistīto pāreju no monolītām koda bāzēm uz mākoņa bāzes mikropakalpojumiem, kas darbojas konteineros, kurus pārvalda tādas orķestrēšanas platformas kā Kubernetes.
Uz konteineriem balstītas lietojumprogrammas, kas darbojas grupētās sistēmās vai mākonī, var būt sarežģītas, un tās ir grūti nodrošināt un pārvaldīt pat ar tādu platformu kā Kubernetes, kas organizē lietas. GitOps ir topošs prakses kopums, kura mērķis ir vienkāršot šo pārvaldības uzdevumu, izmantojot tehnikas no devops pasaules un CI / CD.
GitOps atslēga ir ideja par infrastruktūru kā kodu, kas izmanto tādu pašu pieeju infrastruktūras nodrošināšanai kā devops izmanto nodrošinājuma lietojumprogrammām. Tātad failos tiek aprakstīta ne tikai lietojumprogramma, bet arī pamatā esošās resursdatora mašīnas un tīkli, kurus versiju kontroles sistēmā var uzskatīt par jebkuru citu kodu, un automatizētie procesi pēc tam darbojas, lai reālās pasaules lietojumprogrammu sapludinātu ar šajos aprakstīto. failus.
GitOps valodā runājot, versiju kontroles sistēmā ir kods viens patiesības avots par to, kā lietojumprogrammai vajadzētu izskatīties ražošanā.
GitOps definēts
Weaveworks ir uzņēmums, kas visvairāk ir darījis GitOps koncepcijas popularizēšanu. Mēs nedaudz iedziļināsimies Weaveworks lomā, bet vispirms apskatīsim uzņēmuma definīciju GitOps, kas ir divējāda:
- Kubernetes un citu vietējo mākoņtehnoloģiju darbības modelis, nodrošinot paraugprakses kopumu, kas apvieno konteinerizētu kopu un lietojumprogrammu izvietošanu, pārvaldību un uzraudzību.
- Ceļš uz izstrādātāju pieredzi lietojumprogrammu pārvaldībā; kur gan operācijām, gan izstrādei tiek izmantoti tiešie CI / CD cauruļvadi un Git darbplūsmas.
Citiem vārdiem sakot, GitOps ir īpašs prakses kopums, kas paredzēts Kubernetes un līdzīgu platformu pārvaldībai, un tas ir piemērots arī plašākai lietošanai, jo arvien vairāk attīstības veikalu pieņem izstrādātāju prakses un migrē kodu uz mākoni. Bet, lai saprastu GitOps slepeno mērci un tās atrisinātās problēmas, mums jārunā par komponentiem, kas tajā iekļauti.
Git definīcija
The Git GitOps atsaucas uz ārkārtīgi populāro izplatīto versiju vadības sistēmu, kuru 2005. gadā izstrādāja Linuss Torvalds. Git ir rīks, kas ļauj izstrādātāju komandām kopīgi strādāt pie lietojumprogrammas koda bāzes, glabājot dažādas zari koda, kuru viņi izveic, pirms tos apvieno ražošanas kodā. Git galvenais jēdziens ir pull pieprasījums, kurā izstrādātājs oficiāli pieprasa, lai kāds kods, pie kura viņi ir strādājuši, tiktu integrēts citā filiāles koda bāzē.
Git pull pieprasījums dod iespēju komandas locekļiem sadarboties un apspriest, pirms tiek panākta vienprātība par to, vai jaunais kods būtu jāpievieno lietojumprogrammai. Git glabā arī vecākas koda versijas, kas ļauj viegli atgriezties pie pēdējās labās versijas, ja kaut kas noiet greizi, un ļauj ātri redzēt, kas mainījies starp pārskatījumiem. Git var būt vislabāk pazīstams kā GitHub, mākoņos mitinātas versiju vadības sistēmas pamatā, taču pati Git ir atvērtā pirmkoda programmatūra, kuru var izvietot jebkur, sākot no iekšējiem korporatīvajiem serveriem un beidzot ar datoru.
Ņemiet vērā, ka, lai gan mēs parasti domājam par Git kā datorprogrammēšanas rīku, patiesībā tas ir agnostiķis attiecībā uz to, kādam saturam jūs to izmantojat. Git ar prieku izturēsies pret jebkuru teksta failu kopu kā “koda bāzi”, un, piemēram, to var izmantot rakstnieki, kuri vēlas sekot līdzi kopdarba labojumiem. Tas ir svarīgi, jo lielu daļu GitOps koda bāzes veido deklaratīvi konfigurācijas faili, nevis izpildāms kods.
Vēl viena lieta, kas jāsaka, pirms mēs ejam tālāk: Neskatoties uz to, ka vārds “Git” ir tieši tur, GitOps faktiski neprasa Git izmantošanu. Veikali, kas jau ir ieguldīti citā versiju vadības programmatūrā, piemēram, Subversion, var ieviest arī GitOps. Bet Git tiek plaši izmantots devops pasaulē, lai ieviestu CI / CD, tāpēc lielākā daļa GitOps projektu galu galā tiks izmantoti Git.
Kas ir CI / CD process?
Pilnīgs CI / CD apskats ir ārpus šī raksta darbības jomas - skatiet skaidrojumu par šo tēmu -, bet mums jāsaka daži vārdi par CI / CD, jo tas ir GitOps darbības pamatā. The nepārtraukta integrācija Pusi CI / CD iespējo versiju kontroles krātuves, piemēram, Git: Izstrādātāji var veikt pastāvīgus nelielus uzlabojumus savā koda bāzē, nevis ik pēc pāris mēnešiem vai gadiem izlaist milzīgas, monolītas jaunas versijas. The nepārtraukta izvietošana gabals ir iespējams ar automatizētu sistēmu sauc cauruļvadi kas izveido, testē un izvieto jauno kodu ražošanā.
Atkal mēs turpinām runāt kods šeit, un tas parasti apkopo redzamības par izpildāmo kodu, kas rakstīts programmēšanas valodā, piemēram, C vai Java, vai JavaScript. Bet pakalpojumā GitOps mūsu pārvaldīto “kodu” lielākoties veido konfigurācijas faili. Šī nav tikai neliela detaļa - tā ir GitOps darbības pamatā. Šie konfigurācijas faili, kā jau teicām, ir “vienotais patiesības avots”, kas raksturo to, kādai jābūt mūsu sistēmai. Viņi ir deklaratīvs nevis pamācoša. Tas nozīmē, ka tā vietā, lai teiktu “startēt desmit serverus”, konfigurācijas failā vienkārši tiks teikts: “šī sistēma ietver desmit serverus”.
The CI puse no GitOps vienādojuma ļauj izstrādātājiem ātri ieviest šo konfigurācijas failu uzlabojumus un uzlabojumus; CD puse notiek tad, kad automatizētie programmatūras aģenti dara visu iespējamo, lai nodrošinātu, ka lietojumprogrammas tiešraides versija atspoguļo konfigurācijas failu aprakstus - saplūst uz deklaratīvo modeli GitOps valodā.
GitOps un Kubernetes
Kā jau minējām, GitOps koncepcijas sākotnēji tika izstrādātas ap Kubernetes lietojumprogrammu pārvaldību. Ņemot vērā to, ko mēs tagad zinām par GitOps, vēlreiz apskatīsim Weaveworks GitOps diskusiju un redzēsim, kā viņi apraksta, kā jūs atjauninātu Kubernetes, kas tiek pārvaldīts pēc GitOps principiem. Šeit ir apkopojums:
- Izstrādātājs pieprasa Git jaunu funkciju.
- Kods tiek pārskatīts un apstiprināts, pēc tam apvienots galvenajā koda bāzē.
- Apvienošana izraisa CI / CD cauruļvadu, kas automātiski testē un atjauno jauno kodu un izvieto to reģistrā.
- Programmatūras aģents pamana atjauninājumu, izvelk jauno kodu no reģistra un atjaunina konfigurācijas failu (rakstīts YAML) konfigurācijas krātuvē.
- Programmatūras aģents Kubernetes klasterī nosaka, ka klasteris ir novecojis, pamatojoties uz konfigurācijas failu, izvelk izmaiņas un izvieto jauno funkciju.
Austi un GitOps
Skaidrs, ka šeit 4. un 5. solis veic lielu slodzi. Programmatūras aģenti, kas maģiski sinhronizē Git repozitorija “patiesības avotu” ar reālās pasaules lietojumprogrammu Kubernetes, ir maģija, kas padara GitOps iespējamu. Kā mēs jau teicām, GitOps izteiksmē tiek dēvēts process, kas padara aktīvās sistēmas līdzīgākas konfigurācijas failos aprakstītajām ideālajām sistēmām konverģence. (Kad tiešraides sistēma un ideālā sistēma nav sinhronizētas, tas tā ir atšķirības.) Ideālā gadījumā konverģenci panāktu, izmantojot automatizētus procesus, taču automatizācijai ir ierobežojumi, un dažreiz ir nepieciešama cilvēku iejaukšanās.
Mēs šeit esam aprakstījuši procesu vispārīgi, bet patiesībā, ja jūs patiešām apmeklējat Weaveworks lapu, mūsu pieminētie “programmatūras aģenti” ir daļa no uzņēmuma Weave Cloud platformas. Terminu “GitOps” izdomāja Weaveworks izpilddirektors Aleksis Ričardsons, un tas daļēji kalpo tam, lai Weaveworks platforma būtu pievilcīga izstrādātājiem, kas jau ir iemērkti devops un CI / CD pasaulē.
Bet Weaveworks nekad nav pieprasījis GitOps monopolu, kas ir vairāk filozofija un labākās prakses kopums nekā noteikts produkts. Kā atzīmē CloudBees, uzņēmuma, kas nodrošina CI / CD risinājumus, emuārs, GitOps ir atvērts, no piegādātāja neitrāls modelis, kas tika izstrādāts, reaģējot uz pārvaldītiem patentētiem Kubernetes risinājumiem, kurus ieviesa lieli mākoņu pārdevēji, piemēram, Amazon, Google un Microsoft . CloudBees piedāvā savus GitOps risinājumus, tāpat kā vairāki spēlētāji šajā telpā.
GitOps un devops
Uzņēmumam Atlassian, kas ražo vairākus rīkus veikliem izstrādātājiem, ir padziļināts emuāra ziņojums par GitOps vēsturi un mērķi, kas ir jūsu laika vērts. Pēc viņu domām, GitOps ir loģisks to ideju paplašinājums, kuras apvienojās kā devops. Konkrētāk, GitOps ir infrastruktūras kā koda jēdziena izstrāde, kas pati ir ideja, kas radās devops vidē. GitOps, kā to uzskata Atlassian, pārvarēja izšķirošo plaisu starp esošajām devops metodēm, kas bija attīstījušās, lai atrisinātu sistēmas administrēšanas problēmas, un izplatīto, mākoņa mitināšanas lietojumprogrammu īpašajām vajadzībām. Automātiskā konverģence, ko piedāvā dažādi mākoņu pārdevēji, padara GitOps īpašu.
Lai gan GitOps šodien joprojām koncentrējas uz Kubernetes, mēs ceram, ka mēs esam skaidri norādījuši, kā tas attiecas uz daudz plašāku izplatīto, uz mākoņiem balstīto lietotņu pasauli. Atklātā pirmkoda drošības pārdevēja WhiteSource emuāra ziņā ir izklāstītas GitOps priekšrocības:
- Novērojamība: GitOps sistēmas piedāvā pārraudzību, reģistrēšanu, izsekošanu un vizualizāciju sarežģītās lietojumprogrammās, lai izstrādātāji varētu redzēt, kas un kur notiek.
- Versiju kontrole un izmaiņu vadība: Acīmredzot tas ir galvenais ieguvums, lietojot tādu versiju kontroles sistēmu kā Git. Nepareizus atjauninājumus var viegli atgūt.
- Viegla pieņemšana: GitOps balstās uz devops prasmēm, kuras daudziem izstrādātājiem jau ir.
- Produktivitāte: GitOps nodrošina produktivitātes paaugstināšanu, ko devops un CI / CD ir devuši citās jomās.
- Revīzija: Pateicoties Git, katru darbību var izsekot līdz konkrētai saistībai, tādējādi viegli izsekot kļūdu cēloņiem.
Pat ja jūs neizmantojat Kubernetes, ir liela varbūtība, ka GitOps agrāk vai vēlāk būs daļa no jūsu darbplūsmas.
