Það sem við (en ekki bara við) höfum beðið eftir lengi gerðist: , Opinn uppspretta tól okkar til að byggja forrit og afhenda þau til Kubernetes, styður nú beitingu breytinga með því að nota 3-vega sameiningaplástra! Í viðbót við þetta er hægt að samþykkja núverandi K8s auðlindir í Helm útgáfur án þess að endurbyggja þessar auðlindir.
Ef það er mjög stutt, þá setjum við WERF_THREE_WAY_MERGE=enabled - við fáum dreifingu „eins og í kubectl apply", samhæft við núverandi Helm 2 uppsetningar og jafnvel aðeins meira.
En við skulum byrja á kenningunni: hvað nákvæmlega eru þríhliða sameiningaplástrar, hvernig datt fólki í hug að búa þá til og hvers vegna eru þeir mikilvægir í CI/CD ferlum með Kubernetes-undirstaða innviði? Og eftir það skulum við sjá hvað 3-way-merge er í werf, hvaða stillingar eru notaðar sjálfgefið og hvernig á að stjórna því.
Hvað er 3-way-merge patch?
Svo, við skulum byrja á því verkefni að rúlla út auðlindunum sem lýst er í YAML birtingarmyndum í Kubernetes.
Til að vinna með auðlindir býður Kubernetes API eftirfarandi grunnaðgerðir: búa til, lagfæra, skipta út og eyða. Gert er ráð fyrir að með hjálp þeirra sé nauðsynlegt að byggja upp þægilega samfellda útfærslu á auðlindum til klasans. Hvernig?
kubectl nauðsynlegar skipanir
Fyrsta aðferðin við að stjórna hlutum í Kubernetes er að nota kubectl nauðsynlegar skipanir til að búa til, breyta og eyða þessum hlutum. Einfaldlega sagt:
- teymið
kubectl runþú getur keyrt Deployment eða Job:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - teymið
kubectl scale— breyta fjölda eftirmynda:kubectl scale --replicas=3 deployment/mysql - o.fl.
Þessi aðferð kann að virðast þægileg við fyrstu sýn. Hins vegar eru vandamál:
- Það er erfitt gera sjálfvirkan.
- Как endurspegla uppsetningu í Git? Hvernig á að endurskoða breytingar sem verða á klasanum?
- Hvernig á að veita endurgerðanleika stillingar við endurræsingu?
- ...
Það er ljóst að þessi nálgun passar ekki vel við að geyma forrit og innviði sem kóða (IaC; eða jafnvel sem nútímalegri valkostur, sem nýtur vinsælda í Kubernetes vistkerfinu). Þess vegna fengu þessar skipanir ekki frekari þróun í kubectl.
Búa til, fá, skipta út og eyða aðgerðum
Með prófkjöri sköpun það er einfalt: sendu upplýsingaskrána í aðgerðina create kube api og tilfangið hefur verið búið til. YAML framsetningu upplýsingaskrárinnar er hægt að geyma í Git og búa til með skipuninni kubectl create -f manifest.yaml.
С fjarlægja líka einfalt: komdu í staðinn fyrir það sama manifest.yaml frá Git til liðs kubectl delete -f manifest.yaml.
Operation replace gerir þér kleift að skipta algjörlega um auðlindastillingu fyrir nýja án þess að endurskapa auðlindina. Þetta þýðir að áður en breyting er gerð á tilfangi er rökrétt að spyrjast fyrir um núverandi útgáfu með aðgerðinni get, breyttu því og uppfærðu það með aðgerðinni replace. kube apiserver er innbyggður og ef eftir aðgerð get hluturinn hefur breyst, síðan aðgerðin replace það mun ekki virka.
Til að geyma stillingarnar í Git og uppfæra hana með því að nota replace þarftu að gera aðgerðina get, sameina stillinguna frá Git við það sem við fengum og keyra replace. Sjálfgefið leyfir kubectl þér aðeins að nota skipunina kubectl replace -f manifest.yamlhvar manifest.yaml — þegar fullbúið (í okkar tilfelli, sameinað) upplýsingaskrá sem þarf að setja upp. Það kemur í ljós að notandinn þarf að innleiða samrunaskrár og þetta er ekkert smáræði...
Það er líka rétt að taka fram að þó manifest.yaml og er geymt í Git, getum við ekki vitað fyrirfram hvort nauðsynlegt sé að búa til hlut eða uppfæra hann - það verður að gera með notendahugbúnaði.
Samtals: getum við byggt upp samfellda útsetningu aðeins með því að nota búa til, skipta út og eyða, til að tryggja að innviðastillingar séu geymdar í Git ásamt kóðanum og þægilegum CI/CD?
Í grundvallaratriðum getum við... Fyrir þetta þú þarft að innleiða samrunaaðgerðina stefnuskrár og einhvers konar binding sem:
- athugar tilvist hlutar í þyrpingunni,
- framkvæmir fyrstu auðlindasköpun,
- uppfærir eða eyðir því.
Vinsamlegast hafðu í huga þegar þú uppfærir auðlind gæti hafa breyst síðan síðast get og sjáum sjálfkrafa um bjartsýnislæsingu - gerðu endurteknar uppfærslutilraunir.
Hins vegar, hvers vegna finna upp hjólið aftur þegar kube-apiserver býður upp á aðra leið til að uppfæra auðlindir: aðgerðina patch, sem losar notandann við sum af þeim vandamálum sem lýst er?
Patch
Nú komum við að plástrunum.
Plástrar eru aðal leiðin til að beita breytingum á fyrirliggjandi hluti í Kubernetes. Aðgerð patch þetta virkar svona:
- kube-apiserver notandinn þarf að senda plástur á JSON formi og tilgreina hlutinn,
- og apiserver sjálft mun takast á við núverandi ástand hlutarins og koma því í tilskilið form.
Ekki er þörf á bjartsýni læsingu í þessu tilfelli. Þessi aðgerð er meira yfirlýsandi en að koma í staðinn, þó að í fyrstu virðist það á hinn veginn.
Á þennan hátt:
- með aðgerð
createvið búum til hlut samkvæmt manifestinu frá Git, - með hjálpinni
delete— eyða ef ekki er lengur þörf á hlutnum, - með hjálpinni
patch— við breytum hlutnum, færum hann í það form sem lýst er í Git.
Hins vegar, til að gera þetta, þarftu að búa til réttur plástur!
Hvernig plástrar virka í Helm 2: 2-way-merge
Þegar þú setur upp útgáfu fyrst framkvæmir Helm aðgerðina create fyrir kortaauðlindir.
Þegar þú uppfærir Helm útgáfu fyrir hvert tilfang:
- lítur á plásturinn á milli auðlindaútgáfunnar frá fyrri töflunni og núverandi töfluútgáfu,
- notar þennan plástur.
Við munum kalla þetta plástur Tvíhliða samrunaplástur, vegna þess að 2 stefnuskrár taka þátt í gerð þess:
- auðlindaskrá frá fyrri útgáfu,
- auðlindaskrá frá núverandi auðlind.
Þegar aðgerð er fjarlægð delete í kube apiserver er kallað eftir tilföngum sem lýst var yfir í fyrri útgáfu, en ekki lýst yfir í þeirri núverandi.
The 2 way merge patch nálgun hefur vandamál: það leiðir til ekki í takt við raunverulegt ástand auðlindarinnar í þyrpingunni og birtingarmyndina í Git.
Skýring á vandamálinu með dæmi
- Í Git geymir kort upplýsingaskrá þar sem reiturinn
imageDreifing skiptir máliubuntu:18.04. - Notandi í gegnum
kubectl editbreytt gildi þessa reits íubuntu:19.04. - Þegar stýrikortið er dreift aftur býr ekki til plástur, því sviðið
imageí fyrri útgáfu útgáfunnar og í núverandi myndriti eru þau sömu. - Eftir endurdreifingu
imagestendur eftirubuntu:19.04, þó að grafið segiubuntu:18.04.
Við fengum samstillingu og misstum yfirlýsingu.
Hvað er samstillt auðlind?
Almennt séð fullur Það er ómögulegt að fá samsvörun á milli auðlindaskrárinnar í keyrandi klasa og upplýsingaskrárinnar frá Git. Vegna þess að í raunverulegri upplýsingaskrá geta verið þjónustuskýringar/merkimiðar, viðbótarílát og önnur gögn sem eru bætt við og fjarlægð úr auðlindinni á kraftmikinn hátt af sumum stjórnendum. Við getum ekki og viljum ekki geyma þessi gögn í Git. Hins vegar viljum við að reitirnir sem við tilgreindum sérstaklega í Git taki á sig viðeigandi gildi við útsetningu.
Það kemur svo almennt í ljós samstillt auðlindareglu: þegar þú setur út tilföng geturðu breytt eða eytt aðeins þeim reitum sem eru sérstaklega tilgreindir í upplýsingaskránni frá Git (eða voru tilgreindir í fyrri útgáfu og er nú eytt).
Tvíhliða samrunaplástur
Helstu hugmyndin : við búum til plástur á milli síðustu útgáfu upplýsingaskrárinnar frá Git og markútgáfunnar af upplýsingaskránni frá Git, að teknu tilliti til núverandi útgáfu upplýsingaskrárinnar frá keyrandi þyrpingunni. Plásturinn sem myndast verður að vera í samræmi við samstilltu auðlindaregluna:
- nýjum reitum sem bætt er við markútgáfuna er bætt við með plástri;
- áður fyrirliggjandi reitir í síðustu beittu útgáfunni og ekki til í markútgáfunni eru endurstilltir með plástri;
- reitir í núverandi útgáfu af hlutnum sem eru frábrugðnir markútgáfu upplýsingaskránnar eru uppfærðir með plástrinum.
Það er á þessari reglu sem það býr til plástra kubectl apply:
- síðasta notaða útgáfan af upplýsingaskránni er geymd í skýringunni á hlutnum sjálfum,
- target - tekið úr tilgreindri YAML skrá,
- sú núverandi er úr hlaupandi klasa.
Nú þegar við höfum reddað kenningunni er kominn tími til að segja þér hvað við gerðum í werf.
Að beita breytingum á werf
Áður notaði werf, eins og Helm 2, tvíhliða samruna plástra.
Viðgerð plástur
Til þess að skipta yfir í nýja tegund plástra - 3-way-merge - kynntum við fyrsta skrefið s.k. gera við plástra.
Við uppsetningu er venjulegur 2-vega sameiningaplástur notaður, en werf býr til viðbótar plástur sem myndi samstilla raunverulegt ástand auðlindarinnar við það sem er skrifað í Git (slíkur plástur er búinn til með sömu samstilltu auðlindareglu sem lýst er hér að ofan) .
Ef afsamstilling á sér stað, í lok dreifingarinnar fær notandinn VIÐVÖRUN með samsvarandi skilaboðum og plástri sem þarf að nota til að koma auðlindinni á samstillt form. Þessi plástur er einnig skráður í sérstakri athugasemd werf.io/repair-patch. Gert er ráð fyrir að hendur notanda sjálfur mun nota þennan plástur: werf mun alls ekki nota hann.
Að búa til viðgerðarplástra er tímabundin ráðstöfun sem gerir þér kleift að prófa sköpun plástra byggða á 3-vega samrunareglunni, en ekki beita þessum plástra sjálfkrafa. Í augnablikinu er þessi rekstrarhamur virkur sjálfgefið.
3-way-merge plástur aðeins fyrir nýjar útgáfur
Frá og með 1. desember 2019 byrja beta- og alfaútgáfur af werf sjálfgefið notaðu fullgilda 3-vega samruna plástra til að beita breytingum aðeins á nýjar Helm útgáfur sem eru rúllaðar út í gegnum werf. Núverandi útgáfur munu halda áfram að nota 2-vega-samruna + viðgerðarplástra nálgunina.
Hægt er að virkja þessa aðgerðaham sérstaklega með því að stilla WERF_THREE_WAY_MERGE_MODE=onlyNewReleases núna.
Athugið: Eiginleikinn birtist í werf í nokkrum útgáfum: í alfarásinni varð hann tilbúinn með útgáfu , og í beta rásinni - með .
3-vega sameina plástur fyrir allar útgáfur
Frá og með 15. desember 2019 byrja beta- og alfaútgáfur af werf sjálfgefið að nota fulla 3-vega samruna plástra til að beita breytingum á allar útgáfur.
Hægt er að virkja þessa aðgerðaham sérstaklega með því að stilla WERF_THREE_WAY_MERGE_MODE=enabled núna.
Hvað á að gera við sjálfvirka mælikvarða auðlinda?
Það eru 2 gerðir af sjálfstýringu í Kubernetes: HPA (lárétt) og VPA (lóðrétt).
Lárétt velur sjálfkrafa fjölda eftirmynda, lóðrétt - fjölda auðlinda. Bæði fjöldi eftirmynda og tilfangaþörf er tilgreind í tilfangaskránni (sjá Tilfangalýsing). spec.replicas eða spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
Vandamál: ef notandi stillir tilföng í myndriti þannig að það tilgreini ákveðin gildi fyrir tilföng eða eftirlíkingar og sjálfvirkar mælingar eru virkjaðar fyrir þetta tilfang, þá mun werf endurstilla þessi gildi í það sem er skrifað í kortaskránni með hverri uppsetningu .
Það eru tvær lausnir á vandanum. Til að byrja með er best að forðast að tilgreina sjálfvirkt stærðargildi sérstaklega í töflunni. Ef þessi valkostur hentar ekki af einhverjum ástæðum (t.d. vegna þess að það er þægilegt að setja upphafsmörk og fjölda eftirmynda á töflunni), þá býður werf eftirfarandi athugasemdir:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Ef slík athugasemd er til staðar mun werf ekki endurstilla samsvarandi gildi á hverri dreifingu, heldur aðeins stilla þau þegar tilfangið er upphaflega búið til.
Fyrir frekari upplýsingar, sjá verkefnisskjöl fyrir и .
Banna notkun 3-vega samruna plásturs
Notandinn getur sem stendur bannað notkun nýrra plástra í werf með því að nota umhverfisbreytu WERF_THREE_WAY_MERGE_MODE=disabled. Hins vegar að byrja Frá 1. mars 2020 mun þetta bann ekki lengur gilda. og það verður aðeins hægt að nota 3-way-merge plástra.
Samþykkt auðlinda í werf
Að ná tökum á aðferðinni við að beita breytingum með 3-vega sameiningu plástra gerði okkur kleift að innleiða slíkan eiginleika strax eins og að samþykkja auðlindir sem eru til í þyrpingunni í Helm útgáfuna.
Hjálmur 2 á við vandamál að etja: þú getur ekki bætt tilföngum við kortaskrá sem þegar er til í þyrpingunni án þess að endurskapa þetta tilfang frá grunni (sjá. , ). Við kenndum werf að samþykkja núverandi úrræði til útgáfu. Til að gera þetta þarftu að setja upp athugasemd á núverandi útgáfu af auðlindinni úr keyrandi klasanum (til dæmis með því að nota kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMENú þarf að lýsa auðlindinni á töflunni og næst þegar werf setur útgáfu með viðeigandi nafni verður núverandi auðlind samþykkt í þessa útgáfu og verður áfram undir stjórn hennar. Þar að auki, í því ferli að samþykkja tilföng til útgáfu, mun werf færa núverandi ástand tilfangsins frá keyrandi þyrpingunni í það ástand sem lýst er í töflunni, með því að nota sömu 3-átta sameiningu plástra og samstilltu auðlindaregluna.
Athugið: stilling WERF_THREE_WAY_MERGE_MODE hefur ekki áhrif á upptöku auðlinda - ef um ættleiðingu er að ræða er alltaf notaður 3-vega sameiningaplástur.
Upplýsingar - inn .
Niðurstöður og framtíðarplön
Ég vona að eftir þessa grein hafi það orðið skýrara hvað 3-way-merge plástrar eru og hvers vegna þeir komu til þeirra. Frá hagnýtu sjónarhorni þróunar werf verkefnisins var framkvæmd þeirra enn eitt skrefið í átt að því að bæta dreifinguna eins og Helm. Nú geturðu gleymt vandamálunum með samstillingu stillingar, sem oft komu upp þegar Helm 2 var notað. Á sama tíma var nýr gagnlegur eiginleiki við að taka upp Kubernetes auðlindir sem þegar hefur verið hlaðið niður bætt við Helm útgáfuna.
Það eru enn nokkur vandamál og áskoranir með Helm-líka dreifingu, eins og notkun Go sniðmáta, sem við munum halda áfram að takast á við.
Upplýsingar um uppfærsluaðferðir og upptöku tilfanga má einnig finna á .
Hjálmur 3
Vert að athuga sérstaklega um daginn ný aðalútgáfa af Helm - v3 - sem notar líka 3-way-merge plástra og losar sig við Tiller. Nýja útgáfan af Helm krefst núverandi uppsetningar til að breyta þeim í nýja útgáfu geymslusniðið.
Werf, fyrir sitt leyti, hefur nú losnað við að nota Tiller, skipt yfir í 3-way-merge og bætt við , á meðan það er áfram samhæft við núverandi Helm 2 uppsetningar (ekki þarf að keyra flutningsforskriftir). Þess vegna, þar til werf skiptir yfir í Helm 3, missa werf notendur ekki helstu kostum Helm 3 umfram Helm 2 (werf hefur þá líka).
Hins vegar er óhjákvæmilegt að skipta um werf yfir í Helm 3 kóðagrunninn og mun gerast í náinni framtíð. Væntanlega verður þetta werf 1.1 eða werf 1.2 (sem stendur er aðalútgáfan af werf 1.0; fyrir frekari upplýsingar um werf útgáfubúnaðinn, sjá ). Á þessum tíma mun Helm 3 hafa tíma til að koma á stöðugleika.
PS
Lestu líka á blogginu okkar:
- Röð athugasemda um nýjungar í werf:
- «»;
- «»;
- «'.
- «»;
- «»;
- «'.
Heimild: www.habr.com