🥇Hjálmartækið og gildrur þess

Typhon vöruflutningabíll hugmynd, Anton Swanepoel

Ég heiti Dmitry Sugrobov, ég er verktaki hjá Leroy Merlin. Í þessari grein mun ég segja þér hvers vegna Helm er þörf, hvernig það einfaldar vinnu með Kubernetes, hvað hefur breyst í þriðju útgáfunni og hvernig á að nota það til að uppfæra forrit í framleiðslu án niður í miðbæ.

Þetta er samantekt byggð á ræðu á ráðstefnu @Kubernetes ráðstefna by Mail.ru skýjalausnir - ef þú vilt ekki lesa skaltu horfa á myndbandið.

Af hverju við notum Kubernetes í framleiðslu

Leroy Merlin er leiðandi á DIY smásölumarkaði í Rússlandi og Evrópu. Fyrirtækið okkar hefur meira en hundrað þróunaraðila, 33 innri starfsmenn og gífurlegan fjölda fólks sem heimsækir stórmarkaði og vefsíðuna. Til að gleðja þá alla ákváðum við að fylgja stöðluðum aðferðum iðnaðarins. Þróa ný forrit með því að nota örþjónustuarkitektúr; nota ílát til að einangra umhverfi og tryggja rétta afhendingu; og notaðu Kubernetes til að skipuleggja. Verðið á að nota hljómsveitarstjóra er hratt að verða ódýrara: fjöldi verkfræðinga sem eru færir um tæknina fer vaxandi á markaðnum og veitendur birtast sem bjóða upp á Kubernetes sem þjónustu.

Allt sem Kubernetes gerir er auðvitað hægt að gera á annan hátt, til dæmis með því að fjalla um Jenkins og docker-compose með handritum, en af hverju að flækja lífið ef það er tilbúin og áreiðanleg lausn? Þess vegna komum við til Kubernetes og höfum notað það í framleiðslu í eitt ár núna. Núna erum við með tuttugu og fjóra Kubernetes klasa, sá elsti er meira en ársgamall, með um tvö hundruð fræbelgjum.

Bölvun stórra YAML skráa í Kubernetes

Til að ræsa örþjónustu í Kubernetes, munum við búa til að minnsta kosti fimm YAML skrár: fyrir dreifingu, þjónustu, inngöngu, ConfigMap, Secrets - og senda þær í þyrpinguna. Fyrir næstu umsókn munum við skrifa sama pakkann af jambs, með því þriðja skrifum við annan, og svo framvegis. Ef við margföldum fjölda skjala með fjölda umhverfi, munum við nú þegar fá hundruð skráa, og þetta er ekki enn að taka tillit til kraftmikilla umhverfisins.

Adam Reese, aðalviðhaldari Helm, kynnti hugmyndina um "Þróunarferill í Kubernetes", sem lítur svona út:

Afritaðu YAML - afritaðu YAML skrá.
Límdu YAML - límdu það.
Laga inndrátt - laga inndrátt.
Endurtaktu - endurtaktu aftur.

Valkosturinn virkar, en þú þarft að afrita YAML skrárnar mörgum sinnum. Til að breyta þessari hringrás var Helm fundið upp.

Hvað er Helm

Í fyrsta lagi, Helm - pakkastjóri, sem hjálpar þér að finna og setja upp forritin sem þú þarft. Til að setja upp, til dæmis, MongoDB, þarftu ekki að fara á opinberu vefsíðuna og hlaða niður tvöfaldur, bara keyra skipunina helm install stable/mongodb.

Í öðru lagi, Helm - sniðmát vél, hjálpar til við að stilla skrár. Snúum okkur aftur að ástandinu með YAML skrár í Kubernetes. Það er auðveldara að skrifa sömu YAML skrána, bæta nokkrum staðgengum við hana, sem Helm mun setja gildin í. Það er, í stað stórs setts af vinnupöllum, verður sett af sniðmátum þar sem nauðsynlegum gildum verður skipt út á réttum tíma.

Í þriðja lagi, Helm - dreifingarstjóri. Með því geturðu sett upp, afturkallað og uppfært forrit. Við skulum reikna út hvernig á að gera þetta.

Hvernig á að nota Helm til að dreifa eigin forritum

