werf 1.1 útgáfa: endurbætur á byggingaraðilanum í dag og áætlanir fyrir framtíðina

werf 1.1 útgáfa: endurbætur á byggingaraðilanum í dag og áætlanir fyrir framtíðina

werf er opinn uppspretta GitOps CLI tólið okkar til að byggja og afhenda forrit til Kubernetes. Eins og lofað var, útgáfu af útgáfu v1.0 markaði upphafið að því að bæta nýjum eiginleikum við werf og endurskoða hefðbundnar aðferðir. Nú erum við ánægð að kynna útgáfu v1.1, sem er stórt skref í þróun og grunnur að framtíðinni safnari werf. Útgáfan er nú fáanleg í rás 1.1 ea.

Grunnurinn að útgáfunni er nýr arkitektúr sviðsgeymslu og hagræðingu á vinnu beggja safnara (fyrir Stapel og Dockerfile). Nýi geymsluarkitektúrinn opnar möguleikann á að útfæra dreifðar samsetningar frá mörgum vélum og samhliða samsetningu á sama vélinni.

Hagræðing vinnu felur í sér að losa sig við óþarfa útreikninga á því stigi að reikna út stigi undirskriftir og breyta aðferðum til að reikna út skráathugunarsummur í skilvirkari. Þessi hagræðing dregur úr meðaltíma verkefnabygginga með því að nota werf. Og aðgerðalaus smíði, þegar öll stig eru til í skyndiminni stig-geymsla, eru nú mjög fljótir. Í flestum tilfellum mun endurræsa smíðina taka minna en 1 sekúndu! Þetta á einnig við um verklag til að sannreyna stig í vinnuferli teyma. werf deploy и werf run.

Einnig í þessari útgáfu birtist stefna til að merkja myndir eftir efni - innihaldsmiðaða merkingu, sem er nú sjálfgefið virkt og það eina sem mælt er með.

Við skulum skoða nánar helstu nýjungar í werf v1.1 og segja þér um leið frá áætlunum um framtíðina.

Hvað hefur breyst í werf v1.1?

Nýtt stigsnefnasnið og reiknirit til að velja stig úr skyndiminni

Ný regla um myndun sviðsnafna. Nú býr hver þrepabygging til einstakt sviðsnafn, sem samanstendur af 2 hlutum: undirskrift (eins og hún var í v1.0) auk einstakts tímabundið auðkennis.

Til dæmis gæti heiti myndarinnar í heild sinni litið svona út:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...eða almennt:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Hér:

  • SIGNATURE er sviðsáskrift, sem táknar auðkenni sviðsefnisins og fer eftir sögu breytinga í Git sem leiddu til þessa efnis;
  • TIMESTAMP_MILLISEC er tryggt einstakt myndauðkenni sem er búið til á þeim tíma sem ný mynd er byggð.

Reikniritið til að velja stig úr skyndiminni byggist á því að athuga samband Git commits:

  1. Werf reiknar út undirskrift ákveðins stigs.
  2. В stig-geymsla Það geta verið nokkur stig fyrir tiltekna undirskrift. Werf velur öll stig sem passa við undirskriftina.
  3. Ef núverandi stig er tengt við Git (git-archive, sérsniðið stig með Git plástra: install, beforeSetup, setup; eða git-latest-patch), þá velur werf aðeins þau stig sem eru tengd commit sem er forfaðir núverandi commit (sem byggingin er kölluð fyrir).
  4. Úr þeim stigum sem eftir eru er einn valinn - sá elsti eftir stofnunardegi.

Stig fyrir mismunandi Git útibú getur haft sömu undirskriftina. En werf mun koma í veg fyrir að skyndiminni sem tengist mismunandi greinum sé notað á milli þessara útibúa, jafnvel þótt undirskriftirnar passi.

→ Skjöl.

Nýtt reiknirit til að búa til og vista stig í sviðsgeymslunni

Ef, þegar stig eru valin úr skyndiminni, finnur werf ekki viðeigandi stig, þá er ferlið við að setja saman nýtt stig hafið.

Athugaðu að mörg ferli (á einum eða fleiri vélum) geta byrjað að byggja upp sama stig á um það bil sama tíma. Werf notar bjartsýnt lokunaralgrím stig-geymsla á því augnabliki sem nýsöfnuðu myndina er vistuð inn stig-geymsla. Á þennan hátt, þegar nýja sviðsbyggingin er tilbúin, werf blokkir stig-geymsla og vistar þar nýsöfnuð mynd aðeins ef hentug mynd er ekki lengur til þar (með undirskrift og öðrum breytum - sjá nýja reikniritið til að velja stig úr skyndiminni).

