Paskutinį programavimo dešimtmetį įvyko daugybė revoliucinių pokyčių. Vienas iš jų kilo iš praktinių grupių, susijusių su „devops“, kuri suderina kūrimo ir operacijų komandas į bendrą darbo procesą, ir nuolatinę integraciją ir nuolatinį pristatymą (CI / CD), kai „devops“ komandos nuolat atnaujina kodo bazę. Dar viena transformacija atsirado dėl perėjimo iš monolitinių kodų bazių į debesų pagrindu veikiančias mikropaslaugas, veikiančias konteineriuose, valdomuose orkestravimo platformose, tokiose kaip „Kubernetes“.
Konteinerių programos, veikiančios grupuotose sistemose arba debesyje, gali būti sudėtingos, jas sunku aprūpinti ir valdyti, net naudojant tokią platformą, kaip „Kubernetes“, organizuojant dalykus. „GitOps“ yra atsirandantis praktikų rinkinys, kurio tikslas yra supaprastinti šią valdymo užduotį taikant technikas iš „devops“ ir CI / CD pasaulių.
„GitOps“ raktas yra infrastruktūros, kaip kodo, idėja, teikiant infrastruktūros aprūpinimą tuo pačiu požiūriu, kurį „devops“ naudoja teikimo programoms. Taigi ne tik programa, bet ir pagrindinės pagrindinės mašinos ir tinklai aprašomi failuose, kuriuos galima laikyti bet kokiais kitais kodais versijų valdymo sistemoje, o automatizuoti procesai padeda realioms programoms sujungti su tomis, kurios aprašytos tose programose. failus.
Kalbant „GitOps“, versijų valdymo sistemos kodas yra vienintelis tiesos šaltinis apie tai, kaip programa turėtų atrodyti gamyboje.
Apibrėžta „GitOps“
„Weaveworks“ yra įmonė, kuri labiausiai nuveikė populiarindama „GitOps“ koncepciją. Mes šiek tiek įsigilinsime į „Weaveworks“ vaidmens detales, bet pirmiausia pažvelkime į bendrovės „GitOps“ apibrėžimą, kuris yra dvejopas:
- „Kubernetes“ ir kitų natūralių debesų technologijų veikimo modelis, pateikiantis geriausios praktikos rinkinį, kuris vienija konteinerių grupių ir programų diegimą, valdymą ir stebėjimą.
- Kelias į kūrėjų patirtį valdant programas; kur tiek operacijoms, tiek plėtrai taikomi tiesioginiai CI / CD vamzdynai ir „Git“ darbo eigos.
Kitaip tariant, „GitOps“ yra specifinis praktikų rinkinys, skirtas valdyti „Kubernetes“ ir panašias platformas. Tai taip pat tinka plačiau taikyti, nes vis daugiau programinės įrangos parduotuvių priima „Devops“ praktiką ir perkelia kodą į debesį. Tačiau norėdami suprasti slaptą „GitOps“ padažą ir jo sprendžiamas problemas, turime kalbėti apie jame esančius komponentus.
Gito apibrėžimas
Git „GitOps“ nurodo nepaprastai populiarią paskirstytos versijos valdymo sistemą, kurią 2005 m. sukūrė Linus Torvalds. „Git“ yra įrankis, leidžiantis kūrėjų komandoms kartu dirbti programos kode, saugant įvairius šakos kodo, kurį jie naudoja, prieš sujungdami juos į gamybos kodą. Pagrindinė „Git“ sąvoka yra traukimo užklausa, kuriame kūrėjas oficialiai prašo, kad tam tikras kodas, kurį jie dirbo, būtų integruotas į kitą kodo bazės šaką.
„Git pull“ užklausa suteikia galimybę komandos nariams bendradarbiauti ir aptarti prieš pasiekiant sutarimą, ar naujas kodas turėtų būti pridėtas prie programos. „Git“ taip pat saugo senesnes kodo versijas, kurios leidžia lengvai grįžti prie paskutinės geros versijos, jei kažkas negerai, ir leidžia greitai pamatyti, kas pasikeitė tarp taisymų. „Git“ gali būti geriausiai žinomas kaip „GitHub“, debesų priglobtos versijų valdymo sistemos, pagrindas, tačiau pati „Git“ yra atvirojo kodo programinė įranga, kurią galima įdiegti bet kur, pradedant vidiniais įmonės serveriais ir baigiant jūsų kompiuteriu.
Atkreipkite dėmesį, kad nors mes dažniausiai galvojame apie „Git“ kaip apie kompiuterio programavimo įrankį, iš tikrųjų tai agnostika, kokiam turiniui jūs jį naudojate. „Git“ mielai traktuos bet kokius tekstinių failų rinkinius kaip „kodų bazę“, ir, pavyzdžiui, juos gali naudoti rašytojai, norintys sekti bendro darbo pakeitimus. Tai svarbu, nes didžiąją dalį „GitOps“ pagrindinės kodo bazės sudaro deklaratyvūs konfigūracijos failai, o ne vykdomasis kodas.
Paskutinis dalykas, kurį reikia pasakyti prieš judant toliau: Nepaisant to, kad „Git“ yra tiesiai pavadinime, „GitOps“ iš tikrųjų nereikalauja naudoti „Git“. Parduotuvės, kurios jau yra investuotos į kitą versijų valdymo programinę įrangą, pavyzdžiui, „Subversion“, taip pat gali įdiegti „GitOps“. Bet „Git“ yra plačiai naudojamas „devops“ pasaulyje diegiant CI / CD, todėl dauguma „GitOps“ projektų galų gale bus naudojami „Git“.
Kas yra CI / CD procesas?
Išsamus žvilgsnis į CI / CD nepatenka į šio straipsnio taikymo sritį - žr. Aiškintoją šia tema, tačiau turime pasakyti keletą žodžių apie CI / CD, nes tai yra „GitOps“ veikimo esmė. nuolatinė integracija pusę CI / CD įgalina versijų valdymo saugyklos, pvz., „Git“: Kūrėjai gali nuolat mažus kodo patobulinimus, o ne kas kelis mėnesius ar metus išleisti didžiules, monolitines naujas versijas. nuolatinis dislokavimas kūrinį įgalina vadinamos automatizuotos sistemos vamzdynai kad sukurtų, išbandytų ir įdiegtų naują kodą gamyboje.
Vėlgi, mes nuolat kalbame apie kodas čia, ir tai paprastai apibendrina vykdomojo kodo, parašyto programavimo kalba, pvz., C arba Java, arba „JavaScript“, vizijas. Tačiau „GitOps“ mūsų valdomą „kodą“ daugiausia sudaro konfigūracijos failai. Tai nėra tik nedidelė detalė - tai yra „GitOps“ veiklos esmė. Šie konfigūracijos failai, kaip jau minėjome, yra „vienas tiesos šaltinis“, apibūdinantis, kaip turėtų atrodyti mūsų sistema. Jie yra deklaratyvus o ne pamokanti. Tai reiškia, kad užuot sakius „paleisti dešimt serverių“, konfigūracijos failas tiesiog pasakys: „ši sistema apima dešimt serverių“.
PI pusė „GitOps“ lygties leidžia kūrėjams greitai įdiegti šių konfigūracijos failų patobulinimus ir patobulinimus; Kompaktinis diskas pusė įvyksta, kai automatinės programinės įrangos agentai daro viską, kad užtikrintų, jog tiesioginė programos versija atspindėtų konfigūracijos failų aprašymus - suartėja deklaratyviam modeliui „GitOps“ kalba.
„GitOps“ ir „Kubernetes“
Kaip jau minėjome, „GitOps“ koncepcijos iš pradžių buvo kuriamos valdant „Kubernetes“ programas. Atsižvelgdami į tai, ką dabar žinome apie „GitOps“, dar kartą apžvelkime „Weaveworks“ diskusiją „GitOps“ ir pažiūrėkime, kaip jie apibūdina, kaip atnaujintumėte „Kubernetes“, valdomą pagal „GitOps“ principus. Štai santrauka:
- Kūrėjas pateikia „Git“ užklausą dėl naujos funkcijos.
- Kodas yra peržiūrimas ir patvirtinamas, tada sujungiamas su pagrindine kodų baze.
- Sujungus suaktyvinamas CI / CD dujotiekis, kuris automatiškai išbando ir atstato naują kodą ir pateikia jį registre.
- Programinės įrangos agentas pastebi atnaujinimą, ištraukia naują kodą iš registro ir atnaujina konfigūracijos failą (parašytą YAML) konfigūracijos saugykloje.
- Programinės įrangos agentas, esantis „Kubernetes“ klasteryje, nustato, kad klasteris yra pasenęs, remdamasis konfigūracijos failu, ištraukia pakeitimus ir įdiegia naują funkciją.
Audiniai ir „GitOps“
Aišku, kad čia 4 ir 5 žingsniai atlieka sunkųjį kėlimą. Programinės įrangos agentai, kurie stebuklingai sinchronizuoja „tiesos šaltinį“ „Git“ saugykloje su realaus pasaulio „Kubernetes“ programa, yra ta magija, kuri leidžia „GitOps“. Kaip jau minėjome, GitOps terminais vadinamas procesas, kai tiesioginės sistemos tampa panašesnės į idealias sistemas, aprašytas konfigūracijos failuose. konvergencija. (Kai tiesioginė sistema ir ideali sistema nėra sinchronizuojamos, tai yra išsiskyrimas.) Idealiu atveju konvergencija būtų pasiekta automatizuotais procesais, tačiau yra tam tikrų apribojimų, kuriuos gali atlikti automatika, ir kartais reikia žmogaus įsikišimo.
Apibūdinome procesą čia bendrais bruožais, bet iš tikrųjų, jei jūs iš tikrųjų einate pažvelgti į „Weaveworks“ puslapį, mūsų paminėti „programinės įrangos agentai“ yra bendrovės „Weave Cloud“ platformos dalis. Sąvoką „GitOps“ sugalvojo „Weaveworks“ generalinis direktorius Alexis Richardsonas, ir tai iš dalies padeda tam, kad „Weaveworks“ platforma būtų patraukli kūrėjams, jau įsitaisiusiems devops ir CI / CD pasauliuose.
Tačiau „Weaveworks“ niekada neteigė „GitOps“ monopolijos, o tai yra daugiau filosofija ir geriausios praktikos rinkinys nei konkretus produktas. Kaip pažymi CI / CD sprendimus teikiančios bendrovės „CloudBees“ tinklaraštis, „GitOps“ yra atviras, pardavėjų atžvilgiu neutralus modelis, kuris buvo sukurtas reaguojant į valdomus patentuotus „Kubernetes“ sprendimus, kuriuos įdiegė dideli debesų pardavėjai, tokie kaip „Amazon“, „Google“ ir „Microsoft“. . „CloudBees“ siūlo savo „GitOps“ sprendimus, kaip ir daugelis žaidėjų šioje erdvėje.
„GitOps“ ir „devops“
„Atlassian“, įmonė, gaminanti daugybę įrankių judriems kūrėjams, turi išsamų tinklaraščio įrašą apie „GitOps“ istoriją ir paskirtį, kuris yra vertas jūsų laiko. Jų manymu, „GitOps“ yra logiškas idėjų, susibūrusių kaip „devops“, pratęsimas. Konkrečiau, „GitOps“ yra infrastruktūros, kaip kodo, sąvokos išplėtojimas, pati idėja, kilusi iš devops aplinkos. Kaip „Atlassian“ mato, „GitOps“ panaikino esminį atotrūkį tarp esamų „devops“ metodų, kurie buvo sukurti siekiant išspręsti sistemos administravimo problemas, ir specifinių paskirstytų debesų prieglobos programų poreikių. Automatinė konvergencija, kurią siūlo įvairūs debesų tiekėjai, tuo „GitOps“ yra ypatingas.
Nors „GitOps“ šiandien ir toliau orientuojasi į „Kubernetes“, tikimės, kad mes aiškiai nurodėme, kaip tai taikoma daug platesniam platinamų, debesų pagrindu sukurtų programų pasauliui. Atvirojo kodo saugos tiekėjo „WhiteSource“ tinklaraščio įraše aprašomi „GitOps“ pranašumai:
- Stebimumas: „GitOps“ sistemos siūlo stebėjimą, registravimą, stebėjimą ir vizualizavimą sudėtingose programose, kad kūrėjai galėtų pamatyti, kas ir kur lūžta.
- Versijų valdymas ir pakeitimų valdymas: Akivaizdu, kad tai yra pagrindinis versijų valdymo sistemos, tokios kaip „Git“, privalumas. Sugedusius atnaujinimus galima lengvai sugrąžinti.
- Lengvas priėmimas: „GitOps“ remiasi „devops“ įgūdžiais, kuriuos jau turi daugelis kūrėjų.
- Produktyvumas: „GitOps“ suteikia produktyvumo padidėjimą, kurį devops ir CI / CD atnešė kitoms sritims.
- Auditas: „Git“ dėka kiekvienas veiksmas gali būti susietas su konkrečiu įsipareigojimu, todėl lengva nustatyti klaidų priežastis.
Net jei nenaudojate „Kubernetes“, didelė tikimybė, kad „GitOps“ anksčiau ar vėliau bus jūsų darbo eigos dalis.
