is ons oopbron GitOps CLI-hulpmiddel vir die bou en aflewering van toepassings aan Kubernetes. Soos beloof, was die begin van die toevoeging van nuwe kenmerke tot werf en die hersiening van tradisionele benaderings. Nou is ons bly om vrystelling v1.1 aan te bied, wat 'n groot stap in ontwikkeling en 'n grondslag vir die toekoms is versamelaar werf. Die weergawe is tans beskikbaar in .
Die basis van die vrystelling is die nuwe argitektuur van die verhoogberging en optimalisering van die werk van beide versamelaars (vir Stapel en Dockerfile). Die nuwe bergingsargitektuur maak die moontlikheid oop om verspreide samestellings van veelvuldige gashere en parallelle samestellings op dieselfde gasheer te implementeer.
Optimalisering van werk sluit in om ontslae te raak van onnodige berekeninge in die stadium van die berekening van stadiumhandtekeninge en die verandering van die meganismes vir die berekening van lêerkontrolesomme na meer doeltreffende. Hierdie optimalisering verminder die gemiddelde tyd van projekbou met behulp van werf. En ledige bouwerk, wanneer alle stadiums in die kas bestaan stadiums-berging, is nou baie vinnig. In die meeste gevalle sal die herbegin van die bou minder as 1 sekonde neem! Dit geld ook vir prosedures vir die verifiëring van stadiums in die proses van spanne se werk. werf deploy и werf run.
Ook in hierdie vrystelling het 'n strategie vir die merk van beelde volgens inhoud verskyn - inhoud-gebaseerde tagging, wat nou by verstek geaktiveer is en die enigste een wat aanbeveel word.
Kom ons kyk van naderby na die sleutelinnovasies in werf v1.1, en vertel terselfdertyd van planne vir die toekoms.
Wat het verander in werf v1.1?
Nuwe verhoognaam-formaat en algoritme om stadiums uit die kas te kies
Nuwe verhoognaam generasie reël. Nou genereer elke verhoogbou 'n unieke verhoognaam, wat uit 2 dele bestaan: 'n handtekening (soos dit was in v1.0) plus 'n unieke tydelike identifiseerder.
Byvoorbeeld, die volledige verhoogbeeldnaam kan soos volg lyk:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...of in die algemeen:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
hier:
-
SIGNATUREis 'n verhooghandtekening, wat die identifiseerder van die verhooginhoud verteenwoordig en afhang van die geskiedenis van wysigings in Git wat tot hierdie inhoud gelei het; -
TIMESTAMP_MILLISECis 'n gewaarborgde unieke beeld-identifiseerder wat gegenereer word wanneer 'n nuwe beeld gebou word.
Die algoritme vir die keuse van stadiums uit die kas is gebaseer op die nagaan van die verhouding van Git commits:
- Werf bereken die handtekening van 'n sekere stadium.
- В stadiums-berging Daar kan verskeie stadiums vir 'n gegewe handtekening wees. Werf kies alle stadiums wat by die handtekening pas.
- As die huidige stadium aan Git gekoppel is (git-argief, pasgemaakte stadium met Git-patches:
install,beforeSetup,setup; of git-latest-patch), dan kies werf slegs daardie stadiums wat geassosieer word met 'n commit wat 'n voorouer is van die huidige commit (waarvoor die bou genoem word). - Uit die oorblywende geskikte stadiums word een gekies - die oudste volgens skeppingsdatum.
'n Verhoog vir verskillende Git-takke kan dieselfde handtekening hê. Maar werf sal verhoed dat die kas wat met verskillende takke geassosieer word, tussen hierdie takke gebruik word, selfs al stem die handtekeninge ooreen.
.
Nuwe algoritme vir die skep en stoor van stadiums in die verhoogberging
As werf, wanneer fases uit die kas gekies word, nie 'n geskikte stadium vind nie, word die proses van samestelling van 'n nuwe stadium begin.
Let daarop dat verskeie prosesse (op een of meer gashere) dieselfde stadium op ongeveer dieselfde tyd kan begin bou. Werf gebruik 'n optimistiese blokkeeralgoritme stadiums-berging op die oomblik dat die vars versamelde beeld gestoor word stadiums-berging. Op hierdie manier, wanneer die nuwe verhoogbou gereed is, werf blokke stadiums-berging en stoor 'n vars versamelde beeld slegs daar as 'n geskikte beeld nie meer daar bestaan nie (deur handtekening en ander parameters - sien die nuwe algoritme om stadiums uit die kas te kies).
'n Nuut saamgestelde prent het gewaarborg 'n unieke identifiseerder deur TIMESTAMP_MILLISEC (sien nuwe verhoognaam-formaat). In geval in stadiums-berging 'n geskikte prent sal gevind word, werf sal die vars saamgestelde prent weggooi en die prent van die kas gebruik.
Met ander woorde: die eerste proses om die prent klaar te bou (die vinnigste een) sal die reg kry om dit in stadiums-berging te stoor (en dan is dit hierdie enkele prent wat vir alle bouwerk gebruik sal word). 'n Stadige bouproses sal nooit 'n vinniger proses blokkeer om die bouresultate van die huidige stadium te stoor en aan te beweeg na die volgende bou nie.
.
Verbeterde Dockerfile-bouerprestasie
Op die oomblik bestaan die pyplyn van stadiums vir 'n beeld wat uit 'n Dockerfile gebou is uit een stadium - dockerfile. Wanneer die handtekening bereken word, word die kontrolesom van die lêers bereken context, wat tydens samestelling gebruik sal word. Voor hierdie verbetering het werf rekursief deur alle lêers gestap en 'n kontrolesom verkry deur die konteks en modus van elke lêer op te som. Vanaf v1.1 kan werf berekende kontrolesomme gebruik wat in 'n Git-bewaarplek gestoor is.
Die algoritme is gebaseer op . Die algoritme neem rekords in .dockerignore en deurkruis die lêerboom slegs rekursief wanneer dit nodig is. Ons het dus ontkoppel van die lees van die lêerstelsel, en die afhanklikheid van die algoritme op die grootte context is nie betekenisvol nie.
Die algoritme kontroleer ook ongespoorde lêers en neem dit, indien nodig, in die kontrolesom in ag.
Verbeterde werkverrigting tydens die invoer van lêers
Weergawes van werf v1.1 gebruik 'n rsync-bediener wanneer . Voorheen is invoer in twee stappe gedoen met behulp van 'n gidsmontering vanaf die gasheerstelsel.
Invoerwerkverrigting op macOS word nie meer deur Docker-volumes beperk nie, en invoere voltooi in dieselfde tyd as Linux en Windows.
Inhoud-gebaseerde tagging
Werf v1.1 ondersteun sogenaamde tagging deur beeldinhoud - inhoud-gebaseerde tagging. Die etikette van die resulterende Docker-beelde hang af van die inhoud van hierdie beelde.
Wanneer die opdrag uitgevoer word werf publish --tags-by-stages-signature of werf ci-env --tagging-strategy=stages-signature gepubliseerde beelde van die sg verhoog handtekening beeld. Elke beeld is gemerk met sy eie handtekening van die stadiums van hierdie beeld, wat volgens dieselfde reëls as die gewone handtekening van elke stadium afsonderlik bereken word, maar is 'n algemene identifiseerder van die beeld.
Die handtekening van die beeldstadiums hang af van:
- die inhoud van hierdie beeld;
- geskiedenis van die Git-veranderinge wat tot hierdie inhoud gelei het.
'n Git-bewaarplek het altyd dummy-commits wat nie die inhoud van die beeldlêers verander nie. Byvoorbeeld, commits met slegs opmerkings of merge commits, of commits wat daardie lêers in Git verander wat nie in die prent ingevoer sal word nie.
Wanneer inhoudgebaseerde tagging gebruik word, word die probleme van onnodige herbegin van toepassingspeule in Kubernetes as gevolg van veranderinge in die prentnaam opgelos, selfs al het die inhoud van die prent nie verander nie. Terloops, dit is een van die redes wat verhoed dat baie mikrodienste van een toepassing in 'n enkele Git-bewaarplek gestoor word.
Ook, inhoud-gebaseerde tagging is 'n meer betroubare merker metode as tagging op Git takke, omdat die inhoud van die gevolglike beelde nie afhang van die volgorde waarin pyplyne uitgevoer word in die CI stelsel vir die samestelling van veelvuldige commits van dieselfde tak.
Dit is belangrik om: van nou af stadiums-handtekening - Is die enigste aanbevole merkstrategie. Dit sal by verstek in die opdrag gebruik word werf ci-env (tensy jy 'n ander merkskema uitdruklik spesifiseer).
. 'n Aparte publikasie sal ook aan hierdie kenmerk gewy word. OPGEDATEER (3 April): Artikel met besonderhede .
Meldvlakke
Die gebruiker het nou die geleentheid om die uitset te beheer, die logvlak te stel en met ontfoutingsinligting te werk. Opsies bygevoeg --log-quiet, --log-verbose, --log-debug.
By verstek bevat die uitvoer die minimum inligting:
By die gebruik van verbose uitvoer (--log-verbose) jy kan sien hoe werf werk:
Gedetailleerde uitset (--log-debug), benewens werf ontfoutingsinligting, bevat ook logs van gebruikte biblioteke. U kan byvoorbeeld sien hoe interaksie met die Docker-register plaasvind, en ook die plekke aanteken waar 'n aansienlike hoeveelheid tyd spandeer word:
Toekomsplanne
Внимание! Die opsies wat hieronder beskryf word, is gemerk v1.1 sal beskikbaar wees in hierdie weergawe, baie van hulle in die nabye toekoms. Opdaterings sal via outo-opdaterings kom . Hierdie kenmerke beïnvloed nie die stabiele deel van v1.1-funksies nie; hul voorkoms sal nie handmatige gebruikersingryping in bestaande konfigurasies vereis nie.
Volledige ondersteuning vir verskeie Docker Registry-implementerings (NUUT)
- Weergawe: v1.1
- Datums: Maart
Die doel is dat die gebruiker 'n pasgemaakte implementering sonder beperkings gebruik wanneer werf gebruik word.
Tans het ons die volgende stel oplossings geïdentifiseer waarvoor ons volle ondersteuning gaan waarborg:
- Verstek (biblioteek/register)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub-pakkette
- GitLab-register*,
- Hawe*,
- Kaai.
Oplossings wat tans ten volle deur werf ondersteun word, is met 'n asterisk gemerk. Vir ander is daar ondersteuning, maar met beperkings.
Twee hoofprobleme kan geïdentifiseer word:
- Sommige oplossings ondersteun nie etiketverwydering deur die Docker Registry API te gebruik nie, wat verhoed dat gebruikers werf se outomatiese skoonmaak gebruik. Dit geld vir AWS ECR, Docker Hub en GitHub-pakkette.
- Sommige oplossings ondersteun nie sogenaamde geneste bewaarplekke (Docker Hub, GitHub-pakkette en Quay) of doen nie, maar die gebruiker moet dit met die hand skep deur die UI of API (AWS ECR) te gebruik.
Ons gaan hierdie en ander probleme oplos deur inheemse API's van die oplossings te gebruik. Hierdie taak sluit ook in om die volle siklus van werfbedryf te dek met toetse vir elkeen van hulle.
Verspreide beeldbou (↑)
- Weergawe: v1.2 v1.1 (die prioriteit vir die implementering van hierdie kenmerk is verhoog)
- Datums: Maart-April Maart
Op die oomblik kan werf v1.0 en v1.1 slegs op een toegewyde gasheer gebruik word vir operasies om beelde te bou en te publiseer en die toepassing na Kubernetes te ontplooi.
Om die moontlikhede van verspreide werk van werf oop te maak, wanneer die bou en ontplooiing van toepassings in Kubernetes op verskeie arbitrêre gashere geloods word en hierdie gashere nie hul toestand tussen geboue (tydelike hardlopers) red nie, word van werf vereis om die vermoë om te gebruik te implementeer die Docker Registry as 'n verhoogwinkel.
Voorheen, toe die werfprojek nog dapp genoem is, het dit so 'n geleentheid gehad. Ons het egter 'n aantal kwessies teëgekom wat in ag geneem moet word wanneer hierdie funksionaliteit in werf geïmplementeer word.
Let daarop. Hierdie kenmerk vereis nie dat die versamelaar binne Kubernetes-peule moet werk nie, want Om dit te doen, moet jy ontslae raak van die afhanklikheid van die plaaslike Docker-bediener (in die Kubernetes-pod is daar geen toegang tot die plaaslike Docker-bediener nie, want die proses self loop in 'n houer, en werf ondersteun nie en sal nie werk met die Docker-bediener oor die netwerk). Ondersteuning vir die bestuur van Kubernetes sal afsonderlik geïmplementeer word.
Amptelike ondersteuning vir GitHub Actions (NUUT)
- Weergawe: v1.1
- Datums: Maart
Sluit werfdokumentasie in (afdelings verwysing и lei), asook die amptelike GitHub-aksie om met werf te werk.
Boonop sal dit werf in staat stel om op kortstondige hardlopers te werk.
Die meganika van gebruikersinteraksie met die CI-stelsel sal gebaseer wees op die plasing van etikette op trekversoeke om sekere aksies te begin om die toepassing te bou/ontplooi.
Plaaslike ontwikkeling en ontplooiing van toepassings met werf (↓)
- Weergawe: v1.1
- Datums: Januarie-Februarie April
Die hoofdoel is om 'n enkele verenigde konfigurasie te bereik vir die implementering van toepassings beide plaaslik en in produksie, sonder komplekse aksies, uit die boks.
Daar word ook van werf verwag om 'n bedryfsmodus te hê waarin dit gerieflik sal wees om die toepassingskode te wysig en onmiddellik terugvoer van die lopende toepassing vir ontfouting te ontvang.
Nuwe skoonmaakalgoritme (NUUT)
- Weergawe: v1.1
- Datums: April
In die huidige weergawe van werf v1.1 in die prosedure cleanup Daar is geen voorsiening vir die skoonmaak van beelde vir die inhoudgebaseerde merkerskema nie – hierdie beelde sal ophoop.
Die huidige weergawe van werf (v1.0 en v1.1) gebruik ook verskillende skoonmaakbeleide vir beelde wat onder merkskemas gepubliseer is: Git-tak, Git-merk of Git-commit.
'n Nuwe algoritme vir die skoonmaak van beelde gebaseer op die geskiedenis van commits in Git, verenig vir alle merkerskemas, is uitgevind:
- Hou nie meer as N1 beelde wat verband hou met die N2 mees onlangse commits vir elke git HEAD (takke en etikette).
- Berg nie meer as N1 verhoogbeelde wat verband hou met die N2 mees onlangse commits vir elke git HEAD (takke en etikette).
- Stoor alle beelde wat in enige Kubernetes-klusterhulpbronne gebruik word (alle kube-kontekste van die konfigurasielêer en naamruimtes word geskandeer; jy kan hierdie gedrag met spesiale opsies beperk).
- Stoor alle beelde wat gebruik word in hulpbronkonfigurasiemanifeste wat in Helm-vrystellings gestoor is.
- 'n Prent kan uitgevee word as dit nie met enige HEAD van git geassosieer word nie (byvoorbeeld omdat die ooreenstemmende HEAD self uitgevee is) en nie in enige manifeste in die Kubernetes-groepering en in Helm-vrystellings gebruik word nie.
Parallelle beeldbou (↓)
- Weergawe: v1.1
- Datums: Januarie-Februarie April*
Die huidige weergawe van werf versamel die beelde en artefakte wat in beskryf word werf.yaml, opeenvolgend. Dit is nodig om die proses van samestelling van onafhanklike stadiums van beelde en artefakte te paralleliseer, sowel as om gerieflike en insiggewende uitvoer te verskaf.
* Let wel: die sperdatum is verskuif as gevolg van verhoogde prioriteit vir die implementering van verspreide samestelling, wat meer horisontale skaalvermoë sal byvoeg, sowel as die gebruik van werf met GitHub Actions. Parallelle samestelling is die volgende optimaliseringstap, wat vertikale skaalbaarheid bied wanneer een projek saamgestel word.
Oorgang na Roer 3 (↓)
- Weergawe: v1.2
- Datums: Februarie-Maart Mei*
Sluit migrasie na nuwe kodebasis in en 'n bewese, gerieflike manier om bestaande installasies te migreer.
* Let wel: oorskakeling na Helm 3 sal nie noemenswaardige kenmerke by werf voeg nie, want al die sleutelkenmerke van Helm 3 (3-rigting-samevoeging en geen dissel) is reeds in werf geïmplementeer. Boonop het werf bykomend tot die aangeduide. Hierdie oorgang bly egter in ons planne en sal geïmplementeer word.
Jsonnet vir die beskrywing van Kubernetes-konfigurasie (↓)
- Weergawe: v1.2
- Datums: Januarie-Februarie April-Mei
Werf sal konfigurasiebeskrywings vir Kubernetes in Jsonnet-formaat ondersteun. Terselfdertyd sal werf versoenbaar bly met Helm en daar sal 'n keuse van beskrywingsformaat wees.
Die rede is dat Go-sjablone, volgens baie mense, 'n hoë toegangsversperring het, en die verstaanbaarheid van die kode van hierdie sjablone ly ook daaronder.
Die moontlikheid om ander Kubernetes-konfigurasiebeskrywingstelsels (byvoorbeeld Kustomize) bekend te stel, word ook oorweeg.
Werk binne Kubernetes (↓)
- Weergawe: v1.2
- Datums: April-Mei Mei-Junie
Doelwit: Maak seker dat beelde gebou word en dat die toepassing afgelewer word deur hardlopers in Kubernetes te gebruik. Dié. Nuwe beelde kan direk vanaf Kubernetes-peule gebou, gepubliseer, skoongemaak en ontplooi word.
Om hierdie vermoë te implementeer, moet jy eers verspreide beelde kan bou (sien punt hierbo).
Dit vereis ook ondersteuning vir die bouer se bedryfsmodus sonder 'n Docker-bediener (dit wil sê Kaniko-agtige bou of ingeboude gebruikersruimte).
Werf sal bou op Kubernetes ondersteun nie net met Dockerfile nie, maar ook met sy Stapel-bouer met inkrementele herbou en Ansible.
'n Stap na oop ontwikkeling
Ons is lief vir ons gemeenskap (, ) en ons wil hê meer en meer mense moet help om werf beter te maak, die rigting waarin ons beweeg te verstaan en aan die ontwikkeling deel te neem.
Heel onlangs is besluit om oor te skakel na om die werksproses van ons span te openbaar. Nou kan jy die onmiddellike planne sien, sowel as huidige werk in die volgende gebiede:
- ;
- ;
- ;
- .
Baie werk is gedoen met kwessies:
- Verwyder irrelevantes.
- Die bestaandes word na 'n enkele formaat gebring, met 'n voldoende aantal besonderhede en besonderhede.
- Nuwe uitgawes met idees en voorstelle is bygevoeg.
Hoe om weergawe v1.1 te aktiveer
Die weergawe is tans beskikbaar in (in kanale stabiele и rotsvas vrystellings sal egter verskyn soos stabilisering plaasvind ea self is reeds stabiel genoeg vir gebruik, want deur die kanale gegaan alfa и beta). Geaktiveer op die volgende manier:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Gevolgtrekking
Die nuwe verhoogbergingsargitektuur en boueroptimalisasies vir Stapel- en Dockerfile-bouers maak die moontlikheid oop om verspreide en parallelle bouwerk in werf te implementeer. Hierdie kenmerke sal binnekort in dieselfde v1.1-vrystelling verskyn en sal outomaties beskikbaar word deur die outo-opdateringmeganisme (vir gebruikers ).
In hierdie vrystelling is 'n etiketteringstrategie gebaseer op beeldinhoud bygevoeg - inhoud-gebaseerde tagging, wat die verstekstrategie geword het. Die hoofopdraglogboek is ook herwerk: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Die volgende belangrike stap is om verspreide samestellings by te voeg. Verspreide bouwerk het sedert v1.0 'n hoër prioriteit as parallelle bouwerk geword omdat dit meer waarde tot werf toevoeg: vertikale skaal van bouers en ondersteuning vir kortstondige bouers in verskeie CI/CD-stelsels, asook die vermoë om amptelike ondersteuning vir GitHub Actions te maak . Daarom is die implementeringspertye vir parallelle samestellings verskuif. Ons werk egter daaraan om beide moontlikhede so gou moontlik te implementeer.
Volg die nuus! En moenie vergeet om ons te besoek by om 'n kwessie te skep, vind 'n bestaande een en voeg 'n pluspunt by, skep 'n PR, of kyk bloot na die ontwikkeling van die projek.
PS
Lees ook op ons blog:
- «»
- «»;
- 'n Reeks notas oor innovasies in werf:
- «»;
- «»;
- «»;
- «".
Bron: will.com