Við skulum setja upp Helm biðlarann á tölvunni þinni, eftir opinbera leiðbeiningar. Næst munum við búa til sett af YAML skrám. Í stað þess að tilgreina ákveðin gildi munum við skilja eftir staðgengla sem Helm mun fylla með upplýsingum í framtíðinni. Safn af slíkum skrám er kallað Helm chart. Það er hægt að senda til Helm stjórnborðsbiðlarans á þrjá vegu:

tilgreina möppu með sniðmátum;
pakka skjalasafninu inn í .tar og benda á það;
settu sniðmátið í ytri geymslu og bættu við tengli við geymsluna í Helm biðlaranum.

Þú þarft líka skrá með gildum - values.yaml. Gögnin þaðan verða sett inn í sniðmátið. Við skulum búa það líka.

Önnur útgáfan af Helm er með auka netþjónaforriti - Tiller. Það hangir fyrir utan Kubernetes og bíður eftir beiðnum frá Helm viðskiptavininum, og þegar hringt er í, kemur það í stað nauðsynlegra gilda í sniðmátið og sendir það til Kubernetes.

Helm 3 er einfaldara: í stað þess að vinna sniðmát á þjóninum eru upplýsingar nú unnar algjörlega á Helm biðlarahlið og sendar beint á Kubernetes API. Þessi einföldun bætir klasaöryggi og auðveldar útfærsluáætlunina.

Hvernig virkar þetta allt saman

Keyra skipunina helm install. Við skulum gefa til kynna nafn forritsútgáfunnar og gefa slóðina að values.yaml. Í lokin munum við tilgreina geymsluna sem kortið er í og nafnið á kortinu. Í dæminu eru þetta „lmru“ og „bestchart“ í sömu röð.

helm install --name bestapp --values values.yaml lmru/bestchart

Skipunina er aðeins hægt að framkvæma einu sinni, þegar hún er framkvæmd aftur í staðinn install þarf að nota upgrade. Til einföldunar geturðu keyrt skipunina í stað tveggja skipana upgrade með aukalykli --install. Þegar það er keyrt í fyrsta skipti mun Helm senda skipun til að setja upp útgáfuna og mun uppfæra hana í framtíðinni.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Gildrurnar við að dreifa nýjum útgáfum af forriti með Helm

Á þessum tímapunkti sögunnar er ég að leika Who Wants to Be a Millionaire með áhorfendum og við erum að finna út hvernig á að fá Helm til að uppfæra útgáfuna af appinu. Horfðu á myndbandið.

Þegar ég var að læra hvernig Helm virkar kom ég á óvart með undarlegri hegðun þegar ég reyndi að uppfæra útgáfur af keyrandi forritum. Ég uppfærði forritakóðann, hlóð upp nýrri mynd í Docker registry, sendi dreifingarskipunina - og ekkert gerðist. Hér að neðan eru nokkrar ekki alveg árangursríkar leiðir til að uppfæra forrit. Með því að rannsaka hvert þeirra nánar byrjarðu að skilja innri uppbyggingu tækisins og ástæðurnar fyrir þessari ekki augljósu hegðun.

Aðferð 1. Ekki breyta upplýsingum frá síðustu ræsingu

Eins og segir opinbera síða Helm, "Kubernetes kort geta verið stór og flókin, svo Helm reynir að snerta ekki neitt of mikið." Þess vegna, ef þú uppfærir nýjustu útgáfuna af forritsmyndinni í docker registry og keyrir skipunina helm upgrade, þá gerist ekkert. Helm mun halda að ekkert hafi breyst og það er engin þörf á að senda skipun til Kubernetes til að uppfæra forritið.

Hér og hér að neðan er nýjasta merkið eingöngu sýnt sem dæmi. Þegar þú tilgreinir þetta merki, mun Kubernetes hlaða niður myndinni úr docker-skránni í hvert skipti, óháð færibreytunni imagePullPolicy. Notkun nýjustu framleiðslunnar er óæskileg og veldur aukaverkunum.

Aðferð 2. Uppfærðu LABEL á mynd