Nýsamsett mynd er tryggt að hafa einstakt auðkenni með TIMESTAMP_MILLISEC (sjá nýtt snið fyrir nafngiftir). Í tilfelli í stig-geymsla viðeigandi mynd verður fundin, werf mun henda nýsamsettu myndinni og mun nota myndina úr skyndiminni.

Með öðrum orðum: fyrsta ferlið til að klára að byggja myndina (það hraðasta) fær réttinn til að geyma hana í áföngum-geymslu (og þá er það þessi eina mynd sem verður notuð fyrir allar smíðin). Hægt byggingarferli mun aldrei hindra hraðari ferli frá því að vista byggingarniðurstöður núverandi stigs og halda áfram í næstu byggingu.

→ Skjöl.

Bættur árangur Dockerfile smiðir

Í augnablikinu samanstendur leiðsla þrepa fyrir mynd sem byggð er úr Dockerfile af einu þrepi - dockerfile. Við útreikning á undirskriftinni er eftirlitssumma skránna reiknuð út context, sem verður notað við samsetningu. Áður en þessi umbót fór fram fór werf endurkvæmt í gegnum allar skrár og fékk eftirlitsummu með því að leggja saman samhengi og stillingu hverrar skráar. Frá og með v1.1 getur werf notað reiknaðar eftirlitssummur sem eru geymdar í Git geymslu.

Reikniritið byggir á git ls-tré. Reikniritið tekur mið af færslum í .dockerignore og fer yfir skráartréð aðeins endurkvæmt þegar nauðsyn krefur. Þannig höfum við aftengst lestri skráarkerfisins og því hversu háð reikniritinu er stærð context er ekki marktækur.

Reikniritið athugar einnig órakaðar skrár og, ef nauðsyn krefur, tekur þær með í reikninginn.

Bætt afköst við innflutning á skrám

Útgáfur af werf v1.1 nota rsync miðlara þegar flytja inn skrár úr gripum og myndum. Áður var innflutningur gerður í tveimur skrefum með því að nota möppufestingu frá hýsingarkerfinu.

Afköst innflutnings á macOS takmarkast ekki lengur af Docker bindi og innflutningi lýkur á sama tíma og Linux og Windows.

Efnismiðað merking

Werf v1.1 styður svokallaða merkingu eftir myndefni - innihaldsmiðaða merkingu. Merki Docker myndanna sem myndast fer eftir innihaldi þessara mynda.

Þegar skipunin er keyrð werf publish --tags-by-stages-signature eða werf ci-env --tagging-strategy=stages-signature birtar myndir af svokölluðum sviðsáskrift mynd. Hver mynd er merkt með eigin undirskrift á stigum þessarar myndar, sem er reiknuð út eftir sömu reglum og venjuleg undirskrift hvers stigs fyrir sig, en er almennt auðkenni myndarinnar.

Undirskrift myndstiganna fer eftir:

  1. innihald þessarar myndar;
  2. sögu Git breytinganna sem leiddu til þessa efnis.

Git geymsla hefur alltaf dummy commits sem breyta ekki innihaldi myndskránna. Til dæmis, skuldbindingar með aðeins athugasemdum eða sameiningu skuldbindingar, eða skuldbindingar sem breyta þessum skrám í Git sem verða ekki fluttar inn í myndina.

Þegar innihaldsbundin merking er notuð leysast vandamálin við óþarfa endurræsingu á forritahringjum í Kubernetes vegna breytinga á nafni myndarinnar, jafnvel þótt innihald myndarinnar hafi ekki breyst. Við the vegur, þetta er ein af ástæðunum sem kemur í veg fyrir að geyma margar örþjónustur af einu forriti í einni Git geymslu.

Einnig er innihaldsbundin merking áreiðanlegri merkingaraðferð en merking á Git greinum, vegna þess að innihald myndanna sem myndast er ekki háð röðinni sem leiðslur eru framkvæmdar í CI kerfinu til að setja saman margar skuldbindingar af sömu grein.

Það er mikilvægt: frá og með núna stig-undirskrift - Er eina ráðlagða merkingaraðferðin. Það verður sjálfgefið notað í skipuninni werf ci-env (nema þú tilgreinir sérstaklega annað merkingarkerfi).

