Við kynnum Helm 3

Athugið. þýð.: 16. maí á þessu ári markar mikilvægur áfangi í þróun pakkastjórans fyrir Kubernetes - Helm. Þennan dag var fyrsta alfaútgáfan af framtíðarútgáfu verkefnisins - 3.0 - kynnt. Útgáfa þess mun hafa verulegar og langþráðar breytingar á Helm, sem margir í Kubernetes samfélaginu binda miklar vonir við. Við sjálf erum ein af þessum, þar sem við notum Helm virkan fyrir dreifingu forrita: við höfum samþætt það í tólið okkar til að innleiða CI/CD werf og af og til leggjum við okkar af mörkum til þróunar andstreymis. Þessi þýðing sameinar 7 athugasemdir frá opinbera Helm blogginu, sem eru tileinkaðar fyrstu alfa útgáfu Helm 3 og fjalla um sögu verkefnisins og helstu eiginleika Helm 3. Höfundur þeirra er Matt „bacongobbler“ Fisher, starfsmaður Microsoft og einn af helstu viðhaldsaðilum Helm.

Þann 15. október 2015 fæddist verkefnið sem nú er þekkt sem Helm. Aðeins ári eftir stofnun þess gekk Helm samfélagið til liðs við Kubernetes, á meðan hann var að vinna að Helm 2. Í júní 2018, Helm gekk til liðs við CNCF sem þróunarverkefni (ræktunarverkefni). Hratt áfram til nútímans og fyrsta alfaútgáfan af nýja Helm 3 er á leiðinni. (þessi útgáfa hefur þegar átt sér stað um miðjan maí - ca. þýðing.).

Í þessu stykki mun ég tala um hvar þetta byrjaði allt, hvernig við komumst á þann stað sem við erum í dag, kynna nokkra af þeim einstöku eiginleikum sem til eru í fyrstu alfa útgáfunni af Helm 3 og útskýra hvernig við ætlum að halda áfram.

Yfirlit:

• sköpunarsaga Helms;
• ljúf kveðja Tiller;
• grafageymslur;
• losunarstjórnun;
• breytingar á ósjálfstæði korta;
• bókasafnstöflur;
• hvað er næst?

Saga Helms

Fæðing

Helm 1 byrjaði sem Open Source verkefni búið til af Deis. Við vorum lítið sprotafyrirtæki frásogast Microsoft vorið 2017. Annað Open Source verkefnið okkar, einnig nefnt Deis, var með tól deisctl, sem var notað (meðal annars) til að setja upp og reka Deis pallinn í Flotaþyrping. Á þeim tíma var Fleet einn af fyrstu gámaskipunarpöllunum.

Um mitt ár 2015 ákváðum við að breyta um stefnu og færðum Deis (á þeim tíma endurnefnt Deis Workflow) úr Fleet til Kubernetes. Eitt af því fyrsta sem var endurhannað var uppsetningartólið. deisctl. Við notuðum það til að setja upp og stjórna Deis Workflow í flotaklasanum.

Helm 1 var búið til í mynd frægra pakkastjóra eins og Homebrew, apt og yum. Meginmarkmið þess var að einfalda verkefni eins og pökkun og uppsetningu forrita á Kubernetes. Helm var formlega kynnt árið 2015 á KubeCon ráðstefnunni í San Francisco.

Fyrsta tilraun okkar með Helm virkaði, en hún var ekki án nokkurra alvarlegra takmarkana. Hann tók sett af Kubernetes upplýsingaskrám, bragðbætt með rafala sem inngangs YAML kubba (framhlið)*, og hlaðið niðurstöðunum inn í Kubernetes.

* Athugið. þýð.: Frá fyrstu útgáfu Helm var YAML setningafræði valin til að lýsa Kubernetes auðlindum og Jinja sniðmát og Python forskriftir voru studdar við ritun stillingar. Við skrifuðum meira um þetta og uppbyggingu fyrstu útgáfunnar af Helm almennt í kaflanum „A Brief History of Helm“ þetta efni.

