Huomautus. käännös: Kubernetes-yhteisössä trendi nimeltä GitOps on saamassa selvää suosiota, kuten olemme henkilökohtaisesti nähneet, KubeCon Europe 2019. Tämä termi oli suhteellisen tuore Weaveworksin johtajan - Alexis Richardsonin - mukaan ja se tarkoittaa kehittäjille tuttujen työkalujen (ensisijaisesti Git, tästä nimi) käyttöä operatiivisten ongelmien ratkaisemiseen. Erityisesti puhumme Kubernetesin toiminnasta tallentamalla sen kokoonpanot Gitiin ja ottamalla muutokset käyttöön automaattisesti klusteriin. Matthias Jg puhuu tässä artikkelissa kahdesta lähestymistavasta tähän käyttöönottoon.
Viime vuonna (itse asiassa muodollisesti tämä tapahtui elokuussa 2017 - noin käännös.) Kubernetesin sovellusten käyttöönotossa on uusi lähestymistapa. Sitä kutsutaan GitOpsiksi, ja se perustuu perusajatukseen, että käyttöönottoversioita seurataan Git-tietovaraston suojatussa ympäristössä.
Tämän lähestymistavan tärkeimmät edut ovat seuraavat::
- Käyttöönoton versiointi ja muutoshistoria. Koko klusterin tila tallennetaan Git-tietovarastoon, ja käyttöönotot päivitetään vain toimitusten kautta. Lisäksi kaikkia muutoksia voidaan seurata toimitushistorian avulla.
- Palautukset tuttujen Git-komentojen avulla... Tavallinen
git resetvoit nollata käyttöönottojen muutokset; menneet tilat ovat aina saatavilla. - Valmis kulunvalvonta. Tyypillisesti Git-järjestelmä sisältää paljon arkaluonteista dataa, joten useimmat yritykset kiinnittävät erityistä huomiota sen suojaamiseen. Vastaavasti tämä suojaus koskee myös käyttöönottoja.
- Käyttöönottokäytännöt. Useimmat Git-järjestelmät tukevat natiivisti haarakohtaisia käytäntöjä – esimerkiksi vain vetopyynnöt voivat päivittää pääjärjestelmän, ja toisen tiimin jäsenen on tarkistettava ja hyväksyttävä muutokset. Käyttöönottopäivityksiin sovelletaan samoja käytäntöjä kuin käyttöoikeuksien hallinnassa.
Kuten näet, GitOps-menetelmällä on monia etuja. Kuluneen vuoden aikana kaksi lähestymistapaa on saavuttanut erityisen suosion. Toinen on työntöpohjainen, toinen vetopohjainen. Ennen kuin tarkastelemme niitä, katsotaanpa ensin, miltä tyypilliset Kubernetes-asennukset näyttävät.
Käyttöönottomenetelmät
Viime vuosina Kubernetesissa on vakiinnuttanut erilaisia käyttöönottomenetelmiä ja työkaluja:
- Perustuu alkuperäisiin Kubernetes/Kustomize-malleihin. Tämä on helpoin tapa ottaa sovelluksia käyttöön Kubernetesissa. Kehittäjä luo YAML-perustiedostot ja käyttää niitä. Kustomize kehitettiin päästäkseen eroon samojen mallien jatkuvasta uudelleenkirjoittamisesta (se muuttaa Kubernetes-mallit moduuleiksi). Huomautus. käännös: Kustomize on integroitu kubectliin kanssa .
- Ruorikaaviot. Ruorikaavioiden avulla voit luoda sarjoja malleja, aloitussäilöjä, sivuvaunuja jne., joita käytetään sovellusten käyttöönottamiseksi, joissa on joustavammat mukautusvaihtoehdot kuin mallipohjaisessa lähestymistavassa. Tämä menetelmä perustuu mallipohjaisiin YAML-tiedostoihin. Helm täyttää ne eri parametreilla ja lähettää ne sitten Tillerille, klusterikomponentille, joka ottaa ne käyttöön klusteriin ja mahdollistaa päivitykset ja palautukset. Tärkeää on, että Helm periaatteessa vain lisää halutut arvot malleihin ja sitten soveltaa niitä samalla tavalla kuin perinteisessä lähestymistavassa (lue lisää siitä, miten se kaikki toimii ja kuinka voit käyttää sitä meidän - noin käännös.). On olemassa laaja valikoima valmiita Helm-kaavioita, jotka kattavat monenlaisia tehtäviä.
- Vaihtoehtoiset työkalut. Vaihtoehtoisia työkaluja on monia. Niille kaikille on yhteistä, että ne muuttavat jotkin mallitiedostot Kubernetes-luetettaviksi YAML-tiedostoiksi ja käyttävät niitä sitten.
Käytämme työssämme jatkuvasti Helm-kaavioita tärkeille työkaluille (koska niissä on paljon asioita valmiina, mikä helpottaa elämää huomattavasti) ja "puhtaita" Kubernetes YAML -tiedostoja omien sovelluksiemme käyttöönotossa.
Vedä Työnnä
Yhdessä viimeaikaisessa blogikirjoituksessani esittelin työkalun , jonka avulla voit sitoa malleja Git-säilöön ja päivittää käyttöönoton jokaisen säilön sitoumuksen tai työnnön jälkeen. Kokemukseni osoittaa, että tämä työkalu on yksi tärkeimmistä veto-lähestymistavan edistämisessä, joten viittaan siihen usein. Jos haluat tietää lisää sen käytöstä, täältä .
HUOM! Kaikki GitOpsin käytön edut pysyvät samoina molemmissa lähestymistavoissa.
Vetopohjainen lähestymistapa
Vetomenetelmä perustuu siihen, että kaikki muutokset otetaan käyttöön klusterin sisältä. Klusterin sisällä on operaattori, joka tarkistaa säännöllisesti liittyvät Git- ja Docker-rekisterivarastot. Jos niissä tapahtuu muutoksia, klusterin tila päivitetään sisäisesti. Tätä prosessia pidetään yleensä erittäin turvallisena, koska millään ulkoisella asiakkaalla ei ole pääsyä klusterin järjestelmänvalvojan oikeuksiin.
Plussat:
- Millään ulkoisella asiakkaalla ei ole oikeutta tehdä muutoksia klusteriin; kaikki päivitykset julkaistaan sisältäpäin.
- Joidenkin työkalujen avulla voit myös synkronoida Helm-kaaviopäivityksiä ja linkittää ne klusteriin.
- Docker Registry voidaan skannata uusien versioiden varalta. Jos uusi näköistiedosto on saatavilla, Git-tietovarasto ja käyttöönotto päivitetään uuteen versioon.
- Vetotyökalut voidaan jakaa eri nimiavaruuksiin erilaisilla Git-varastoilla ja -oikeuksilla. Tämän ansiosta voidaan käyttää usean vuokralaisen mallia. Esimerkiksi tiimi A saattaa käyttää nimiavaruutta A, tiimi B voi käyttää nimiavaruutta B ja infrastruktuuritiimi globaalia tilaa.
- Yleensä työkalut ovat erittäin kevyitä.
- Yhdessä työkalujen, kuten operaattorin, kanssa , salaisuudet voidaan tallentaa salattuna Git-tietovarastoon ja hakea klusterin sisällä.
- CD-putkiin ei ole yhteyttä, koska käyttöönotto tapahtuu klusterin sisällä.
Miinukset:
- Käyttöönottosalaisuuksien hallinta Helm-kaavioista on vaikeampaa kuin tavallisista, koska ne on ensin luotava esimerkiksi sinetöityjen salaisuuksien muodossa, minkä jälkeen ne on purettava sisäisen operaattorin toimesta ja vasta sen jälkeen ne tulevat vetotyökalun saataville. Sitten voit suorittaa julkaisun Helmissa jo käyttöönotettujen salaisuuksien arvoilla. Helpoin tapa on luoda salaisuus kaikilla käyttöönotossa käytetyillä Helm-arvoilla, purkaa salaus ja sitoa se Gitiin.
- Kun otat veto-lähestymistavan, sinut sidotaan vetotyökaluihin. Tämä rajoittaa kykyä mukauttaa käyttöönottoprosessia klusterissa. Esimerkiksi Kustomizea vaikeuttaa se tosiasia, että sen on suoritettava ennen kuin lopulliset mallit sitoutuvat Gitiin. En sano, että et voi käyttää itsenäisiä työkaluja, mutta niitä on vaikeampi integroida käyttöönottoprosessiisi.
Työntöpohjainen lähestymistapa
Push-lähestymistavassa ulkoinen järjestelmä (lähinnä CD-liukuhihnat) käynnistää käyttöönotot klusteriin Git-tietovarastoon sitoutumisen jälkeen tai jos edellinen CI-liukuhihna on onnistunut. Tässä lähestymistavassa järjestelmällä on pääsy klusteriin.
Pros:
- Suojaus määräytyy Git-tietovaraston ja rakennusprosessin perusteella.
- Helm-kaavioiden käyttöönotto on helpompaa ja tukee Helm-laajennuksia.
- Salaisuuksia on helpompi hallita, koska salaisuuksia voidaan käyttää putkissa ja ne voidaan myös tallentaa salattuna Gitiin (riippuen käyttäjän mieltymyksistä).
- Ei yhteyttä tiettyyn työkaluun, koska voidaan käyttää mitä tahansa tyyppiä.
- Säilön versiopäivitykset voidaan käynnistää koontiprosessissa.
Miinukset:
- Klusterin käyttötiedot ovat rakennusjärjestelmän sisällä.
- Käyttöönottosäiliöiden päivittäminen on edelleen helpompaa vetoprosessin avulla.
- Voimakas riippuvuus CD-järjestelmästä, koska tarvitsemamme putkistot on saatettu olla alun perin kirjoitettu Gitlab Runnersille, ja sitten tiimi päättää siirtyä Azure DevOpsiin tai Jenkinsiin... ja sen on siirrettävä suuri määrä rakennusputkia.
Tulokset: työnnä vai vedä?
Kuten yleensä, jokaisella lähestymistavalla on hyvät ja huonot puolensa. Jotkut tehtävät on helpompi suorittaa yhdellä ja vaikeampia toisella. Aluksi tein käyttöönotot manuaalisesti, mutta kun törmäsin muutamaan Weave Fluxia käsittelevään artikkeliin, päätin ottaa GitOps-prosessit käyttöön kaikkiin projekteihin. Perusmalleille tämä oli helppoa, mutta sitten aloin törmätä vaikeuksiin Helm-kaavioiden kanssa. Tuolloin Weave Flux tarjosi vain alkeellista versiota Helm Chart Operatorista, mutta nykyäänkin jotkut tehtävät ovat vaikeampia, koska salaisuudet on luotava ja käytettävä manuaalisesti. Voit väittää, että vetomenetelmä on paljon turvallisempi, koska klusterin tunnistetiedot eivät ole käytettävissä klusterin ulkopuolella, mikä tekee siitä niin paljon turvallisemman, että se on ylimääräisen vaivan arvoista.
Hetken pohdinnan jälkeen tulin odottamattomaan johtopäätökseen, että näin ei ole. Jos puhumme komponenteista, jotka vaativat maksimaalista suojausta, tämä luettelo sisältää salaisen tallennustilan, CI/CD-järjestelmät ja Git-arkistot. Niiden sisällä oleva tieto on erittäin haavoittuvaa ja tarvitsee maksimaalista suojaa. Lisäksi, jos joku pääsee Git-tietovarastoon ja voi työntää sinne koodia, hän voi ottaa käyttöön mitä haluaa (joko vetoa tai työntöä) ja soluttautua klusterin järjestelmiin. Näin ollen tärkeimmät suojattavat komponentit ovat Git-arkisto ja CI/CD-järjestelmät, eivät klusterin tunnistetiedot. Jos sinulla on hyvin konfiguroidut käytännöt ja suojaustoiminnot tämän tyyppisille järjestelmille ja klusterin tunnistetiedot puretaan vain salaisuuksina, vetomenetelmän lisätty tietoturva ei välttämättä ole niin arvokasta kuin alun perin luuli.
Joten jos veto-lähestymistapa on työvoimavaltaisempaa eikä tuota turvallisuusetua, eikö ole loogista käyttää vain push-lähestymistapaa? Mutta joku saattaa väittää, että push-lähestymistavassa olet liian sidottu CD-järjestelmään, ja ehkä on parempi olla tekemättä tätä, jotta siirtyminen on helpompaa tulevaisuudessa.
Mielestäni (kuten aina) sinun tulisi käyttää sitä, mikä sopii parhaiten tiettyyn tapaukseen tai yhdistelmään. Henkilökohtaisesti käytän molempia lähestymistapoja: Weave Fluxia vetopohjaisiin käyttöönotuksiin, jotka sisältävät enimmäkseen omia palvelujamme, ja push-lähestymistapaa Helmin ja lisäosien kanssa, mikä helpottaa Helm-kaavioiden soveltamista klusteriin ja mahdollistaa salaisuuksien luomisen saumattomasti. Mielestäni ei koskaan tule olemaan yhtä ainoaa kaikkiin tapauksiin sopivaa ratkaisua, koska vivahteita on aina paljon ja ne riippuvat tietystä sovelluksesta. Tästä huolimatta suosittelen GitOpsia - se tekee elämästä paljon helpompaa ja parantaa turvallisuutta.
Toivon, että kokemukseni tästä aiheesta auttaa sinua päättämään, mikä menetelmä sopii paremmin sinun käyttöön, ja kuulisin mielelläni mielipiteesi.
PS Kääntäjän huomautus
Pullomallin haittapuoli on, että on vaikea laittaa renderöityjä manifesteja Gitiin, mutta ei ole haittaa, että pull-mallin CD-liukuhihna elää erillään julkaisusta ja siitä tulee olennaisesti luokkaputki. Jatkuva soveltaminen. Siksi tarvitaan vielä enemmän ponnisteluja niiden tilan keräämiseksi kaikista käyttöönotuksista ja jollakin tavalla pääsyn antamiseen lokeihin/tiloihin, mieluiten CD-järjestelmään viitaten.
Tässä mielessä työntömalli antaa meille mahdollisuuden tarjota ainakin joitain takeita käyttöönotosta, koska putkilinjan käyttöikä voidaan tehdä yhtä suureksi kuin käyttöönoton käyttöikä.
Kokeilimme molempia malleja ja tulimme samoihin johtopäätöksiin kuin artikkelin kirjoittaja:
- Vetomalli sopii meille useiden klustereiden järjestelmäkomponenttien päivityksen järjestämiseen (katso. ).
- GitLab CI:hen perustuva push-malli soveltuu hyvin Helm-kaavioita käyttävien sovellusten käyttöönottoon. Samanaikaisesti työkalun avulla seurataan käyttöönottojen käyttöönottoa putkien sisällä . Muuten, tämän projektimme yhteydessä kuulimme jatkuvan "GitOps"-äänen, kun keskustelimme DevOps-insinöörien kiireellisistä ongelmista osastollamme KubeCon Europe'19:ssä.
PPS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Käytätkö GitOpsia?
-
Kyllä, vedä lähestymistapa
-
Kyllä, työnnä
-
Kyllä, vedä + työnnä
-
Kyllä, jotain muuta
-
Ei
30 käyttäjää äänesti. 10 käyttäjää pidättyi äänestämästä.
Lähde: will.com