→ Skjöl. Sérstakt rit verður einnig varið til þessa eiginleika. UPPFÆRT (3. apríl): Grein með smáatriðum birt.

Skráningarstig

Notandinn hefur nú tækifæri til að stjórna úttakinu, stilla skráningarstigið og vinna með villuleitarupplýsingar. Valkostum bætt við --log-quiet, --log-verbose, --log-debug.

Sjálfgefið er að úttakið inniheldur lágmarksupplýsingar:

werf 1.1 útgáfa: endurbætur á byggingaraðilanum í dag og áætlanir fyrir framtíðina

Þegar þú notar margorða úttak (--log-verbose) þú getur séð hvernig werf virkar:

werf 1.1 útgáfa: endurbætur á byggingaraðilanum í dag og áætlanir fyrir framtíðina

Ítarleg framleiðsla (--log-debug), auk werf villuleitarupplýsinga, inniheldur einnig annála yfir notuð bókasöfn. Til dæmis geturðu séð hvernig samskipti við Docker Registry eiga sér stað og einnig skráð staðina þar sem verulegum tíma er varið:

werf 1.1 útgáfa: endurbætur á byggingaraðilanum í dag og áætlanir fyrir framtíðina

Frekari áætlanir

Attention! Valmöguleikarnir sem lýst er hér að neðan eru merktir v1.1 verða fáanlegar í þessari útgáfu, margar þeirra á næstunni. Uppfærslur munu koma með sjálfvirkum uppfærslum þegar þú notar multiwerf. Þessir eiginleikar hafa ekki áhrif á stöðuga hluta v1.1 aðgerða; útlit þeirra mun ekki krefjast handvirkrar inngrips notenda í núverandi stillingar.

Fullur stuðningur við ýmsar Docker Registry útfærslur (NÝTT)

Markmiðið er að notandinn noti sérsniðna útfærslu án takmarkana við notkun werf.

Eins og er höfum við bent á eftirfarandi sett af lausnum sem við ætlum að tryggja fullan stuðning fyrir:

  • Sjálfgefið (safn/skrá)*,
  • AWS ECR
  • Azure*,
  • Docker Hub
  • GCR*,
  • GitHub pakkar
  • GitLab Registry*,
  • Höfn*,
  • Quay.

Lausnir sem nú eru að fullu studdar af werf eru merktar með stjörnu. Fyrir aðra er stuðningur, en með takmörkunum.

Hægt er að greina tvö megin vandamál:

  • Sumar lausnir styðja ekki fjarlægingu merkja með Docker Registry API, sem kemur í veg fyrir að notendur geti notað sjálfvirka hreinsun werf. Þetta á við um AWS ECR, Docker Hub og GitHub pakka.
  • Sumar lausnir styðja hvorki svokallaðar nesd repositories (Docker Hub, GitHub Packages og Quay) eða gera það, en notandinn verður að búa þær til handvirkt með því að nota UI eða API (AWS ECR).

Við ætlum að leysa þessi og önnur vandamál með því að nota innfædd API lausnanna. Þetta verkefni felur einnig í sér að ná yfir alla hringrás vinnslustöðvarinnar með prófunum fyrir hvert þeirra.

Dreifð myndbygging (↑)

  • Útgáfa: v1.2 v1.1 (forgangurinn fyrir innleiðingu þessa eiginleika hefur verið aukinn)
  • Dagsetningar: mars-apríl mars
  • Tölublað

Sem stendur er aðeins hægt að nota werf v1.0 og v1.1 á einum sérstökum hýsil fyrir aðgerðir við að byggja og birta myndir og dreifa forritinu til Kubernetes.

Til að opna möguleika á dreifðri vinnu werf, þegar smíði og dreifing á forritum í Kubernetes er hleypt af stokkunum á nokkrum handahófskenndum vélum og þessir vélar vista ekki ástand sitt á milli bygginga (tímabundinna hlaupara), þarf werf að innleiða getu til að nota Docker Registry sem sviðsverslun.

Áður, þegar werf verkefnið var enn kallað dapp, hafði það slíkt tækifæri. Hins vegar höfum við lent í ýmsum vandamálum sem þarf að taka tillit til þegar þessi virkni er innleidd í werf.