Til dæmis, til að skipta um reit í YAML skrá, þurftir þú að bæta eftirfarandi smíði við upplýsingaskrána:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Það er frábært að sniðmátvélar séu til í dag, er það ekki?

Af mörgum ástæðum krafðist þetta snemma Kubernetes uppsetningarforrit harðkóðaðan lista yfir upplýsingaskrár og framkvæmdi aðeins litla, fasta atburðaröð. Það var svo erfitt í notkun að Deis Workflow R&D teymi átti erfitt uppdráttar þegar þeir reyndu að flytja vöru sína á þennan vettvang - hins vegar var fræjum hugmyndarinnar þegar sáð. Fyrsta tilraun okkar var frábært námstækifæri: við áttum okkur á því að við höfðum sannarlega brennandi áhuga á að búa til raunsæ verkfæri sem leysa hversdagsleg vandamál fyrir notendur okkar.

Byggt á reynslu af fyrri mistökum byrjuðum við að þróa Helm 2.

Gerir hjálm 2

Í lok árs 2015 hafði Google teymið samband við okkur. Þeir voru að vinna að svipuðu tóli fyrir Kubernetes. Deployment Manager fyrir Kubernetes var höfn á núverandi tóli sem var notað fyrir Google Cloud Platform. „Viljum við,“ spurðu þeir, „eyða nokkrum dögum í að ræða líkt og ólíkt?

Í janúar 2016 hittust lið Helm og Deployment Manager í Seattle til að skiptast á hugmyndum. Samningaviðræðunum lauk með metnaðarfullri áætlun: að sameina bæði verkefnin til að búa til Helm 2. Ásamt Deis og Google, krakkarnir frá SkipBox (nú hluti af Bitnami - u.þ.b. þýðing), og við byrjuðum að vinna að Helm 2.

Við vildum halda áfram að nota Helm, en bættum við eftirfarandi:

• kortasniðmát til að sérsníða;
• innan klasastjórnunar fyrir teymi;
• heimsklassa kortageymsla;
• stöðugt pakkasnið með undirskriftarmöguleika;
• sterk skuldbinding um merkingarfræðilega útgáfu og viðhalda afturábakssamhæfni milli útgáfur.

Til að ná þessum markmiðum hefur öðrum þætti verið bætt við Helm vistkerfið. Þessi innanþyrpingahluti var kallaður Tiller og sá um að setja upp Helm kort og stjórna þeim.

Síðan Helm 2 kom út árið 2016 hefur Kubernetes bætt við nokkrum helstu nýjungum. Bætt við hlutverkatengdri aðgangsstýringu (RBAC), sem að lokum leysti af hólmi eiginleika-Based Access Control (ABAC). Nýjar tegundir tilfanga voru kynntar (Deployments var enn í beta-útgáfu á þeim tíma). Sérsniðnar auðlindaskilgreiningar (upphaflega kallaðar Third Party Resources eða TPRs) voru fundnar upp. Og síðast en ekki síst, sett af bestu starfsvenjum hefur komið fram.

Innan við allar þessar breytingar hélt Helm áfram að þjóna Kubernetes notendum dyggilega. Eftir þrjú ár og margar nýjar viðbætur var ljóst að það væri kominn tími til að gera verulegar breytingar á kóðagrunninum til að tryggja að Helm gæti haldið áfram að mæta vaxandi þörfum vistkerfis í þróun.

Með kærri kveðju til Tiller

Við þróun Helm 2 kynntum við Tiller sem hluta af samþættingu okkar við dreifingarstjóra Google. Tiller gegndi mikilvægu hlutverki fyrir teymi sem starfa innan sameiginlegs klasa: það gerði mismunandi sérfræðingum sem starfrækja innviðina að hafa samskipti við sama sett af útgáfum.

