Suurin osa meistä, kun huomaa IT-blogosfäärissä tai -konferenssissa toisen uuden termin, kysyy ennemmin tai myöhemmin samanlaisen kysymyksen: "Mitä tämä on? Vain yksi muotisana, "muotisana" tai jotain todella tarkkaavaisen huomion, tutkimuksen ja uusien horisonttien lupauksen arvoista? Minulle kävi samoin termin kanssa GitOps jonkin aikaa sitten. Varustettu monilla olemassa olevilla artikkeleilla sekä yrityksen kollegoiden tietämyksellä , yritin selvittää, millainen peto tämä on ja miltä sen käyttö voisi näyttää käytännössä.
Muuten, termin uutuudesta GitOps Tuoreen kyselymme mukaan myös yli puolet kyselyyn vastanneista ei ole vielä alkanut työskennellä sen periaatteiden kanssa.
Infrastruktuurin hallinnan ongelma ei siis ole uusi. Monet pilvipalveluntarjoajat ovat olleet suuren yleisön saatavilla jo parikymmentä vuotta, ja niiden olisi ilmeisesti pitänyt tehdä infrastruktuurista vastaavien tiimien työstä yksinkertaista ja suoraviivaista. Kuitenkin verrattuna sovelluskehitysprosessiin (jossa automaatio saavuttaa yhä uusia tasoja), infrastruktuuriprojektit sisältävät edelleen usein monia manuaalisia tehtäviä ja vaativat erikoisosaamista ja asiantuntemusta, etenkin kun otetaan huomioon tämän päivän vikasietoisuus, joustavuus, skaalautuvuus ja joustavuus.
Pilvipalvelut täyttivät nämä vaatimukset erittäin hyvin ja juuri ne antoivat merkittävän sysäyksen lähestymistavan kehittämiselle IaC. Tämä on ymmärrettävää. Loppujen lopuksi ne mahdollistivat täysin virtuaalisen datakeskuksen konfiguroinnin: fyysisiä palvelimia, telineitä tai verkkokomponentteja ei ole, koko infrastruktuuri voidaan kuvata komentosarjojen ja asetustiedostojen avulla.
Mitä eroa siis tarkalleen ottaen on? GitOps alkaen IaC? Tästä kysymyksestä aloitin tutkimukseni. Keskusteltuani kollegoiden kanssa sain seuraavan vertailun:
GitOps
IaC
Kaikki koodi on tallennettu git-arkistoon
Koodin versiointi on valinnainen
Ilmoittava koodi Kuvaus / Idempotenssi
Sekä deklaratiiviset että pakottavat kuvaukset ovat hyväksyttäviä
Muutokset tulevat voimaan yhdistämispyyntö-/vetopyyntömekanismien avulla
Sopimus, hyväksyntä ja yhteistyö ovat valinnaisia
Päivitysten käyttöönottoprosessi on automatisoitu
Päivitysprosessia ei ole standardoitu (automaattinen, manuaalinen, tiedostojen kopiointi, komentorivin käyttö jne.)
Toisin sanoen GitOps syntyi juuri periaatteita soveltamalla IaC. Ensinnäkin infrastruktuuri ja kokoonpanot voidaan nyt tallentaa samalla tavalla kuin sovellukset. Koodi on helppo tallentaa, jakaa, vertailla ja käyttää versiointiominaisuuksia. Versiot, haarat, historia. Ja kaikki tämä paikassa, joka on julkisesti koko tiimin käytettävissä. Siksi versionhallintajärjestelmien käytöstä tuli täysin luonnollista kehitystä. Erityisesti git suosituimpana.
Toisaalta infrastruktuurin hallintaprosessien automatisointi tuli mahdolliseksi. Nyt tämä voidaan tehdä nopeammin, luotettavammin ja halvemmalla. Lisäksi CI / CD:n periaatteet olivat jo tuttuja ja suosittuja ohjelmistokehittäjien keskuudessa. Tarvittiin vain siirtää ja soveltaa jo tuttua tietoa ja taitoja uudelle alueelle. Nämä käytännöt menivät kuitenkin pidemmälle kuin vakiomääritelmä Infrastruktuurista koodina, tästä syystä käsite GitOps.
Uteliaisuus GitOps, tietysti myös siinä, että se ei ole tuote, laajennus tai alusta, joka liittyy mihinkään toimittajaan. Se on enemmän paradigma ja periaatteiden joukko, samanlainen kuin toinen meille tuttu termi: DevOps.
Yhtiö olemme kehittäneet kaksi määritelmää tälle uudelle termille: teoreettinen ja käytännöllinen. Aloitetaan teoreettisesta:
GitOps on menetelmä, joka ottaa käyttöön parhaat sovelluskehityksessä käytetyt DevOps-periaatteet, kuten versionhallinta, yhteistyö, orkestrointi, CI/CD, ja soveltaa niitä infrastruktuurin hallinnan automatisoinnin haasteisiin.
Kaikki prosessit GitOps Työskentelen olemassa olevilla työkaluilla. Kaikki infrastruktuurikoodi on tallennettu jo tuttuihin git-arkistoon, muutokset käyvät läpi saman hyväksymisprosessin kuin mikä tahansa muu ohjelmakoodi, ja käyttöönottoprosessi on automatisoitu, mikä mahdollistaa inhimillisten virheiden minimoimisen, luotettavuuden ja toistettavuuden lisäämisen.
Käytännön näkökulmasta kuvaamme GitOps seuraavasti:
Olemme jo keskustelleet infrastruktuurista koodina yhtenä tämän kaavan avainkomponenteista. Esittelemme loput osallistujat.
Yhdistämispyyntö (vaihtoehtoinen nimi Pull Request). Prosessin termeissä MR on pyyntö tehdä koodimuutoksia ja sitten yhdistää haarat. Mutta mitä tulee käyttämiimme työkaluihin, tämä on pikemminkin mahdollisuus saada täydellinen kuva kaikista tehdyistä muutoksista: ei vain koodin ero, joka on kerätty tietystä määrästä sitoumuksia, vaan myös kontekstista, testituloksista ja lopullinen odotettu tulos. Jos puhumme infrastruktuurikoodista, niin olemme kiinnostuneita siitä, kuinka infrastruktuuri tarkalleen muuttuu, kuinka monta uutta resurssia lisätään tai poistetaan, muutetaan. Mieluiten jossain kätevämmässä ja helposti luettavassa muodossa. Pilvipalvelujen tarjoajien on hyvä tietää, mitä taloudellisia vaikutuksia tällä muutoksella on.
Mutta MR on myös yhteistyön, vuorovaikutuksen ja viestinnän väline. Paikka, jossa valvonta- ja tasapainojärjestelmä tulee peliin. Yksinkertaisista kommenteista muodollisiin hyväksyntöihin ja hyväksyntöihin.
No, viimeinen komponentti: CI/CD, kuten jo tiedämme, mahdollistaa infrastruktuurimuutosten ja testauksen automatisoinnin (yksinkertaisesta syntaksin tarkistuksesta monimutkaisempaan staattisen koodin analyysiin). Ja myös myöhemmässä ajautumisen havaitsemisessa: erot järjestelmän todellisen ja halutun tilan välillä. Esimerkiksi luvattomien manuaalisten muutosten tai järjestelmävian seurauksena.
Kyllä, termi GitOps ei esittele meille mitään täysin uutta, ei keksi pyörää uudelleen, vaan yksinkertaisesti soveltaa jo kertynyttä kokemusta uudella alueella. Mutta tässä on hänen voimansa.
Ja jos yhtäkkiä kiinnostut siitä, miltä tämä kaikki näyttää käytännössä, kutsun sinut katsomaan meidän , jossa kerron sinulle vaihe vaiheelta, kuinka GitLabia käytetään:
-
Toteuta GitOpsin perusperiaatteet
-
Luo ja tee muutoksia pilviinfrastruktuuriin (Yandex Cloudin esimerkin avulla)
-
Automatisoi järjestelmän poikkeaman havaitseminen halutusta tilasta aktiivisen valvonnan avulla
https://bit.ly/34tRpwZ
Lähde: will.com