Eins og skrifað í sama skjöl, "Helm mun aðeins uppfæra forrit ef það hefur breyst frá síðustu útgáfu." Rökréttur valkostur fyrir þetta virðist vera að uppfæra LABEL í sjálfri docker myndinni. Hins vegar skoðar Helm ekki forritamyndirnar og hefur ekki hugmynd um breytingar á þeim. Í samræmi við það, þegar merki eru uppfærð á myndinni, mun Helm ekki vita af þeim og uppfærsluskipun forritsins verður ekki send til Kubernetes.

Aðferð 3: Notaðu lykil --force

Snúum okkur að handbókunum og leitum að nauðsynlegum lykli. Lykillinn er skynsamlegastur --force. Þrátt fyrir augljóst nafn er hegðunin önnur en búist var við. Í stað þess að þvinga fram uppfærslu á forriti, er raunverulegur tilgangur hennar að endurheimta útgáfu sem er í MEISTAÐA stöðu. Ef þú notar ekki þennan lykil þarftu að framkvæma skipanirnar í röð helm delete && helm install --replace. Mælt er með því að nota lykilinn í staðinn --force, sem gerir sjálfvirkan raðframkvæmd þessara skipana. Nánari upplýsingar í þessu draga beiðni. Til þess að segja Helm að uppfæra forritaútgáfuna mun þessi lykill því miður ekki virka.

Aðferð 4. Breyttu merkjum beint í Kubernetes

Uppfærir merki beint í klasanum með því að nota skipunina kubectl edit - slæm hugmynd. Þessi aðgerð mun leiða til ósamræmis upplýsinga á milli forritsins sem er í gangi og þess sem upphaflega var sent til dreifingar. Hegðun Helm við uppsetningu í þessu tilviki er frábrugðin útgáfu þess: Helm 2 mun ekki gera neitt og Helm 3 mun senda nýju útgáfuna af forritinu. Til að skilja hvers vegna þarftu að skilja hvernig Helm virkar.

Hvernig virkar Helm?

Til að ákvarða hvort forrit hafi breyst frá síðustu útgáfu þess getur Helm notað:

keyra forrit í Kubernetes;
ný gildi.yaml og núverandi graf;
Innri útgáfuupplýsingar Helm.

Fyrir þá sem eru fróðari: hvar geymir Helm innri upplýsingar um útgáfur?Með því að framkvæma skipunina helm history, munum við fá allar upplýsingar um útgáfurnar sem settar eru upp með Helm.

Það eru einnig nákvæmar upplýsingar um send sniðmát og gildi. Við getum beðið um það:

Í annarri útgáfu Helm eru þessar upplýsingar staðsettar í sama nafnrými og Tiller er í gangi (kube-kerfi sjálfgefið), í ConfigMap, merkt með merkimiðanum „OWNER=TILLER“:

Þegar þriðja útgáfan af Helm birtist færðust upplýsingarnar yfir í leyndarmál og í sama nafnrými þar sem forritið var í gangi. Þökk sé þessu varð mögulegt að keyra nokkur forrit samtímis í mismunandi nafnasvæðum með sama útgáfuheiti. Í seinni útgáfunni var það alvarlegur höfuðverkur þegar nafnarými eru einangruð en geta haft áhrif hvert á annað.

Annar Helm, þegar reynt er að skilja hvort uppfærslu sé þörf, notar aðeins tvær upplýsingar: það sem honum er veitt núna og innri upplýsingar um útgáfur, sem liggja í ConfigMap.

Þriðja Helm notar þríhliða samrunastefnu: auk þessara upplýsinga tekur það einnig tillit til forritsins sem er í gangi núna í Kubernetes.

Af þessum sökum mun gamla útgáfan af Helm ekki gera neitt, þar sem hún tekur ekki tillit til umsóknarupplýsinga í klasanum, en Helm 3 mun taka á móti breytingunum og senda nýju forritið til dreifingar.

Aðferð 5. Notaðu --recreate-pods rofann

Með lykli --recreate-pods þú getur náð því sem þú ætlaðir upphaflega að ná með lyklinum --force. Gámarnir munu endurræsa sig og samkvæmt imagePullPolicy: Always policy fyrir nýjasta merkið (nánar um þetta í neðanmálsgreininni hér að ofan), mun Kubernetes hlaða niður og opna nýja útgáfu af myndinni. Þetta verður ekki gert á besta hátt: án þess að taka tillit til StrategyType dreifingar mun það skyndilega slökkva á öllum gömlum forritatilvikum og hefja ný. Við endurræsingu mun kerfið ekki virka, notendur munu þjást.

