Huomautus. käännös: Äskettäisen julkaisun jälkeen veto- ja työntömenetelmistä GitOpsissa, näimme kiinnostusta tähän malliin yleisesti, mutta venäjänkielisiä julkaisuja aiheesta oli hyvin vähän (Habresta ei yksinkertaisesti ole yhtään). Siksi meillä on ilo tarjota huomionne käännös toisesta artikkelista - tosin melkein vuosi sitten! - Weaveworksilta, jonka johtaja loi termin "GitOps". Tekstissä selitetään lähestymistavan olemus ja keskeiset erot olemassa oleviin.
Vuosi sitten julkaisimme . Tuolloin kerroimme, kuinka Weaveworks-tiimi lanseerasi kokonaan Kubernetesiin perustuvan SaaS-ratkaisun ja kehitti joukon ohjeellisia parhaita käytäntöjä pilvipohjaisessa ympäristössä tapahtuvaa käyttöönottoa, hallintaa ja seurantaa varten.
Artikkeli osoittautui suosituksi. Muut ihmiset alkoivat puhua GitOpsista ja alkoivat julkaista uusia työkaluja , , , , ja niin edelleen. Ilmestynyt verkkosivuillamme julkaisut ja GitOps-käyttötapaukset. Mutta joillakin ihmisillä on edelleen kysymyksiä. Miten malli eroaa perinteisestä? ja jatkuva toimitus ()? Onko Kubernetesin käyttö välttämätöntä?
Huomasimme pian, että tarvitaan uusi kuvaus, joka tarjoaa:
- Suuri määrä esimerkkejä ja tarinoita;
- GitOpsin erityinen määritelmä;
- Vertailu perinteiseen jatkuvaan toimitukseen.
Tässä artikkelissa olemme yrittäneet kattaa kaikki nämä aiheet. Se tarjoaa päivitetyn johdannon GitOpsiin sekä kehittäjä- ja CI/CD-näkökulman. Keskitymme ensisijaisesti Kubernetesiin, vaikka mallia voi yleistää.
Tutustu GitOpsiin
Kuvittele Alice. Hän johtaa perhevakuutusta, joka tarjoaa terveys-, auto-, koti- ja matkavakuutuksia ihmisille, jotka ovat liian kiireisiä selvittämään itse sopimusten yksityiskohdat. Hänen liiketoimintansa alkoi sivuprojektina, kun Alice työskenteli pankissa datatieteilijänä. Eräänä päivänä hän tajusi, että hän voisi käyttää kehittyneitä tietokonealgoritmeja analysoimaan dataa ja laatimaan vakuutuspaketteja tehokkaammin. Sijoittajat rahoittivat projektin, ja nyt hänen yrityksensä tuo yli 20 miljoonaa dollaria vuodessa ja kasvaa nopeasti. Tällä hetkellä se työllistää 180 henkilöä eri tehtävissä. Tähän kuuluu teknologiatiimi, joka kehittää, ylläpitää verkkosivustoa, tietokantaa ja analysoi asiakaskuntaa. 60 hengen tiimiä johtaa yrityksen tekninen johtaja Bob.
Bobin tiimi ottaa tuotantojärjestelmiä käyttöön pilvessä. Heidän ydinsovelluksensa toimivat GKE:ssä hyödyntäen Google Cloudin Kubernetesia. Lisäksi he käyttävät työssään erilaisia data- ja analytiikkatyökaluja.
Perhevakuutus ei ryhtynyt käyttämään kontteja, mutta jäi kiinni Dockerin innostukseen. Yritys huomasi pian, että GKE teki helpoksi ottaa käyttöön klustereita uusien ominaisuuksien testaamiseksi. Jenkins for CI ja Quay lisättiin järjestämään konttirekisteriä, Jenkinsille kirjoitettiin komentosarjoja, jotka työnsivät uusia säiliöitä ja määrityksiä GKE:hen.
Jonkin verran aikaa on kulunut. Alice ja Bob olivat pettyneitä valitsemansa lähestymistapaan ja sen vaikutukseen liiketoimintaan. Konttien käyttöönotto ei parantanut tuottavuutta niin paljon kuin tiimi oli toivonut. Joskus käyttöönotot katkesivat, ja oli epäselvää, olivatko koodimuutokset syyllisiä. Myös asetusmuutosten seuranta osoittautui vaikeaksi. Usein jouduttiin luomaan uusi klusteri ja siirtämään siihen sovelluksia, sillä tämä oli helpoin tapa poistaa järjestelmästä muodostunut sotku. Alice pelkäsi tilanteen pahenevan sovelluksen kehittyessä (lisäksi oli tulossa uusi koneoppimiseen perustuva projekti). Bob oli automatisoinut suurimman osan työstä, eikä ymmärtänyt, miksi putkisto oli edelleen epävakaa, ei skaalautunut hyvin ja vaati ajoittain manuaalisia toimia?
Sitten he oppivat GitOpsista. Tämä päätös osoittautui juuri sellaiseksi, mitä he tarvitsivat päästäkseen eteenpäin luottavaisesti.
Alice ja Bob ovat kuulleet Gitistä, DevOpsista ja infrastruktuurista koodityönkulkuina vuosia. GitOpsin ainutlaatuisuus on, että se tuo joukon parhaita käytäntöjä – sekä lopullisia että normatiivisia – näiden ideoiden toteuttamiseen Kubernetesin kontekstissa. Tämä teema , mukaan lukien .
Perhevakuutus päättää ottaa GitOps käyttöön. Yhtiöllä on nyt automaattinen toimintamalli, joka on yhteensopiva Kubernetesin ja yhdistelmien kanssa nopeus kanssa vakauttakoska he:
- havaitsi, että joukkueen tuottavuus kaksinkertaistui ilman, että kukaan olisi tullut hulluksi;
- lopetti skriptien tarjoamisen. Sen sijaan he voivat nyt keskittyä uusiin ominaisuuksiin ja parantaa suunnittelumenetelmiä – esimerkiksi ottamalla käyttöön Canary-versioita ja parantamalla testausta;
- olemme parantaneet käyttöönottoprosessia niin, että se harvoin hajoaa;
- sai mahdollisuuden palauttaa käyttöönotot osittaisten vikojen jälkeen ilman manuaalista puuttumista;
- ostettu käytettynäоLisää luottamusta toimitusjärjestelmiin. Alice ja Bob huomasivat, että he voisivat jakaa tiimin rinnakkain toimiviin mikropalvelutiimeihin;
- voi tehdä 30-50 muutosta projektiin joka päivä kunkin ryhmän ponnisteluilla ja kokeilla uusia tekniikoita;
- projektiin on helppo houkutella uusia kehittäjiä, joilla on mahdollisuus ottaa käyttöön päivitykset tuotantoon vetopyyntöjen avulla muutamassa tunnissa;
- helposti läpäisevä tarkastus SOC2:n puitteissa (palveluntarjoajien turvallista tiedonhallintaa koskevien vaatimusten noudattamisesta; lue lisää esim. - noin käännös.).
Mitä tapahtui?
GitOps on kaksi asiaa:
- Toimintamalli Kubernetesille ja pilvi-natiiville. Se tarjoaa joukon parhaita käytäntöjä konttiklusterien ja -sovellusten käyttöönottoon, hallintaan ja valvontaan. Tyylikäs määritelmä muodossa alkaen :
- Polku kehittäjäkeskeisen sovellushallintaympäristön luomiseen. Käytämme Git-työnkulkua sekä toimintaan että kehitykseen. Huomaa, että tämä ei koske vain Git pushia, vaan koko CI/CD- ja UI/UX-työkalusarjan järjestämistä.
Muutama sana Gitistä
Jos et tunne versionhallintajärjestelmiä ja Git-pohjaista työnkulkua, suosittelemme tutustumaan niihin. Haarojen ja vetopyyntöjen kanssa työskentely voi aluksi tuntua mustalta magialta, mutta hyödyt ovat vaivan arvoisia. Tässä aloittaa.
Miten Kubernetes toimii
Tarinassamme Alice ja Bob kääntyivät GitOpsiin työskenneltyään jonkin aikaa Kubernetesin kanssa. GitOps liittyykin läheisesti Kubernetesiin – se on toimintamalli Kubernetesiin perustuville infrastruktuurille ja sovelluksille.
Mitä Kubernetes antaa käyttäjille?
Tässä on joitain pääominaisuuksia:
- Kubernetes-mallissa kaikki voidaan kuvata deklaratiivisessa muodossa.
- Kubernetes API -palvelin ottaa tämän ilmoituksen syötteenä ja yrittää sitten jatkuvasti saattaa klusterin ilmoituksessa kuvattuun tilaan.
- Ilmoitukset ovat riittäviä kuvaamaan ja hallitsemaan monenlaisia työkuormia – "sovelluksia".
- Tämän seurauksena sovellukseen ja klusteriin tapahtuu muutoksia seuraavista syistä:
- muutokset konttikuvissa;
- muutokset deklaratiiviseen eritelmään;
- ympäristön virheet - esimerkiksi kontin kaatumiset.
Kubernetesin suuret konvergenssiominaisuudet
Kun järjestelmänvalvoja tekee kokoonpanomuutoksia, Kubernetes-orkesteri soveltaa niitä klusteriin niin kauan kuin sen tila on ei tule lähelle uutta kokoonpanoa. Tämä malli toimii kaikissa Kubernetes-resursseissa ja on laajennettavissa mukautetuilla resurssien määritelmillä (CRD). Siksi Kubernetes-asetuksissa on seuraavat upeat ominaisuudet:
- automaatio: Kubernetes-päivitykset tarjoavat mekanismin, joka automatisoi muutosten käyttöönoton sulavasti ja oikea-aikaisesti.
- Lähentyminen: Kubernetes jatkaa päivitysten yrittämistä, kunnes onnistuu.
- Idempotenssi: Toistuvat konvergenssisovellukset johtavat samaan tulokseen.
- Determinismi: Kun resurssit ovat riittävät, päivitetyn klusterin tila riippuu vain halutusta tilasta.
Miten GitOps toimii
Olemme oppineet tarpeeksi Kubernetesista selittääksemme, kuinka GitOps toimii.
Palataan perhevakuutuksen mikropalvelutiimeihin. Mitä heidän yleensä pitää tehdä? Katso alla olevaa luetteloa (jos jotkin sen sisältämät kohteet vaikuttavat oudolta tai vierailta, älä kritisoi ja pysy kanssamme). Nämä ovat vain esimerkkejä Jenkins-pohjaisista työnkulkuista. Muiden työkalujen kanssa työskentelyssä on monia muita prosesseja.
Tärkeintä on, että näemme jokaisen päivityksen päättyvän määritystiedostojen ja Git-varastojen muutoksiin. Nämä Gitiin tehdyt muutokset saavat "GitOps-operaattorin" päivittämään klusterin:
1. Työprosessi: "Jenkins build - päähaara'.
Tehtävälista:
- Jenkins työntää merkityt kuvat Quayyn;
- Jenkins työntää konfigurointi- ja Helm-kaaviot master-tallennusämpäriin;
- Pilvitoiminto kopioi konfiguraation ja kaaviot päätallennussäilystä Git-päätietovarastoon;
- GitOps-operaattori päivittää klusterin.
2. Jenkins build - julkaisu tai hotfix haara:
- Jenkins työntää merkitsemättömät kuvat Quayyn;
- Jenkins työntää konfigurointi- ja Helm-kaaviot välimuistiin;
- Pilvitoiminto kopioi konfiguraation ja kaaviot staging-tallennussäilöstä vaiheittaiseen Git-tietovarastoon;
- GitOps-operaattori päivittää klusterin.
3. Jenkins rakentaa - kehittää tai ominaisuus haara:
- Jenkins työntää merkitsemättömät kuvat Quayyn;
- Jenkins työntää konfigurointi- ja Helm-kaaviot kehitystallennustilaan;
- Pilvitoiminto kopioi konfiguraation ja kaaviot kehitystallennusalueesta kehittämään Git-tietovarastoon;
- GitOps-operaattori päivittää klusterin.
4. Uuden asiakkaan lisääminen:
- Ylläpitäjä tai järjestelmänvalvoja (LCM/ops) kutsuu Gradlea ottamaan käyttöön ja määrittämään verkon kuormituksen tasaajat (NLB:t);
- LCM/ops tekee uuden konfiguraation valmistellakseen käyttöönottoa päivityksiä varten;
- GitOps-operaattori päivittää klusterin.
Lyhyt kuvaus GitOpsista
- Kuvaile koko järjestelmän haluttua tilaa käyttämällä kunkin ympäristön deklaratiivisia määrityksiä (tarinassamme Bobin tiimi määrittelee koko järjestelmäkokoonpanon Gitissä).
- Git-arkisto on ainoa totuuden lähde koskien koko järjestelmän haluttua tilaa.
- Kaikki muutokset haluttuun tilaan tehdään Git-toimitusten kautta.
- Kaikki halutut klusterin parametrit ovat myös havaittavissa itse klusterissa. Tällä tavalla voimme määrittää, ovatko ne samat (konvergoivat, suppenee) tai erota (poikkeaa, erota) halutut ja havaitut tilat.
- Jos halutut ja havaitut tilat poikkeavat toisistaan, niin:
- On olemassa konvergenssimekanismi, joka ennemmin tai myöhemmin automaattisesti synkronoi kohde- ja havaitut tilat. Klusterin sisällä Kubernetes tekee tämän.
- Prosessi alkaa välittömästi "muutossitoutuneella" -varoituksella.
- Jonkin konfiguroitavan ajan kuluttua voidaan lähettää "diff"-hälytys, jos tilat ovat erilaiset.
- Tällä tavalla kaikki Gitin sitoumukset aiheuttavat todennettavia ja idempotentteja päivityksiä klusteriin.
- Palautus on konvergenssi aiemmin haluttuun tilaan.
- Konvergenssi on lopullinen. Sen esiintyminen on osoitettu:
- Ei erohälytyksiä tietyn ajanjakson aikana.
- "konvergoitunut" hälytys (esim. webhook, Git-kirjoitustapahtuma).
Mikä on ero?
Toistetaan vielä: kaikkien haluttujen klusterin ominaisuuksien on oltava havaittavissa itse klusterissa.
Muutamia esimerkkejä eroista:
- Muutos konfiguraatiotiedostossa Gitin haarojen yhdistämisen vuoksi.
- Muutos konfiguraatiotiedostossa GUI-asiakkaan tekemän Git-sitoumuksen vuoksi.
- Useita muutoksia haluttuun tilaan Gitin PR:n vuoksi, minkä jälkeen konttikuvan rakentaminen ja konfiguraatiomuutokset.
- Muutos klusterin tilassa virheen vuoksi, resurssiristiriita, joka johtaa "huonoon käyttäytymiseen" tai yksinkertaisesti satunnaiseen poikkeamiseen alkuperäisestä tilasta.
Mikä on konvergenssin mekanismi?
Muutama esimerkki:
- Säiliöiden ja klustereiden konvergenssimekanismin tarjoaa Kubernetes.
- Samaa mekanismia voidaan käyttää Kubernetes-pohjaisten sovellusten ja suunnitelmien (kuten Istio ja Kubeflow) hallintaan.
- Mekanismi Kubernetesin, kuvavarastojen ja Gitin välisen operatiivisen vuorovaikutuksen hallintaan tarjoaa , joka on osa .
- Peruskoneissa konvergenssimekanismin on oltava deklaratiivinen ja itsenäinen. Oman kokemuksemme perusteella voimme sanoa sen lähinnä tätä määritelmää, mutta vaatii silti ihmisen hallinnan. Tässä mielessä GitOps laajentaa Infrastructure as Code -perinnettä.
GitOps yhdistää Gitin Kubernetesin erinomaiseen konvergenssimoottoriin tarjotakseen mallin hyväksikäyttöä varten.
GitOps antaa meille mahdollisuuden sanoa: Vain sellaiset järjestelmät, joita voidaan kuvata ja tarkkailla, voidaan automatisoida ja ohjata.
GitOps on tarkoitettu koko pilvipohjaiselle pinolle (esim. Terraform jne.)
GitOps ei ole vain Kubernetes. Haluamme, että koko järjestelmää ohjataan deklaratiivisesti ja käytetään konvergenssia. Koko järjestelmällä tarkoitamme kokoelmaa ympäristöjä, jotka toimivat Kubernetesin kanssa - esimerkiksi "dev cluster 1", "production" jne. Jokainen ympäristö sisältää koneita, klustereita, sovelluksia sekä rajapintoja ulkoisille palveluille, jotka tarjoavat dataa, valvontaa ja jne.
Huomaa, kuinka tärkeä Terraform on käynnistysongelmalle tässä tapauksessa. Kubernetes on otettava käyttöön jossain, ja Terraformin käyttö tarkoittaa, että voimme käyttää samoja GitOps-työnkulkuja Kubernetesia ja sovelluksia tukevan ohjauskerroksen luomiseen. Tämä on hyödyllinen paras käytäntö.
Keskitytään voimakkaasti GitOps-konseptien soveltamiseen Kubernetesin päällä oleviin tasoihin. Tällä hetkellä Istiolle, Helmille, Ksonnetille, OpenFaaS:lle ja Kubeflow:lle sekä esimerkiksi Pulumille on olemassa GitOps-tyyppisiä ratkaisuja, jotka luovat kerroksen pilvipohjaisten sovellusten kehittämiselle.
Kubernetes CI/CD: GitOpsien vertailu muihin lähestymistapoihin
Kuten todettiin, GitOps on kaksi asiaa:
- Yllä kuvattu Kubernetesin ja pilven natiivin toimintamalli.
- Polku kehittäjäkeskeiseen sovellushallintaympäristöön.
Monille GitOps on ensisijaisesti Git-työntöihin perustuva työnkulku. Pidämme hänestä myös. Mutta siinä ei vielä kaikki: katsotaanpa nyt CI/CD-putkia.
GitOps mahdollistaa jatkuvan käyttöönoton (CD) Kubernetesille
GitOps tarjoaa jatkuvan käyttöönottomekanismin, joka eliminoi erillisten "käytön hallintajärjestelmien" tarpeen. Kubernetes tekee kaiken työn puolestasi.
- Sovelluksen päivittäminen vaatii päivityksen Gitissä. Tämä on tapahtumapäivitys haluttuun tilaan. Kubernetes itse suorittaa "käyttöönoton" klusterin sisällä päivitetyn kuvauksen perusteella.
- Kubernetesin toiminnan luonteen vuoksi nämä päivitykset ovat yhdenmukaisia. Tämä tarjoaa jatkuvan käyttöönoton mekanismin, jossa kaikki päivitykset ovat ydinasioita.
- Huom: tarjoaa GitOps-operaattorin, joka integroi Gitin ja Kubernetesin ja mahdollistaa CD-levyn suorittamisen sovittamalla yhteen klusterin haluttu ja nykyinen tila.
Ilman kubectlia ja skriptejä
Sinun tulee välttää Kubectlin käyttöä klusterin päivittämiseen ja erityisesti skriptien käyttöä kubectl-komentojen ryhmittelyyn. Sen sijaan GitOps-putkilinjan avulla käyttäjä voi päivittää Kubernetes-klusterinsa Gitin kautta.
Edut sisältävät:
- Oikein. Joukko päivityksiä voidaan soveltaa, lähentää ja lopuksi validoida, mikä vie meidät lähemmäksi ydinasetuksen tavoitetta. Sitä vastoin komentosarjojen käyttö ei takaa lähentymistä (lisätietoja alla).
- Безопасность. Kelsey Hightower: "Rajoita pääsy Kubernetes-klusteriisi automaatiotyökaluille ja järjestelmänvalvojille, jotka ovat vastuussa virheenkorjauksesta tai sen ylläpidosta." Katso myös turvallisuudesta ja teknisten eritelmien noudattamisesta sekä varastamalla valtakirjat huolimattomasti kirjoitetusta Jenkinsin käsikirjoituksesta.
- Käyttäjäkokemus. Kubectl paljastaa Kubernetes-objektimallin mekaniikan, joka on melko monimutkainen. Ihannetapauksessa käyttäjien tulisi olla vuorovaikutuksessa järjestelmän kanssa korkeammalla abstraktiotasolla. Tässä viittaan jälleen Kelseyyn ja suosittelen katsomista .
Ero CI:n ja CD:n välillä
GitOps parantaa olemassa olevia CI/CD-malleja.
Nykyaikainen CI-palvelin on orkestrointityökalu. Se on erityisesti työkalu CI-putkien organisointiin. Näitä ovat muun muassa rakentaminen, testaus, yhdistäminen runkoon jne. CI-palvelimet automatisoivat monimutkaisten monivaiheisten putkien hallinnan. Yleinen kiusaus on kirjoittaa joukko Kubernetes-päivityksiä ja suorittaa se osana liukuhihnaa muutosten siirtämiseksi klusteriin. Todellakin, monet asiantuntijat tekevät näin. Tämä ei kuitenkaan ole optimaalinen, ja tässä on syy.
CI:tä tulisi käyttää päivitysten työntämiseen runkoon, ja Kubernetes-klusterin pitäisi muuttua itse näiden päivitysten perusteella hallitakseen CD-levyä sisäisesti. Me kutsumme sitä , toisin kuin CI push -malli. CD on osa runtime orkestraatio.
Miksi CI-palvelinten ei pitäisi tehdä CD-levyjä suorien päivitysten kautta Kubernetesissa?
Älä käytä CI-palvelinta Kubernetesin suorien päivitysten järjestämiseen CI-töiden joukkona. Tämä on se anti-malli, josta puhumme blogissasi.
Palataanpa Aliceen ja Bobiin.
Mitä ongelmia he kohtasivat? Bobin CI-palvelin ottaa muutokset käyttöön klusteriin, mutta jos se kaatuu prosessin aikana, Bob ei tiedä, missä tilassa klusteri on (tai missä sen pitäisi olla) tai kuinka se korjataan. Sama pätee onnistumisen tapauksessa.
Oletetaan, että Bobin tiimi loi uuden kuvan ja korjasi sitten käyttöönottonsa ottaakseen kuvan käyttöön (kaikki CI-putkistosta).
Jos kuva muodostuu normaalisti, mutta putkisto epäonnistuu, tiimin on selvitettävä:
- Onko päivitys julkaistu?
- Aloitammeko uuden rakennuksen? Aiheuttaako tämä tarpeettomia sivuvaikutuksia - mahdollisuutta saada kaksi samasta muuttumattomasta kuvasta?
- Pitäisikö meidän odottaa seuraavaa päivitystä ennen koontiversion suorittamista?
- Mikä meni tarkalleen pieleen? Mitkä vaiheet on toistettava (ja mitkä ovat turvallisia toistaa)?
Git-pohjaisen työnkulun luominen ei takaa, että Bobin tiimi ei kohtaa näitä ongelmia. He voivat silti tehdä virheen commit push -tunnisteen, tagin tai jonkin muun parametrin kanssa; Tämä lähestymistapa on kuitenkin vielä paljon lähempänä eksplisiittistä kaikki tai ei mitään -lähestymistapaa.
Yhteenvetona voidaan todeta, miksi CI-palvelinten ei pitäisi käsitellä CD-levyjä:
- Päivitysskriptit eivät aina ole deterministisiä; Niissä on helppo tehdä virheitä.
- CI-palvelimet eivät lähenty deklaratiiviseen klusterimalliin.
- Idempotenssia on vaikea taata. Käyttäjien on ymmärrettävä järjestelmän syvä semantiikka.
- Osittaisesta epäonnistumisesta on vaikeampi toipua.
Huomautus Helmistä: Jos haluat käyttää Helmiä, suosittelemme sen yhdistämistä GitOps-operaattoriin, kuten . Tämä auttaa varmistamaan lähentymisen. Helm itsessään ei ole deterministinen eikä atominen.
GitOps on paras tapa toteuttaa jatkuva toimitus Kubernetesille
Alicen ja Bobin tiimi ottaa GitOpsin käyttöön ja huomaa, että ohjelmistotuotteiden käsittelystä, korkean suorituskyvyn ja vakauden ylläpitämisestä on tullut paljon helpompaa. Lopetetaan tämä artikkeli havainnolla, joka näyttää, miltä heidän uusi lähestymistapansa näyttää. Muista, että puhumme enimmäkseen sovelluksista ja palveluista, mutta GitOpsia voidaan käyttää kokonaisen alustan hallintaan.
Toimintamalli Kubernetesille
Katso seuraava kaavio. Se esittelee Gitin ja säilön kuvavaraston yhteisinä resursseina kahdelle organisoidulle elinkaarelle:
- Jatkuva integrointiputki, joka lukee ja kirjoittaa tiedostoja Gitiin ja voi päivittää säilön kuvien arkiston.
- Suorituksenaikainen GitOps-putkisto, joka yhdistää käyttöönoton hallintaan ja havainnointiin. Se lukee ja kirjoittaa tiedostoja Gitiin ja voi ladata säilökuvia.
Mitkä ovat tärkeimmät havainnot?
- Huolien erottelu: Huomaa, että molemmat liukuhihnat voivat kommunikoida vain päivittämällä Git tai kuvavarasto. Toisin sanoen CI:n ja ajonaikaisen ympäristön välillä on palomuuri. Kutsumme sitä "muuttumattomuuden palomuuriksi" (muuttumattomuus palomuuri), koska kaikki arkiston päivitykset luovat uusia versioita. Lisätietoja tästä aiheesta on dioissa 72-87 .
- Voit käyttää mitä tahansa CI- ja Git-palvelinta: GitOps toimii minkä tahansa komponentin kanssa. Voit jatkaa suosikkisi CI- ja Git-palvelimiesi, kuvavarastojen ja testiohjelmistojen käyttöä. Lähes kaikki muut markkinoilla olevat jatkuvan jakelun työkalut vaativat oman CI/Git-palvelimen tai kuvavaraston. Tästä voi tulla rajoittava tekijä pilven natiivin kehittämisessä. GitOpsissa voit käyttää tuttuja työkaluja.
- Tapahtumat integraatiotyökaluna: Heti kun Gitin tiedot päivitetään, Weave Flux (tai Weave Cloud -operaattori) ilmoittaa suoritusajan. Aina kun Kubernetes hyväksyy muutosjoukon, Git päivitetään. Tämä tarjoaa yksinkertaisen integraatiomallin GitOps-työnkulkujen järjestämiseen alla olevan kuvan mukaisesti.
Johtopäätös
GitOps tarjoaa vahvat päivitystakuut, joita kaikki nykyaikaiset CI/CD-työkalut vaativat:
- automaatio;
- lähentyminen;
- idempotenssi;
- determinismi.
Tämä on tärkeää, koska se tarjoaa toimintamallin pilvipohjaisille kehittäjille.
- Perinteiset työkalut järjestelmien hallintaan ja valvontaan liittyvät runbookin sisällä toimiviin käyttöryhmiin (joukko rutiinitoimenpiteitä ja -toimintoja - noin käännös), joka on sidottu tiettyyn käyttöön.
- Pilven natiivihallinnassa havainnointityökalut ovat paras tapa mitata käyttöönottojen tuloksia, jotta kehitystiimi voi reagoida nopeasti.
Kuvittele monia klustereita hajallaan eri pilvissä ja monissa palveluissa omilla tiimeillään ja käyttöönottosuunnitelmillaan. GitOps tarjoaa mittakaavaltaan muuttumattoman mallin kaiken tämän runsauden hallintaan.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «'.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Tiesitkö GitOpsista ennen kuin nämä kaksi käännöstä ilmestyivät Habrelle?
-
Kyllä, tiesin kaiken
-
Vain pinnallisesti
-
Ei
35 käyttäjää äänesti. 10 käyttäjää pidättyi äänestämästä.
Lähde: will.com