Ohjelmoinnin viime vuosikymmenen aikana on tapahtunut useita vallankumouksellisia muutoksia. Yksi on syntynyt devopsia ympäröivistä käytäntöjoukosta, joka sovittaa kehitys- ja operatiiviset ryhmät yhteiseksi työprosessiksi, ja jatkuvaan integrointiin ja jatkuvaan toimitukseen (CI / CD), jossa devops-tiimit toimittavat jatkuvasti päivitettäviä kooditietokantaan. Toinen muutos on tullut vastaavasta siirtymisestä monoliittisista koodikannoista pilvipohjaisiin mikropalveluihin, jotka kulkevat säiliöissä, joita hallitsevat orkesterointialustat, kuten Kubernetes.
Ryhmäkohtaisissa järjestelmissä tai pilvessä toimivat konttipohjaiset sovellukset voivat olla monimutkaisia, ja niiden hankkiminen ja hallitseminen on vaikeaa, vaikka Kubernetesin kaltaisella alustalla järjestetään asioita. GitOps on nouseva käytäntöjoukko, jonka tarkoituksena on yksinkertaistaa tätä hallintatehtävää soveltamalla tekniikoita devopsin ja CI / CD: n maailmasta.
GitOpsin avain on ajatus infrastruktuurista koodina, joka käyttää samaa lähestymistapaa infrastruktuurin valmisteluun kuin devops käyttää provisiointisovelluksiin. Joten sovelluksen lisäksi myös taustalla olevat isäntäkoneet ja verkot kuvataan tiedostoissa, joita voidaan käsitellä muina koodeina versionhallintajärjestelmässä. Automaattiset prosessit pyrkivät sitten lähentämään tosielämän sovellusta näissä kuvattuun. tiedostot.
GitOps-kielellä versionhallintajärjestelmän koodi on yksi totuuden lähde mistä sovelluksen pitäisi näyttää tuotannossa.
GitOps määritelty
Weaveworks on yritys, joka on tehnyt eniten GitOps-konseptin popularisoimiseksi. Käsittelemme Weaveworksin roolin yksityiskohtia hieman, mutta ensin katsotaan yrityksen määrittely GitOpsille, joka on kaksinkertainen:
- Toimintamalli Kubernetesille ja muille pilvipalveluteknologioille, joka tarjoaa joukon parhaita käytäntöjä, jotka yhtenäistävät kontistoitujen klustereiden ja sovellusten käyttöönoton, hallinnan ja valvonnan.
- Polku kohti kehittäjäkokemusta sovellusten hallinnassa; missä päästä päähän CI / CD-putkistoja ja Git-työnkulkuja käytetään sekä toimintaan että kehitykseen.
Toisin sanoen, GitOps on erityinen käytäntöjoukko, joka on suunniteltu Kubernetesin ja vastaavien alustojen hallintaan, mikä soveltuu myös laajempaan sovellukseen, kun yhä useampi kehitysliike ottaa käyttöön devops-käytäntöjä ja siirtää koodin pilveen. Mutta ymmärtääksemme GitOpsin salaisen kastikkeen ja sen ratkaisemat ongelmat, meidän on puhuttava siihen menevistä komponenteista.
Gitin määritelmä
Git GitOps viittaa erittäin suosittuun hajautettuun versionhallintajärjestelmään, jonka Linus Torvalds on kehittänyt vuonna 2005. Git on työkalu, jonka avulla kehittäjäryhmät voivat työskennellä yhdessä sovelluskoodipohjan kanssa tallentaen erilaisia oksat koodia, jota he käyttävät ennen niiden yhdistämistä tuotantokoodiksi. Keskeinen konsepti Gitissä on vetopyyntö, jossa kehittäjä pyytää virallisesti työskentelemäänsä koodia integroitumaan toiseen haaraan koodipohjassa.
Git-vetopyyntö tarjoaa tiimin jäsenille mahdollisuuden tehdä yhteistyötä ja keskustella ennen kuin päästään yksimielisyyteen siitä, pitäisikö uusi koodi lisätä sovellukseen. Git tallentaa myös vanhemmat versiot koodista, mikä helpottaa paluuta viimeiseen hyvään versioon, jos jokin menee pieleen, ja antaa sinun nopeasti nähdä, mitä muutokset ovat muuttuneet versioiden välillä. Git tunnetaan parhaiten GitHubin, pilvipalvelun tarjoaman versionhallintajärjestelmän perustana, mutta itse Git on avoimen lähdekoodin ohjelmisto, joka voidaan ottaa käyttöön missä tahansa sisäisistä yrityspalvelimista tietokoneeseesi.
Huomaa, että vaikka ajattelemme Gitiä yleensä tietokoneohjelmointityökaluna, se on itse asiassa agnostinen siitä, mihin sisältöön käytät sitä. Git käsittelee mielellään kaikkia tekstitiedostoja "kooditietokantana", ja sitä voivat käyttää esimerkiksi kirjailijat, jotka haluavat seurata yhteistyötyön muokkauksia. Tämä on tärkeää, koska suuri osa GitOpsin ytimen koodikannasta koostuu deklaratiivisista kokoonpanotiedostoista suoritettavan koodin sijaan.
Viimeinen asia sanottava ennen kuin siirrymme eteenpäin: Huolimatta siitä, että “Git” on nimen alla, GitOps ei todellakaan vaadi Gitin käyttöä. Kaupat, jotka on jo investoitu muihin versionhallintaohjelmistoihin, kuten Subversion, voivat myös toteuttaa GitOpsin. Mutta Gitiä käytetään laajasti devops-maailmassa CI / CD: n toteuttamiseen, joten useimmat GitOps-projektit käyttävät Gitiä.
Mikä on CI / CD-prosessi?
CI / CD: n täydellinen tarkastelu on tämän artikkelin ulkopuolella - katso aiheen selittäjä - mutta meidän on sanottava muutama sana CI / CD: stä, koska se on GitOpsin toiminnan ydin. jatkuva integraatio puolet CI: stä / CD: stä on käytössä versionhallinnan arkistoissa, kuten Git: Kehittäjät voivat tehdä jatkuvasti pieniä parannuksia kooditietokantaansa sen sijaan, että julkaisisivat valtavia, monoliittisia uusia versioita muutaman kuukauden tai vuoden välein. jatkuva käyttöönotto pala mahdollistaa automatisoidut järjestelmät, joita kutsutaan putkistot joka rakentaa, testaa ja ottaa käyttöön uuden koodin tuotantoon.
Jälleen kerran puhumme siitä koodi tässä, ja se yleensä kutsuu yhteen visioita suoritettavasta koodista, joka on kirjoitettu ohjelmointikielellä, kuten C tai Java tai JavaScript. Mutta GitOpsissa hallinnoimamme "koodi" koostuu pääosin kokoonpanotiedostoista. Tämä ei ole vain pieni yksityiskohta - se on GitOpsin toiminnan ydin. Nämä konfiguraatiotiedostot ovat, kuten olemme sanoneet, "yksi totuuden lähde", joka kuvaa järjestelmämme ulkoasua. He ovat vakuuttava pikemminkin kuin opettavainen. Tämä tarkoittaa, että sen sijaan, että sanot "käynnistä kymmenen palvelinta", määritystiedosto yksinkertaisesti sanoo: "tämä järjestelmä sisältää kymmenen palvelinta".
CI puolet GitOps-yhtälöstä antaa kehittäjille mahdollisuuden ottaa nämä säätötiedostot nopeasti käyttöön ja tehdä parannuksia; CD puolet tapahtuu, kun automaattiset ohjelmistoagentit tekevät parhaansa varmistaakseen, että sovelluksen reaaliaikainen versio heijastaa määritystiedostojen kuvauksia - että se lähentyy deklaratiiviseen malliin GitOps-kielellä.
GitOps ja Kubernetes
Kuten olemme maininneet, GitOps-konseptit kehitettiin alun perin Kubernetes-sovellusten hallintaan. Palaa nyt Weaveworksin GitOps-keskusteluun sen avulla, mitä tiedämme nyt GitOpsista, ja katso, miten ne kuvaavat, kuinka päivittäisit GitOps-periaatteilla hallittua Kubernetesia. Tässä on yhteenveto:
- Kehittäjä tekee uuden ominaisuuden Git-vetopyynnön.
- Koodi tarkistetaan ja hyväksytään, ja sitten se yhdistetään pääkoodiin.
- Yhdistäminen laukaisee CI / CD-putkiston, joka testaa ja rakentaa uuden koodin automaattisesti ja sijoittaa sen rekisteriin.
- Ohjelmistoagentti huomaa päivityksen, vetää uuden koodin rekisteristä ja päivittää määritystiedoston (kirjoitettu YAML-muodossa) määritysvarastossa.
- Ohjelmistoagentti Kubernetes-klusterissa havaitsee kokoonpanotiedoston perusteella, että klusteri on vanhentunut, vetää muutokset ja ottaa uuden ominaisuuden käyttöön.
Weaveworks ja GitOps
Tässä selvästi vaiheet 4 ja 5 tekevät paljon raskaasta nostosta. Ohjelmistoagentit, jotka synkronoivat maagisesti Gitin arkiston "totuuden lähteen" todellisen Kubernetes-sovelluksen kanssa, ovat taika, joka tekee GitOpsista mahdollisen. Kuten olemme sanoneet, GitOps-termeillä prosessia, jolla live-järjestelmät tehdään enemmän kuin konfiguraatiotiedostoissa kuvatut ihanteelliset järjestelmät, kutsutaan lähentyminen. (Kun live-järjestelmä ja ihanteellinen järjestelmä eivät ole synkronoitu, niin eroavaisuuksia.) Ihannetapauksessa konvergenssi saavutettaisiin automatisoiduilla prosesseilla, mutta automaatiolla voi olla rajoituksia, ja joskus tarvitaan ihmisen toimia.
Olemme kuvanneet prosessin tässä yleisesti, mutta itse asiassa, jos todella katsot Weaveworksin sivua, mainitsemamme "ohjelmistoagentit" ovat osa yrityksen Weave Cloud -alustaa. Termin "GitOps" kehitti Weaveworksin toimitusjohtaja Alexis Richardson, ja se palvelee osittain sitä, että Weaveworks-alusta houkuttelee kehittäjiä, jotka ovat jo täynnä devops- ja CI / CD-maailmoissa.
Mutta Weaveworks ei ole koskaan väittänyt GitOpsin monopoliasemaa, mikä on enemmän filosofiaa ja parhaiden käytäntöjen joukko kuin tietty tuote. CI / CD-ratkaisuja tarjoavan CloudBees-yrityksen blogi toteaa, että GitOps edustaa avointa, myyjäneutraalia mallia, joka kehitettiin vastauksena hallittujen omien Kubernetes-ratkaisujen käyttöönottoon suurilla pilvimyyjillä, kuten Amazon, Google ja Microsoft. . CloudBees tarjoaa omat GitOps-ratkaisunsa, samoin kuin monet pelaajat tässä tilassa.
GitOps ja devops
Atlassianilla, joka tekee useita työkaluja ketterille kehittäjille, on aikasi arvoinen perusteellinen blogiteksti GitOpsin historiasta ja tarkoituksesta. Heidän mielestään GitOps edustaa loogista jatkoa ideoiksi, jotka kokoontuivat devopsina. GitOps on tarkemmin määritelty infrastruktuurin käsite koodiksi, itsessään idea, joka tuli ulos devops-ympäristöstä. GitOps, kuten Atlassian näkee, ylitti ratkaisevan kuilun olemassa olevien devops-tekniikoiden välillä, jotka olivat kehittyneet ratkaisemaan järjestelmänhallinnan ongelmia, ja hajautettujen pilvipalvelusovellusten erityistarpeiden välillä. Eri pilvimyyjien tarjoama automatisoitu lähentyminen tekee GitOpsista erityisen.
Ja vaikka GitOps keskittyy edelleen Kubernetesiin, toivomme, että olemme tehneet selväksi, miten se soveltuu hajautettujen, pilvipohjaisten sovellusten paljon laajempaan maailmaan. Avoimen lähdekoodin tietoturvatoimittajan WhiteSourcen blogikirjoitus kuvaa GitOpsin edut:
- Havaittavuus: GitOps-järjestelmät tarjoavat valvontaa, kirjaamista, seurantaa ja visualisointia monimutkaisiksi sovelluksiksi, jotta kehittäjät näkevät, mikä rikkoo ja missä.
- Versioiden hallinta ja muutosten hallinta: Tämä on tietysti keskeinen etu Gitin kaltaisen versionhallintajärjestelmän käytöstä. Vialliset päivitykset voidaan helposti palauttaa.
- Helppo hyväksyminen: GitOps perustuu devops-taitoihin, joita monilla kehittäjillä on jo.
- Tuottavuus: GitOps tarjoaa tuottavuuden parannuksia, joita devops ja CI / CD ovat tuoneet muihin alueisiin.
- Tarkastus: Gitin ansiosta jokainen toiminto voidaan jäljittää tiettyyn sitoutumiseen, mikä tekee virheiden syyn selvittämisen helpoksi.
Vaikka et käytä Kubernetesia, on todennäköistä, että GitOps on osa työnkulkua ennemmin tai myöhemmin.