Athugið. Þessi eiginleiki krefst þess ekki að safnarinn vinni inni í Kubernetes belgjum vegna þess Til að gera þetta þarftu að losna við ósjálfstæðin á staðbundnum Docker þjóninum (í Kubernetes pod er enginn aðgangur að staðbundnum Docker þjóninum, vegna þess að ferlið sjálft er í gangi í gámi og werf styður ekki og mun ekki styðja vinna með Docker netþjóninn yfir netið). Stuðningur við að keyra Kubernetes verður útfærður sérstaklega.

Opinber stuðningur við GitHub Actions (NÝTT)

Inniheldur werf skjöl (kafla tilvísun и leiðbeina), sem og opinberu GitHub Action fyrir að vinna með werf.

Að auki mun það gera werf kleift að vinna á skammvinnum hlaupurum.

Vélbúnaður notendasamskipta við CI kerfið mun byggjast á því að setja merkimiða á dráttarbeiðnir til að hefja ákveðnar aðgerðir til að byggja/útbúa forritið.

Staðbundin þróun og dreifing forrita með werf (↓)

  • Útgáfa: v1.1
  • Dagsetningar: janúar-febrúar apríl
  • Tölublað

Meginmarkmiðið er að ná einni sameinðri stillingu til að dreifa forritum bæði á staðnum og í framleiðslu, án flókinna aðgerða, úr kassanum.

werf þarf einnig að hafa rekstrarham þar sem þægilegt er að breyta forritskóðanum og fá strax endurgjöf frá keyrandi forritinu fyrir villuleit.

Nýtt hreinsunaralgrím (NÝTT)

Í núverandi útgáfu af werf v1.1 í málsmeðferðinni cleanup Það er ekkert kveðið á um að þrífa myndir fyrir innihaldsbundið merkingarkerfi - þessar myndir munu safnast upp.

Einnig notar núverandi útgáfa af werf (v1.0 og v1.1) mismunandi hreinsunarstefnur fyrir myndir sem birtar eru undir merkingarkerfum: Git branch, Git tag eða Git commit.

Nýtt reiknirit til að þrífa myndir byggt á sögu skuldbindinga í Git, sameinað fyrir öll merkingarkerfi, hefur verið fundið upp:

  • Geymið ekki fleiri en N1 myndir sem tengjast N2 nýjustu skuldbindingunum fyrir hvert git HEAD (útibú og merki).
  • Geymið ekki fleiri en N1 sviðsmyndir sem tengjast N2 nýjustu skuldbindingunum fyrir hvert git HEAD (útibú og merki).
  • Geymdu allar myndir sem eru notaðar í hvaða Kubernetes klasatilföngum sem er (öll kube samhengi stillingaskrárinnar og nafnasvæði eru skannaðar; þú getur takmarkað þessa hegðun með sérstökum valkostum).
  • Geymdu allar myndir sem eru notaðar í uppsetningarskrár tilfanga sem eru vistaðar í Helm útgáfum.
  • Hægt er að eyða mynd ef hún er ekki tengd neinum HEAD frá git (til dæmis vegna þess að samsvarandi HEAD sjálfu var eytt) og er ekki notuð í neinum upplýsingum í Kubernetes klasanum og í Helm útgáfum.

Samhliða myndbygging (↓)

  • Útgáfa: v1.1
  • Dagsetningar: janúar-febrúar apríl*

Núverandi útgáfa af werf safnar myndunum og gripunum sem lýst er í werf.yaml, í röð. Nauðsynlegt er að samsíða ferlið við að setja saman sjálfstæða stig mynda og gripa, auk þess að veita þægilegan og fræðandi framleiðsla.

* Athugið: fresturinn hefur verið færður til vegna aukins forgangs fyrir innleiðingu dreifðrar samsetningar, sem mun bæta við fleiri láréttum stærðargetu, sem og notkun werf með GitHub Actions. Samhliða samsetning er næsta hagræðingarskref, sem veitir lóðréttan sveigjanleika þegar sett er saman eitt verkefni.

Umskipti yfir í stýri 3 (↓)

  • Útgáfa: v1.2
  • Dagsetningar: febrúar-mars maí*

Inniheldur flutning yfir í nýjan kóðagrunn Hjálmur 3 og sannað, þægileg leið til að flytja núverandi uppsetningar.

* Athugið: að skipta yfir í Helm 3 mun ekki bæta mikilvægum eiginleikum við werf, vegna þess að allir lykileiginleikar Helm 3 (3-vega-samruna og án stýris) eru þegar innleiddir í werf. Þar að auki hefur werf viðbótaraðgerðir til viðbótar þeim sem tilgreindar eru. Hins vegar er þessi umskipti áfram í áætlunum okkar og verður hrint í framkvæmd.