Þar sem hlutverkatengd aðgangsstýring (RBAC) var sjálfkrafa virkjuð í Kubernetes 1.6, varð erfiðara að vinna með Tiller í framleiðslu. Vegna fjölda mögulegra öryggisstefnu hefur afstaða okkar verið sú að bjóða upp á leyfilega uppsetningu sjálfgefið. Þetta gerði nýliðum kleift að gera tilraunir með Helm og Kubernetes án þess að þurfa að kafa í öryggisstillingar fyrst. Því miður gæti þessi heimildastilling veitt notandanum of breitt úrval af heimildum sem þeir þurftu ekki. DevOps og SRE verkfræðingar þurftu að læra fleiri aðgerðaskref þegar Tiller var sett upp í fjölleiguklasa.

Eftir að hafa lært hvernig samfélagið notaði Helm við sérstakar aðstæður komumst við að því að útgáfustjórnunarkerfi Tiller þarf ekki að reiða sig á íhluta innan klasa til að viðhalda ástandi eða virka sem miðlæg miðstöð fyrir útgáfuupplýsingar. Þess í stað gætum við einfaldlega tekið á móti upplýsingum frá Kubernetes API þjóninum, búið til töflu á biðlarahlið og geymt skrá yfir uppsetninguna í Kubernetes.

Meginmarkmið Tiller hefði getað náðst án Tiller, þannig að ein af fyrstu ákvörðunum okkar varðandi Helm 3 var að yfirgefa Tiller algjörlega.

Þegar Tiller er farinn hefur öryggislíkan Helms verið einfaldað til muna. Helm 3 styður nú allar nútímalegar öryggis-, auðkennis- og heimildaraðferðir núverandi Kubernetes. Hjálparheimildir eru ákvarðaðar með því að nota kubeconfig skrá. Klasastjórnendur geta takmarkað notendaréttindi við hvaða nákvæmni sem er. Útgáfur eru enn vistaðar í þyrpingunni og restin af virkni Helm er ósnortinn.

Myndageymslur

Á háu stigi er kortageymsla staður þar sem hægt er að geyma og deila myndritum. Helm viðskiptavinurinn pakkar og sendir töflurnar í geymsluna. Einfaldlega sagt, töflugeymsla er frumstæður HTTP þjónn með index.yaml skrá og sumum pökkuðum töflum.

Þó að það séu nokkrir kostir við að Charts Repository API uppfylli flestar grunnkröfur um geymslu, þá eru líka nokkrir ókostir:

• Myndageymslur eru ekki samhæfðar við flestar öryggisútfærslur sem krafist er í framleiðsluumhverfi. Að hafa staðlað API fyrir auðkenningu og heimild er afar mikilvægt í framleiðsluatburðarás.
• Upprunakort Helm, notuð til að undirrita, sannreyna heiðarleika og uppruna korts, eru valfrjáls hluti af útgáfuferli myndrita.
• Í fjölnotendaaðstæðum getur annar notandi hlaðið sama töflunni upp og tvöfaldað plássið sem þarf til að geyma sama efni. Snjallari geymslur hafa verið þróaðar til að leysa þetta vandamál, en þær eru ekki hluti af formlegu forskriftinni.
• Notkun einni vísitöluskrá til að leita, geyma lýsigögn og sækja töflur hefur gert það erfitt að þróa öruggar fjölnotendaútfærslur.

Project Docker dreifing (einnig þekkt sem Docker Registry v2) er arftaki Docker Registry og virkar í raun sem safn verkfæra til að pakka, senda, geyma og afhenda Docker myndir. Margar stórar skýjaþjónustur bjóða upp á vörur sem byggja á dreifingu. Þökk sé þessari auknu athygli hefur dreifingarverkefnið notið góðs af margra ára umbótum, bestu starfsvenjum í öryggi og vettvangsprófunum sem hafa gert það að einni farsælustu ósungnu hetju Open Source heimsins.

En vissir þú að dreifingarverkefnið var hannað til að dreifa hvers kyns efni, ekki bara gámamyndum?

Þökk sé viðleitninni Opið gámafrumtak (eða OCI), hægt er að setja Helm töflur á hvaða dreifingartilvik sem er. Í bili er þetta ferli tilraunakennt. Innskráningarstuðningur og aðrir eiginleikar sem þarf fyrir fullan Helm 3 eru í vinnslu, en við erum spennt að læra af uppgötvunum sem OCI og dreifingarteymið hafa gert í gegnum árin. Og í gegnum leiðsögn þeirra og leiðsögn lærum við hvernig það er að starfrækja mjög tiltæka þjónustu í stærðargráðu.

