🥇Kolmisuuntainen yhdistäminen Werfiin: käyttöönotto Kubernetesiin Helmin kanssa "steroideilla"

Se, mitä me (ja emme vain me) olemme odottaneet pitkään, on tapahtunut: werf, avoimen lähdekoodin apuohjelmamme sovellusten rakentamiseen ja Kubernetesiin toimittamiseen, tukee nyt muutosten käyttöönottoa kolmisuuntaisten yhdistämispäivitysten avulla! Lisäksi nyt on mahdollista ottaa käyttöön olemassa olevia K8s-resursseja Helm-julkaisuissa ilman, että niitä tarvitsee luoda uudelleen.

Lyhyesti sanottuna, laitoimme WERF_THREE_WAY_MERGE=enabled — saamme käyttöönoton ”kuten kohdassa kubectl apply", yhteensopiva olemassa olevien Helm 2 -asennusten kanssa ja jopa hieman enemmän.

Mutta aloitetaan teoriasta: mitä ovat 3-way-merge-korjaukset, miten ihmiset keksivät lähestymistavan niiden luomiseen ja miksi ne ovat tärkeitä CI/CD-prosesseissa Kubernetes-pohjaisessa infrastruktuurissa? Sen jälkeen tarkastelemme, mitä 3-way-merge oikeastaan on WERF:ssä, mitä tiloja käytetään oletusarvoisesti ja miten sitä hallitaan.

Mikä on 3-tieinen yhdistämispatch?

Aloitetaan siis YAML-manifesteissa kuvattujen resurssien käyttöönotolla Kubernetesiin.

Kubernetes-rajapinta tarjoaa seuraavat perustoiminnot resurssien käsittelyyn: luonti, korjaus, korvaus ja poisto. Näiden tarkoituksena on rakentaa kätevä ja jatkuva resurssien käyttöönotto klusterissa. Miten?

Välttämättömät kubectl-komennot

Ensimmäinen tapa hallita objekteja Kubernetesissa on käyttää välttämättömiä kubectl-komentoja näiden objektien luomiseen, muokkaamiseen ja poistamiseen. Yksinkertaisesti sanottuna:

joukkue kubectl run Voit suorittaa käyttöönoton tai työn:

kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

joukkue kubectl scale — muuta kopioiden määrää:
```
kubectl scale --replicas=3 deployment/mysql
```
jne.

Tämä lähestymistapa saattaa vaikuttaa ensi silmäyksellä kätevältä. Siihen liittyy kuitenkin ongelmia:

Se on hänelle vaikeaa automatisoida.
miten heijastaa konfiguraatiota Gitissä? Miten voin tarkastella klusteriin tehtyjä muutoksia?
Kuinka varmistaa toistettavuus asetukset uudelleenkäynnistyksen yhteydessä?
...