Jsonnet til að lýsa Kubernetes stillingum (↓)

  • Útgáfa: v1.2
  • Dagsetningar: janúar-febrúar apríl-maí

Werf mun styðja stillingarlýsingar fyrir Kubernetes á Jsonnet sniði. Á sama tíma verður werf áfram samhæft við Helm og valið verður um lýsingarsnið.

Ástæðan er sú að Go sniðmát, að mati margra, hafa mikla aðgangshindrun og skiljanleiki kóðans á þessum sniðmátum er einnig fyrir þrifum.

Einnig er verið að skoða möguleikann á að kynna önnur Kubernetes stillingarlýsingarkerfi (til dæmis Kustomize).

Að vinna í Kubernetes (↓)

  • Útgáfa: v1.2
  • Dagsetningar: apríl-maí maí-júní

Markmið: Gakktu úr skugga um að myndir séu byggðar og að forritið sé afhent með því að nota hlaupara í Kubernetes. Þeir. Hægt er að búa til nýjar myndir, birta, hreinsa og dreifa beint úr Kubernetes belgjum.

Til að útfæra þessa möguleika þarftu fyrst að geta smíðað dreifðar myndir (sjá lið hér að ofan).

Það krefst einnig stuðnings fyrir rekstrarham byggingaraðila án Docker netþjóns (þ.e. Kaniko-lík bygging eða innbyggð notendarými).

Werf mun styðja að byggja á Kubernetes, ekki aðeins með Dockerfile, heldur einnig með Stapel smiðnum sínum með stigvaxandi endurbyggingum og Ansible.

Skref í átt að opinni þróun

Við elskum samfélagið okkar (GitHub, Telegram) og við viljum að fleiri og fleiri hjálpi til við að gera werf betri, skilji í hvaða átt við erum að fara og taki þátt í þróuninni.

Nokkuð nýlega var ákveðið að skipta yfir í GitHub verkefnisstjórnir í því skyni að sýna vinnuferli teymis okkar. Nú geturðu séð áætlanir strax, sem og núverandi vinnu á eftirfarandi sviðum:

Mikið hefur verið unnið með mál:

  • Fjarlægði óviðkomandi.
  • Þær sem fyrir eru eru settar á eitt snið, með nægilegum fjölda upplýsinga og smáatriðum.
  • Ný blöð með hugmyndum og tillögum hafa bæst við.

Hvernig á að virkja útgáfu v1.1

Útgáfan er nú fáanleg í rás 1.1 ea (í rásum stöðugt и grjótharður útgáfur munu hins vegar birtast þegar stöðugleiki á sér stað ea sjálft er nú þegar nógu stöðugt til notkunar, vegna þess að fór í gegnum sundin alfa и beta). Virkjað í gegnum multiwerf á eftirfarandi hátt:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Ályktun

Nýi sviðsgeymsluarkitektúrinn og hagræðingar byggingaraðila fyrir Stapel og Dockerfile smiðirnir opna möguleika á að innleiða dreifðar og samhliða byggingar í werf. Þessir eiginleikar munu brátt birtast í sömu v1.1 útgáfu og verða sjálfkrafa tiltækir í gegnum sjálfvirka uppfærslukerfið (fyrir notendur multiwerf).

Í þessari útgáfu hefur merkingaraðferð sem byggir á myndefni verið bætt við - innihaldsmiðaða merkingu, sem er orðin sjálfgefin stefna. Aðalskipanaskráin hefur einnig verið endurunnin: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Næsta mikilvæga skrefið er að bæta við dreifðum samkomum. Dreifðar smíðir hafa fengið hærri forgang en samhliða smíði síðan v1.0 vegna þess að þær bæta meira gildi við werf: lóðrétt stærðarstærð bygginga og stuðningur við skammvinn smiði í ýmsum CI/CD kerfum, sem og getu til að gera opinberan stuðning fyrir GitHub Actions . Þess vegna var innleiðingarfrestum samhliða þingum færðar til. Hins vegar er unnið að því að innleiða báða möguleikana eins fljótt og auðið er.

Fylgstu með fréttum! Og ekki gleyma að heimsækja okkur kl GitHubað búa til mál, finna það sem fyrir er og bæta við plús, búa til PR eða einfaldlega fylgjast með þróun verkefnisins.

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Bæta við athugasemd