Nánari lýsing á nokkrum væntanlegum breytingum á Helm kortageymslunum er fáanleg по ссылке.

Útgáfustjórnun

Í Helm 3 er umsóknarástand rakið innan klasans með pari af hlutum:

• losunarhlutur - táknar forritstilvik;
• útgáfu útgáfa leyndarmál - táknar æskilegt ástand forritsins á tilteknum tímapunkti (til dæmis útgáfu nýrrar útgáfu).

Hringdu helm install býr til útgáfuhlut og losunarútgáfu leyndarmál. Hringdu helm upgrade krefst útgáfuhluts (sem hann getur breytt) og býr til nýja útgáfuútgáfu sem inniheldur nýju gildin og tilbúna upplýsingaskrá.

Losunarhlutur inniheldur upplýsingar um útgáfuna, þar sem losun er ákveðin uppsetning á nafngreindu grafi og gildum. Þessi hlutur lýsir lýsigögnum á efsta stigi um útgáfuna. Útgáfuhluturinn er viðvarandi allan líftíma forritsins og er eigandi allra útgáfuútgáfuleyndarmála, sem og allra hluta sem eru beint búnir til af Helm töflunni.

Leyndarmál útgáfuútgáfu tengir útgáfu við röð endurskoðana (uppsetning, uppfærslur, afturköllun, eyðing).

Í Helm 2 voru endurskoðanir mjög samkvæmar. Hringdu helm install búið til v1, síðari uppfærslu (uppfærsla) - v2, og svo framvegis. Leyndarmál útgáfu og útgáfu útgáfu hefur verið hrundið saman í einn hlut sem kallast endurskoðun. Breytingar voru geymdar í sama nafnrými og Tiller, sem þýddi að hver útgáfa var "alþjóðleg" hvað varðar nafnrými; þar af leiðandi var aðeins hægt að nota eitt dæmi um nafnið.

Í Helm 3 er hver útgáfa tengd einu eða fleiri útgáfuleyndarmálum. Útgáfuhluturinn lýsir alltaf núverandi útgáfu sem er sett á Kubernetes. Leyndarmál hverrar útgáfuútgáfu lýsir aðeins einni útgáfu af þeirri útgáfu. Uppfærsla, til dæmis, mun búa til nýja útgáfu útgáfu leyndarmál og síðan breyta útgáfu hlutnum til að benda á þá nýju útgáfu. Ef um er að ræða afturköllun geturðu notað leyndarmál fyrri útgáfu útgáfu til að snúa útgáfunni aftur í fyrra ástand.

Eftir að Tiller er yfirgefin geymir Helm 3 útgáfugögn í sama nafnrými og útgáfan. Þessi breyting gerir þér kleift að setja upp töflu með sama útgáfuheiti í öðru nafnrými og gögnin eru vistuð á milli klasauppfærslu/endurræsingar í etcd. Til dæmis geturðu sett upp WordPress í „foo“ nafnrýminu og síðan í „bar“ nafnrýminu og báðar útgáfurnar geta heitið „wordpress“.

Breytingar á kortafíkn

Myndrit pakkað (með því að nota helm package) til notkunar með Helm 2 er hægt að setja upp með Helm 3, hins vegar hefur vinnuflæði kortaþróunar verið endurskoðað að fullu, þannig að nokkrar breytingar verða að gera til að halda áfram þróun korta með Helm 3. Sérstaklega hefur stjórnunarkerfi kortaháðarinnar breyst.

Ávanastjórnunarkerfi myndritsins hefur færst frá requirements.yaml и requirements.lock á Chart.yaml и Chart.lock. Þetta þýðir að töflurnar sem notuðu skipunina helm dependency, þarf einhverja uppsetningu til að virka í Helm 3.

Við skulum líta á dæmi. Við skulum bæta ósjálfstæði við töfluna í Helm 2 og sjá hvað breytist þegar farið er yfir í Helm 3.