On selvää, että tämä lähestymistapa ei sovi hyvin yhteen sovelluskoodin ja infrastruktuurin tallentamisen kanssa koodina (IaC; tai edes GitOps (nykyaikaisempana vaihtoehtona, joka on kasvattanut suosiotaan Kubernetes-ekosysteemissä). Siksi näitä kubectl-komentoja ei ole kehitetty pidemmälle.

Luonti-, haku-, korvaus- ja poistotoiminnot

Ensisijaisen kanssa luominen Se on yksinkertaista: lähetämme manifestin operaatiolle create Kube-rajapinta ja resurssi luodaan. Manifestin YAML-esitys voidaan tallentaa Gitiin, ja sen luomiseen käytetään komentoa kubectl create -f manifest.yaml.

С poistaminen se on myös yksinkertaista: korvaamme saman manifest.yaml Gitistä tiimiin kubectl delete -f manifest.yaml.

Toiminta replace Mahdollistaa resurssin kokoonpanon täydellisen korvaamisen uudella ilman resurssin uudelleenluomista. Tämä tarkoittaa, että ennen resurssiin tehtäviä muutoksia on loogista pyytää nykyistä versiota toiminnolla. get, muuta sitä ja päivitä se toiminnolla replaceKubessa on sisäänrakennettu apiserver. optimistinen lukitus ja jos leikkauksen jälkeen get objekti on muuttunut, niin toiminto replace se ei toimi.

Tallentaaksesi kokoonpanon Gitiin ja päivittääksesi sen replace-komennolla, sinun on suoritettava seuraava toiminto get, yhdistä Gitistä saadut asetukset saamiimme ja suorita replaceOletusarvoisesti kubectl sallii vain komennon käytön kubectl replace -f manifest.yamlMissä manifest.yaml — täysin valmisteltu (tässä tapauksessa yhdistetty) manifesti, joka on asennettava. Tämä tarkoittaa, että käyttäjän on yhdistettävä manifestit, mikä ei ole triviaali asia…

On myös syytä huomata, että vaikka manifest.yaml ja se on tallennettu Gitiin, emme voi etukäteen tietää, onko objekti luotava tai päivitettävä – tämä on tehtävä käyttäjän ohjelmistolla.

Yhteensä: Voimmeko rakentaa jatkuvan käyttöönoton? käyttäen vain luonti-, korvaus- ja poistokomentoja varmistaen, että infrastruktuurikokoonpano tallennetaan Gitiin yhdessä koodin ja kätevän CI/CD:n kanssa?

Periaatteessa voimme... Tätä varten yhdistämisoperaatio on tarpeen toteuttaa manifestit ja jonkinlainen sidonta, joka:

tarkistaa objektin läsnäolon klusterissa,
suorittaa resurssin alkuperäisen luomisen,
päivittää tai poistaa sen.

Päivittäessäsi muista, että resurssi on saattanut muuttua viimeisestä lähtien get ja käsittelee automaattisesti optimistisen lukituksen tapauksen - yritä päivittää toistuvasti.

Miksi kuitenkin keksiä pyörää uudelleen, kun kube-apiserver tarjoaa toisen tavan päivittää resursseja: operaation patch, mikä vapauttaa käyttäjän joistakin kuvatuista ongelmista?

läikkä

Eli vihdoin olemme päässeet laastarien luo.

Korjaukset ovat ensisijainen tapa tehdä muutoksia olemassa oleviin objekteihin Kubernetesissa. patch toimii siten, että:

Kube-apiserver-käyttäjän on lähetettävä korjaustiedosto JSON-muodossa ja määritettävä objekti,
ja itse apiserver käsittelee objektin nykyisen tilan ja saattaa sen vaadittuun muotoon.

Optimistista lukitusta ei tässä tapauksessa tarvita. Tämä operaatio on enemmän deklaratiivinen kuin korvaava, vaikka se saattaa aluksi vaikuttaa päinvastaiselta.

Näin:

leikkauksen avulla create luomme objektin Gitin manifestin perusteella,
kautta delete - poistaa, jos kohdetta ei enää tarvita,
kautta patch — muutamme objektia ja saatamme sen Gitissä kuvattuun muotoon.

Tämän tekemiseksi sinun on kuitenkin luotava oikea laastari!

Kuinka korjaustiedostot toimivat Helm 2:ssa: 2-suuntaiset yhdistämiset

Kun asennat julkaisun ensimmäisen kerran, Helm suorittaa toiminnon create kaavioresursseja varten.

Kun päivität kunkin resurssin Helm-julkaisua:

laskee korjaustiedoston edellisen kaavion resurssiversion ja kaavion nykyisen version välillä,
käyttää tätä korjaustiedostoa.

Kutsumme tällaista laastaria 2-suuntainen yhdistämispaikkaus, koska sen luomiseen liittyy kaksi manifestia:

resurssiluettelo edellisestä julkaisusta,
resurssin luettelo nykyisestä resurssista.

Kun poistat toiminnon delete Kubessa apiserver-funktiota kutsutaan resursseille, jotka on ilmoitettu edellisessä julkaisussa, mutta joita ei ole ilmoitettu nykyisessä.

Kaksisuuntaisella yhdistämispaikalla on ongelma: se johtaa klusterin resurssin todellisen tilan ja Git-manifestin desynkronointi.

Ongelman havainnollistaminen esimerkillä

Gitissä kaavio tallentaa manifestin, jossa kenttä image Käyttöönotolla on arvoa ubuntu:18.04.
Käyttäjä kautta kubectl edit muutti tämän kentän arvon muotoon ubuntu:19.04.
Helm-kaavion uudelleenkäyttöönotto ei luo korjaustiedostoa, koska kenttä image julkaisun edellisessä versiossa ja nykyisessä kaaviossa ovat samat.
Uudelleensijoittamisen jälkeen image jäännökset ubuntu:19.04vaikka kaavassa lukeekin ubuntu:18.04.

Me menetimme synkronoinnin ja julistautumiskyvyn.

Mikä on synkronoitu resurssi?

Yleisesti ottaen, täydellinen On mahdotonta saada vastaavuutta käynnissä olevan klusterin resurssimanifestin ja Gitistä saadun manifestin välillä. Tämä johtuu siitä, että todellinen manifesti voi sisältää palvelumerkintöjä/tunnisteita, lisäkontteja ja muuta dataa, jota jotkin ohjaimet ovat dynaamisesti lisänneet ja poistaneet resurssista. Emme voi emmekä halua tallentaa tätä dataa Gitiin. Haluamme kuitenkin, että Gitissä nimenomaisesti määritellyillä kentillä on oikeat arvot käyttöönoton aikana.

Se osoittautuu niin yleiseksi synkronoitu resurssisääntöResurssia käyttöönotettaessa voit muuttaa tai poistaa vain niitä kenttiä, jotka on nimenomaisesti määritetty Git-manifestissa (tai jotka määritettiin edellisessä versiossa ja jotka on nyt poistettu).

3-suuntainen yhdistämispaikkaus

keskeinen ajatus 3-suuntainen yhdistämispaikkaus: Luo korjaustiedosto viimeksi käytetyn Git-manifestin version ja kohdeversion välille ottaen huomioon käynnissä olevan klusterin manifestin nykyisen version. Tuloksena olevan korjaustiedoston on oltava synkronoitujen resurssien säännön mukainen:

kohdeversioon lisätyt uudet kentät lisätään korjauspäivityksen kautta;
viimeksi käytetyssä versiossa aiemmin olleet kentät ja kohdeversiossa puuttuvat kentät nollataan korjauspäivityksen avulla;
Objektin nykyisen version kentät, jotka eroavat manifestin kohdeversiosta, päivitetään korjaustiedoston avulla.

Tämä on periaate, jolla paikkaukset generoidaan. kubectl apply:

manifestin viimeksi käytetty versio tallennetaan itse objektin annotaatioon,
kohde - otetaan määritetystä YAML-tiedostosta,
nykyinen - käynnissä olevasta klusterista.

Nyt kun olemme käyneet teorian läpi, on aika kertoa, mitä teimme werfissä.

Muutosten tekeminen werf-arvoon

Aiemmin Werf, kuten Helm 2, käytti kaksisuuntaisia yhdistämispäivityksiä.

Korjauskorjaus

Siirtyäksemme uudenlaisiin patch-tyyppeihin – 3-way-merge-tekniikkaan – ensimmäinen askel oli ns. korjauspaikat.

Käyttöönotossa käytetään standardia kaksisuuntaista yhdistämistä koskevaa korjauspäivitystä, mutta werf luo lisäksi korjauspäivityksen, joka synkronoi resurssin todellisen tilan Gitissä kirjoitetun kanssa (tämä korjauspäivitys luodaan käyttämällä samaa yllä kuvattua synkronoitujen resurssien sääntöä).

Jos synkronointi katkeaa käyttöönoton lopussa, käyttäjä saa VAROITUSviestin, joka sisältää vastaavan viestin ja korjauspäivityksen, joka on asennettava resurssin palauttamiseksi synkronointiin. Tämä korjauspäivitys kirjoitetaan myös erityiseen annotaatioon. werf.io/repair-patchOletetaan, että käyttäjä käyttää käsiään itse asentaa tämän päivityksen: werf ei periaatteesta asenna sitä.

Korjauspäivitysten luominen on väliaikainen toimenpide, jonka avulla voit testata kolmisuuntaisen yhdistämisen korjauspäivitysten luontiprosessia, mutta se ei automaattisesti ota näitä korjauspäivityksiä käyttöön. Tämä tila on tällä hetkellä oletusarvoisesti käytössä.

3-suuntainen yhdistämispäivitys vain uusille julkaisuille

Werfin beta- ja alfa-versiot tulevat saataville 1. joulukuuta 2019 alkaen. oletuksena Käytä täysiä kolmisuuntaisia yhdistämiskorjauksia, jos haluat tehdä muutoksia vain uusiin Werf-komennon kautta käyttöönotettuihin Helm-julkaisuihin. Aiemmin julkaistuissa julkaisuissa käytetään edelleen kaksisuuntaista yhdistämistä ja korjauskorjausta.

Tämä toimintatila voidaan ottaa käyttöön erikseen asettamalla WERF_THREE_WAY_MERGE_MODE=onlyNewReleases nyt.

Huomata: ominaisuus esiintyi Werfissä useissa julkaisuissa: alfakanavassa se valmistui versiolla v1.0.5-alpha.19ja beetakanavassa - kanssa v1.0.4-beta.20.

3-suuntainen yhdistämispaikkaus kaikille julkaisuille

15. joulukuuta 2019 alkaen Werf-beta- ja alfaversiot käyttävät oletuksena täydellisiä kolmisuuntaisia yhdistämispäivityksiä muutosten käyttöönottoon kaikissa julkaisuissa.

Tämä toimintatila voidaan ottaa käyttöön erikseen asettamalla WERF_THREE_WAY_MERGE_MODE=enabled nyt.

Miten resurssien automaattisen skaalauksen kanssa toimitaan?

Kubernetesissa on kahdenlaisia automaattisia skaalauksia: HPA (vaakasuora) ja VPA (vertikaalinen).

Vaakasuuntainen valitsee automaattisesti replikoiden määrän, kun taas pystysuuntainen valitsee resurssien määrän. Sekä replikoiden määrä että resurssivaatimukset määritetään resurssiluettelossa (katso spec.replicas tai spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и muut).

Ongelma: Jos käyttäjä määrittää kaaviossa olevan resurssin niin, että se määrittää resursseille tai replikoille tietyt arvot, ja automaattiset skaalaimet on otettu käyttöön tälle resurssille, Werf palauttaa nämä arvot jokaisen käyttöönoton yhteydessä kaavion manifestissa kirjoitetuiksi.

Tähän ongelmaan on kaksi ratkaisua. Paras tapa aloittaa on välttää automaattisen skaalauksen arvojen määrittämistä erikseen kaavion manifestissa. Jos tämä vaihtoehto ei jostain syystä sovi (esimerkiksi siksi, että on kätevää määrittää alkuperäiset resurssien rajat ja kaaviossa olevien replikoiden määrä), werf tarjoaa seuraavat merkinnät:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Tämän merkinnän avulla werf ei nollaa vastaavia arvoja jokaisella käyttöönotolla, vaan asettaa ne vasta resurssin luomisen yhteydessä.

Lisätietoja on projektidokumentaatiossa. HPA и VPA.

Poista käytöstä 3-tie-yhdistämispatchin käyttö

Käyttäjä voi tällä hetkellä poistaa uusien korjauspäivitysten käytön käytöstä werfissä ympäristömuuttujalla. WERF_THREE_WAY_MERGE_MODE=disabledKuitenkin aloittaminen Tämä kielto ei ole enää voimassa 1. maaliskuuta 2020 alkaen. ja vain kolmisuuntaisia yhdistämispatcheja on mahdollista käyttää.

Resurssien käyttöönotto Werfissä

Kolmisuuntaisen yhdistämismenetelmän hallinta muutosten soveltamisessa mahdollisti meille sellaisen ominaisuuden välittömän käyttöönoton kuin olemassa olevien klusteriresurssien käyttöönotto Helm-julkaisussa.

Helm 2:ssa on ongelma: et voi lisätä kaavion manifesteihin resurssia, joka on jo olemassa klusterissa, luomatta kyseistä resurssia uudelleen tyhjästä (katso alla). #6031, #3275). Olemme opettaneet Werf-komennon hyväksymään olemassa olevia resursseja julkaisuun. Tätä varten sinun on asennettava annotaatio käynnissä olevan klusterin resurssin nykyiseen versioon (esimerkiksi käyttämällä kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Nyt resurssi on kuvattava kaaviossa, ja kun Werf seuraavan kerran ottaa käyttöön vastaavannimisen julkaisun, olemassa oleva resurssi hyväksytään kyseiseen julkaisuun ja pysyy sen hallinnassa. Lisäksi resurssin julkaisuun hyväksymisprosessin aikana Werf muuntaa resurssin nykyisen tilan käynnissä olevasta klusterista kaaviossa kuvattuun tilaan käyttämällä samoja kolmisuuntaisia yhdistämiskorjauksia ja synkronoitua resurssisääntöä.

Huomata: asetus WERF_THREE_WAY_MERGE_MODE ei vaikuta resurssien käyttöönottoon – käyttöönoton tapauksessa käytetään aina 3-suuntaista yhdistämiskohtaa.

Tiedot ovat kohdassa dokumentointi.

Johtopäätökset ja tulevaisuudensuunnitelmat

Toivottavasti tämä artikkeli on selventänyt, mitä 3-suuntaiset yhdistämispäivitykset ovat ja miksi ne valittiin. Käytännön näkökulmasta Werf-projektin kannalta niiden käyttöönotto on jälleen yksi askel kohti Helm-tyyppisen käyttöönoton parantamista. Helm 2:n kanssa usein ilmenneet konfiguraation synkronointiongelmat voidaan nyt unohtaa. Samalla on lisätty uusi, hyödyllinen ominaisuus: jo käyttöönotettujen Kubernetes-resurssien käyttöönotto Helm-julkaisussa.

Helmin kaltaisessa käyttöönotossa on edelleen joitakin ongelmia ja haasteita, kuten Go-mallien käyttö, ja jatkamme niiden ratkaisemista.

Tietoa resurssien päivitysmenetelmistä ja käyttöönotosta löytyy myös osoitteesta tämä dokumentaatiosivu.

Kypärä 3

Erityismaininnan arvoinen vapautettu Juuri toissapäivänä julkaistiin uusi Helmin pääversio – v3 – joka myös käyttää kolmisuuntaisia yhdistämispäivityksiä ja poistaa Tiller-korjaustiedoston. Uusi Helmin versio vaatii muuttoliike olemassa olevat asennukset muuntaaksesi ne uuden julkaisun tallennusmuotoon.

Werf on puolestaan luopunut Tilleristä, siirtynyt kolmitieyhdistämiseen ja lisännyt paljon enemmän, samalla kun se pysyy yhteensopivana olemassa olevien Helm 2 -asennusten kanssa (siirtoskriptejä ei tarvita). Siksi, kunnes werf vaihtaa Helm 3:een, werf-käyttäjät eivät menetä Helm 3:n keskeisiä etuja Helm 2:een verrattuna (werfillä on myös nämä edut).

Werfin siirtyminen Helm 3 -koodikantaan on kuitenkin väistämätöntä ja tapahtuu lähitulevaisuudessa. Tämä tulee todennäköisesti olemaan Werf 1.1 tai Werf 1.2 (tällä hetkellä Werfin pääversio on 1.0; lisätietoja Werfin versioinnista on osoitteessa täällä). Tänä aikana Helm 3:lla on aikaa vakautua.