Í Kubernetes sjálfu var svipað vandamál einnig uppi í langan tíma. Og núna, 4 árum eftir opnun Tölublað, vandamálið hefur verið lagað og frá og með útgáfu 1.15 af Kubernetes birtist hæfileikinn til að endurræsa belg.

Helm slekkur einfaldlega á öllum forritum og setur nýja ílát í nágrenninu. Þú getur ekki gert þetta í framleiðslu, til að valda ekki niður í miðbæ. Þetta er aðeins þörf fyrir þróunarþarfir og er aðeins hægt að framkvæma í sviðsumhverfi.

Hvernig á að uppfæra forritaútgáfuna með því að nota Helm?

Við munum breyta gildunum sem send eru til Helm. Venjulega eru þetta gildi sem skipt er út fyrir myndamerkið. Þegar um er að ræða nýjasta, sem oft er notað fyrir óframleiðandi umhverfi, eru breytanlegar upplýsingar athugasemdir, sem eru gagnslausar fyrir Kubernetes sjálft, og fyrir Helm mun það virka sem merki um þörfina á að uppfæra forritið. Valkostir til að fylla út athugasemdagildi:

Tilviljunarkennd gildi með því að nota staðlaða aðgerðina - {{ randAlphaNum 6 }}.
Það er fyrirvari: eftir hverja uppsetningu með því að nota töflu með slíkri breytu verður skýringargildið einstakt og Helm mun gera ráð fyrir að það séu breytingar. Það kemur í ljós að við munum alltaf endurræsa forritið, jafnvel þótt við höfum ekki breytt útgáfu þess. Þetta er ekki mikilvægt, þar sem það verður engin niður í miðbæ, en það er samt óþægilegt.
Límdu núverandi Dagsetning og tími - {{ .Release.Date }}.
Afbrigði er svipað og handahófsgildi með varanlega einstaka breytu.
Réttari leiðin er að nota tékksummur. Þetta er SHA myndarinnar eða SHA síðasta commit í git - {{ .Values.sha }}.
Telja þarf þá og senda þeim til Helm-viðskiptavinarins sem hringir, til dæmis í Jenkins. Ef umsóknin hefur breyst mun eftirlitsumman breytast. Þess vegna mun Helm aðeins uppfæra forritið þegar þess er þörf.

Við skulum draga saman tilraunir okkar

Helm gerir breytingar á minnsta ífarandi hátt, þannig að allar breytingar á forritamyndastigi í Docker Registry munu ekki leiða til uppfærslu: ekkert mun gerast eftir að skipunin er keyrð.
Lykill --force notað til að endurheimta erfiðar útgáfur og er ekki tengt þvinguðum uppfærslum.
Lykill --recreate-pods mun uppfæra forrit af krafti, en mun gera það með skemmdarverkum: það mun skyndilega slökkva á öllum gámum. Notendur munu þjást af þessu; þú ættir ekki að gera þetta í framleiðslu.
Gerðu breytingar beint á Kubernetes klasanum með því að nota skipunina kubectl edit ekki: við rjúfum samræmi og hegðunin mun vera mismunandi eftir útgáfu Helm.
Með útgáfu nýju útgáfunnar af Helm hafa mörg blæbrigði birst. Málum í Helm geymslunni er lýst á skýru máli, þau munu hjálpa þér að skilja smáatriðin.
Með því að bæta við breytanlegum athugasemdum við myndrit verður það sveigjanlegra. Þetta gerir þér kleift að rúlla út forritinu á réttan hátt, án niður í miðbæ.

Hugsun um „heimsfriður“ sem virkar á öllum sviðum lífsins: lestu leiðbeiningarnar fyrir notkun, ekki eftir notkun. Aðeins með fullkomnum upplýsingum verður hægt að byggja upp áreiðanleg kerfi og gera notendur ánægða.

Aðrir tengdir tenglar:

Skýrsla þessi var fyrst kynnt kl @Kubernetes ráðstefna frá Mail.ru Cloud Solutions. Sjáðu vídeó aðrar sýningar og gerast áskrifandi að viðburðatilkynningum á Telegram Í kringum Kubernetes hjá Mail.ru Group.

Heimild: www.habr.com

Helm tækið og gildrur þess