Í Hjálmi 2 requirements.yaml leit svona út:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Í Helm 3 mun sama ósjálfstæði endurspeglast í þínu Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Myndritum er enn hlaðið niður og sett í möppuna charts/, svo undirtöflur (undirtöflur), sem liggur í vörulistanum charts/, mun starfa áfram án breytinga.

Við kynnum bókasafnstöflur

Helm 3 styður flokk korta sem kallast bókasafnskort (safnkort). Þetta kort er notað af öðrum myndritum, en býr ekki til neina útgáfugripi á eigin spýtur. Sniðmát bókasafnsrita getur aðeins lýst þáttum define. Annað efni er einfaldlega hunsað. Þetta gerir notendum kleift að endurnýta og deila kóðabútum sem hægt er að nota á mörgum töflum, þannig að forðast tvíverknað og viðhalda meginreglunni Þurrkað.

Bókasafnstöflur eru lýstar í kaflanum dependencies í skrá Chart.yaml. Uppsetning og umsjón með þeim er ekkert frábrugðin öðrum töflum.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Við erum spennt fyrir notkunartilvikunum sem þessi hluti mun opna fyrir korthönnuði, sem og bestu starfsvenjur sem geta komið fram úr bókasafnstöflum.

Hvað er næst?

Helm 3.0.0-alpha.1 er grunnurinn sem við byrjum á að byggja nýja útgáfu af Helm á. Í greininni lýsti ég nokkrum áhugaverðum eiginleikum Helm 3. Margir þeirra eru enn á frumstigi þróunar og þetta er eðlilegt; Tilgangurinn með alfa útgáfu er að prófa hugmyndina, safna viðbrögðum frá fyrstu notendum og staðfesta forsendur okkar.

Um leið og alfa útgáfan er gefin út (mundu að þetta er þegar gerst - ca. þýðing.), munum við byrja að samþykkja plástra fyrir Helm 3 frá samfélaginu. Þú þarft að búa til sterkan grunn sem gerir kleift að þróa og taka upp nýja virkni og að notendur finni fyrir þátttöku í ferlinu með því að opna miða og gera lagfæringar.

Ég hef reynt að draga fram nokkrar af helstu endurbótunum sem koma á Helm 3, en þessi listi er alls ekki tæmandi. Heildar vegakortið fyrir Helm 3 inniheldur eiginleika eins og bættar uppfærsluaðferðir, dýpri samþættingu við OCI skrár og notkun JSON skema til að sannreyna kortagildi. Við ætlum líka að hreinsa til í kóðagrunninum og uppfæra hluta hans sem hafa verið vanræktir undanfarin þrjú ár.

Ef þér finnst eins og við höfum misst af einhverju, viljum við gjarnan heyra hugsanir þínar!

Taktu þátt í umræðunni á okkar Slakar rásir:

• #helm-users fyrir spurningar og einföld samskipti við samfélagið;
• #helm-dev til að ræða pull beiðnir, kóða og villur.

Þú getur líka spjallað í vikulegum opinberum símtölum fyrir þróunaraðila á fimmtudögum klukkan 19:30 MSK. Fundirnir eru helgaðir því að ræða málefni sem lykilframleiðendur og samfélagið eru að vinna að, svo og umræðuefni vikunnar. Allir geta verið með og tekið þátt í fundinum. Tengill í boði í Slack rás #helm-dev.

PS frá þýðanda

Lestu líka á blogginu okkar:

• «Pakkastjóri fyrir Kubernetes - Helm: fortíð, nútíð, framtíð»;
• «Alveg edrú sýn á hjálm 2: „Þetta er það sem það er...“»;
• «Hagnýt kynning á pakkastjóranum fyrir Kubernetes - Helm»;
• «Kubernetes ráð og brellur: flytja tilföng sem keyra í klasa yfir í Helm 2 stjórnun»;
• «Æfðu þig með dapp. Part 2. Dreifa Docker myndum til Kubernetes með því að nota Helm'.

Heimild: www.habr.com