is ús iepen boarne GitOps CLI-hulpprogramma foar it bouwen en leverjen fan applikaasjes nei Kubernetes. As tasein, markearre it begjin fan it tafoegjen fan nije funksjes oan werf en it bewurkjen fan tradisjonele oanpak. No binne wy bliid te presintearjen release v1.1, dat is in grutte stap yn ûntwikkeling en in stifting foar de takomst samler werf. De ferzje is op it stuit beskikber yn .
De basis fan 'e release is de nije arsjitektuer fan' e poadium opslach en optimisaasje fan it wurk fan beide samlers (foar Stapel en Dockerfile). De nije opslacharsjitektuer iepenet de mooglikheid om ferdielde gearkomsten fan meardere hosts en parallelle gearkomsten op deselde host te ymplementearjen.
Optimalisaasje fan wurk omfettet it kwytreitsje fan ûnnedige berekkeningen op it poadium fan it berekkenjen fan poadiumhantekeningen en it feroarjen fan de meganismen foar it berekkenjen fan bestânkontrôlesummen nei effisjinter. Dizze optimalisaasje ferleget de gemiddelde tiid fan projektbou mei werf. En idle builds, as alle stadia besteane yn 'e cache stadia-opslach, binne no echt fluch. Yn 'e measte gefallen sil it opnij begjinnen fan de bou minder dan 1 sekonde nimme! Dit jildt ek foar prosedueres foar it ferifiearjen fan stadia yn it proses fan teamwurk. werf deploy и werf run.
Ek yn dizze release ferskynde in strategy foar tagging fan ôfbyldings op ynhâld - ynhâld-basearre tagging, dy't no standert ynskeakele is en de ienige oanrikkemandearre is.
Lit ús de wichtichste ynnovaasjes yn werf v1.1 fan tichterby besjen, en tagelyk fertelle oer plannen foar de takomst.
Wat is feroare yn werf v1.1?
Nije poadiumnamme-opmaak en algoritme foar it selektearjen fan stadia út cache
Nije regel foar generaasje fan poadiumnammen. No genereart elke poadiumbou in unike poadiumnamme, dy't bestiet út 2 dielen: in hantekening (sa't it wie yn v1.0) plus in unike tydlike identifier.
Bygelyks, de namme fan 'e folsleine poadiumôfbylding kin der sa útsjen:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... of yn it algemien:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Hjir:
-
SIGNATUREis in poadiumûndertekening, dy't de identifier fan 'e poadiumynhâld fertsjintwurdiget en hinget ôf fan' e skiednis fan bewurkingen yn Git dy't liede ta dizze ynhâld; -
TIMESTAMP_MILLISECis in garandearre unike ôfbyldingsidentifikaasje dy't wurdt oanmakke op it stuit dat in nije ôfbylding wurdt boud.
It algoritme foar it selektearjen fan stadia út it cache is basearre op it kontrolearjen fan de relaasje fan Git-commits:
- Werf berekkent de hantekening fan in bepaald poadium.
- В stadia-opslach D'r kinne ferskate stadia wêze foar in opjûne hantekening. Werf selektearret alle stadia dy't oerienkomme mei de hantekening.
- As it hjoeddeistige poadium keppele is oan Git (git-argyf, oanpast poadium mei Git-patches:
install,beforeSetup,setup; of git-latest-patch), dan selekteart werf allinich dy stadia dy't ferbûn binne mei in commit dy't in foarfaar is fan 'e hjoeddeistige commit (dêr't de build foar neamd wurdt). - Ut de oerbleaune geskikte stadia wurdt ien selektearre - de âldste troch skepping datum.
In poadium foar ferskate Git-tûken kin deselde hantekening hawwe. Mar werf sil foarkomme dat de cache ferbûn mei ferskate tûken brûkt wurdt tusken dizze tûken, sels as de hantekeningen oerienkomme.
.
Nij algoritme foar it meitsjen en bewarjen fan stadia yn 'e poadiumopslach
As werf by it selektearjen fan poadia út de cache gjin gaadlik poadium fynt, dan wurdt it proses fan it gearstallen fan in nije poadium ynset.
Tink derom dat meardere prosessen (op ien of mear hosts) kinne begjinne mei it bouwen fan itselde poadium op likernôch deselde tiid. Werf brûkt in optimistysk blokkearjende algoritme stadia-opslach op it momint fan it bewarjen fan de nij sammele ôfbylding yn stadia-opslach. Op dizze manier, as de nije poadiumbou klear is, werfblokken stadia-opslach en bewarret dêr in farsk sammele ôfbylding allinnich as in gaadlik byld dêr net mear bestiet (troch hantekening en oare parameters - sjoch it nije algoritme foar it selektearjen fan stadia út 'e cache).
In nij gearstalde ôfbylding wurdt garandearre in unike identifier troch TIMESTAMP_MILLISEC (sjoch nij formaat foar poadiumnamme). Yn gefal yn stadia-opslach in geskikte ôfbylding wurdt fûn, werf smyt de nij gearstalde ôfbylding ôf en sil de ôfbylding út de cache brûke.
Mei oare wurden: it earste proses om it bouwen fan 'e ôfbylding te foltôgjen (de rapste) sil it rjocht krije om it op te slaan yn stadia-opslach (en dan is it dizze ienige ôfbylding dy't brûkt wurdt foar alle builds). In stadich bouproses sil in rapper proses nea blokkearje fan it bewarjen fan de bouresultaten fan it hjoeddeistige stadium en troch te gean nei de folgjende bou.
.
Ferbettere prestaasjes fan Dockerfile-bouwer
Op it stuit bestiet de pipeline fan stadia foar in ôfbylding boud fan in Dockerfile út ien poadium - dockerfile. By it berekkenjen fan de hantekening wurdt de kontrôlesum fan de bestannen berekkene context, dy't brûkt wurde sil by de montage. Foar dizze ferbettering rûn werf rekursyf troch alle triemmen en krige in kontrôlesum troch de kontekst en modus fan elke triem op te tellen. Begjinnend mei v1.1, werf kin brûke berekkene kontrôlesummen opslein yn in Git repository.
It algoritme is basearre op . It algoritme hâldt rekken mei records yn .dockerignore en trochkrúst de triembeam allinich rekursyf as it nedich is. Sa hawwe wy loskeppele fan it lêzen fan it bestânsysteem, en de ôfhinklikens fan it algoritme op 'e grutte context is net fan betsjutting.
It algoritme kontrolearret ek net-trackte bestannen en, as it nedich is, nimt se rekken mei yn 'e kontrôlesum.
Ferbettere prestaasjes by it ymportearjen fan bestannen
Ferzjes fan werf v1.1 brûke in rsync-tsjinner wannear . Eartiids waard ymportearjen yn twa stappen dien mei in mapmount fan it hostsysteem.
Ymportearje prestaasjes op macOS is net langer beheind troch Docker-voluminten, en ymporten kompleet yn deselde tiid as Linux en Windows.
Ynhâld-basearre tagging
Werf v1.1 stipet saneamde tagging troch ôfbylding ynhâld - ynhâld-basearre tagging. De tags fan de resultearjende Docker-ôfbyldings binne ôfhinklik fan de ynhâld fan dizze ôfbyldings.
By it útfieren fan it kommando werf publish --tags-by-stages-signature of werf ci-env --tagging-strategy=stages-signature publisearre bylden fan de saneamde poadium hantekening byld. Elke ôfbylding is tagged mei in eigen hantekening fan 'e stadia fan dizze ôfbylding, dy't wurdt berekkene neffens deselde regels as de reguliere hantekening fan elke poadium apart, mar is in algemiene identifier fan 'e ôfbylding.
De hantekening fan 'e byldstadia hinget ôf fan:
- de ynhâld fan dizze ôfbylding;
- histoarjes fan 'e Git-feroarings dy't liede ta dizze ynhâld.
In Git-repository hat altyd dummy-commits dy't de ynhâld fan 'e ôfbyldingsbestannen net feroarje. Bygelyks, commits mei allinich opmerkingen of commit commits, of commits dy't dizze bestannen yn Git feroarje dy't net sille wurde ymporteare yn 'e ôfbylding.
By it brûken fan ynhâld-basearre tagging wurde de problemen fan ûnnedige opstarten fan applikaasjepods yn Kubernetes fanwege feroaringen yn 'e ôfbyldingsnamme oplost, sels as de ynhâld fan 'e ôfbylding net feroare is. Trouwens, dit is ien fan 'e redenen dy't it opslaan fan in protte mikrotsjinsten fan ien applikaasje yn ien Git-repository foarkomt.
Ek ynhâld-basearre tagging is in betrouberere tagging-metoade dan tagging op Git-tûken, om't de ynhâld fan 'e resultearjende ôfbyldings net ôfhinklik is fan' e folchoarder wêryn pipelines wurde útfierd yn it CI-systeem foar it gearstallen fan meardere commits fan deselde branch.
wichtich: begjinnend fan no stadia-hântekening Is de ienige oanrikkemandearre tagging strategy. It sil standert brûkt wurde yn it kommando werf ci-env (útsein as jo eksplisyt in oar taggingskema oantsjutte).
. Oan dizze funksje sil ek in aparte publikaasje wijd wurde. UPDATED (3 april): Artikel mei details .
Logging nivo's
De brûker hat no de kâns om de útfier te kontrolearjen, it lognivo yn te stellen en te wurkjen mei debuggenynformaasje. Opsjes tafoege --log-quiet, --log-verbose, --log-debug.
Standert befettet de útfier de minimale ynformaasje:
By it brûken fan verbose útfier (--log-verbose) kinne jo sjen hoe't werf wurket:
Detaillearre útfier (--log-debug), befettet neist werf debuggen ynformaasje, ek logs fan brûkte biblioteken. Jo kinne bygelyks sjen hoe't ynteraksje mei it Docker Registry foarkomt, en ek de plakken opnimme wêr't in signifikante hoemannichte tiid wurdt bestege:
Takomstplannen
Wês opsichtich! De opsjes beskreaun hjirûnder binne markearre v1.1 sil beskikber wurde yn dizze ferzje, in protte fan harren yn 'e heine takomst. Updates sille komme fia auto-updates . Dizze funksjes hawwe gjin ynfloed op it stabile diel fan 'e v1.1-funksjes; har uterlik sil gjin hânmjittich yntervinsje fan brûkers nedich wêze yn besteande konfiguraasjes.
Folsleine stipe foar ferskate Docker Registry-ymplemintaasjes (NIJ)
- Ferzje: 1.1
- Data: maart
It doel is dat de brûker sûnder beheiningen in oanpaste ymplemintaasje brûket by it brûken fan werf.
Op it stuit hawwe wy de folgjende set oplossingen identifisearre wêrfoar wy folsleine stipe sille garandearje:
- Standert (bibleteek/register)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub-pakketten
- GitLab Registry*,
- Haven*,
- Quay.
Oplossings dy't op it stuit folslein troch werf stipe wurde binne markearre mei in asterisk. Foar oaren is der stipe, mar mei beheiningen.
Twa haadproblemen kinne identifisearre wurde:
- Guon oplossingen stypje gjin tagferwidering mei de Docker Registry API, wêrtroch brûkers de automatyske skjinmeitsjen fan werf net brûke. Dit is wier foar AWS ECR, Docker Hub, en GitHub-pakketten.
- Guon oplossings stypje gjin saneamde nested repositories (Docker Hub, GitHub Packages and Quay) of do, mar de brûker moat meitsje se mei de hân mei help fan de UI of API (AWS ECR).
Wy sille dizze en oare problemen oplosse mei native API's fan 'e oplossingen. Dizze taak omfettet ek it dekken fan de folsleine syklus fan werfoperaasje mei tests foar elk fan harren.
Ferspraat ôfbylding bouwe (↑)
- Ferzje: v1.2 v1.1 (de prioriteit foar it útfieren fan dizze funksje is ferhege)
- Data: maart-april maart
Op it stuit kinne werf v1.0 en v1.1 allinich brûkt wurde op ien dedicated host foar operaasjes fan it bouwen en publisearjen fan ôfbyldings en it ynsetten fan de applikaasje nei Kubernetes.
Om de mooglikheden fan ferspraat wurk fan werf te iepenjen, as it bouwen en ynsetten fan applikaasjes yn Kubernetes op ferskate willekeurige hosts lansearre wurde en dizze hosts har steat net bewarje tusken builds (tydlike runners), is werf ferplichte om de mooglikheid te brûken de Docker Registry as poadiumwinkel.
Earder, doe't it werfprojekt noch dapp hjitte, hie it sa'n kâns. Wy binne lykwols in oantal problemen tsjinkaam dy't by it útfieren fan dizze funksjonaliteit yn werf rekken holden wurde moatte.
remark. Dizze funksje fereasket de samler net om binnen Kubernetes-pods te wurkjen, om't Om dit te dwaan moatte jo de ôfhinklikens fan 'e lokale Docker-tsjinner kwytreitsje (yn 'e Kubernetes-pod is gjin tagong ta de lokale Docker-tsjinner, om't it proses sels yn in kontener rint, en werf net en sil net stypje wurkje mei de Docker-tsjinner oer it netwurk). Stipe foar it útfieren fan Kubernetes sil apart wurde ymplementearre.
Offisjele stipe foar GitHub Actions (NIJ)
- Ferzje: 1.1
- Data: maart
Omfettet werf dokumintaasje (seksjes referinsje и guide), en ek de offisjele GitHub-aksje foar it wurkjen mei werf.
Dêrnjonken sil it werf mooglik meitsje om te wurkjen oan vlugge rinners.
De meganika fan brûkersynteraksje mei it CI-systeem sil basearre wêze op it pleatsen fan labels op pull-oanfragen om bepaalde aksjes te begjinnen om de applikaasje op te bouwen / út te rollen.
Lokale ûntwikkeling en ynset fan applikaasjes mei werf (↓)
- Ferzje: 1.1
- Data: jannewaris-febrewaris april
It haaddoel is om ien ienige konfiguraasje te berikken foar it ynsetten fan applikaasjes sawol lokaal as yn produksje, sûnder komplekse aksjes, bûten it fak.
werf is ek ferplichte om in bestjoeringsmodus te hawwen wêryn it handich is om de applikaasjekoade te bewurkjen en daliks feedback te ûntfangen fan 'e rinnende applikaasje foar debuggen.
Nije skjinmeitsjen algoritme (NIJ)
- Ferzje: 1.1
- Datums: april
Yn de hjoeddeiske ferzje fan werf v1.1 yn de proseduere cleanup D'r is gjin foarsjenning foar it skjinmeitsjen fan ôfbyldings foar it ynhâld-basearre taggingskema - dizze ôfbyldings sille accumulearje.
Ek de hjoeddeiske ferzje fan werf (v1.0 en v1.1) brûkt ferskillende opromjen belied foar ôfbyldings publisearre ûnder de tagging schemes: Git branch, Git tag of Git commit.
In nij algoritme foar it skjinmeitsjen fan ôfbyldings basearre op 'e skiednis fan commits yn Git, ferienige foar alle tagging-skema's, is útfûn:
- Hâld net mear as N1-ôfbyldings assosjeare mei de meast resinte commits fan N2 foar elke git HEAD (tûken en tags).
- Bewarje net mear as N1-poadiumôfbyldings ferbûn mei de N2 meast resinte commits foar elke git HEAD (tûken en tags).
- Bewarje alle ôfbyldings dy't brûkt wurde yn alle Kubernetes-klusterboarnen (alle kube-konteksten fan it konfiguraasjetriem en nammeromten wurde skansearre; jo kinne dit gedrach beheine mei spesjale opsjes).
- Bewarje alle ôfbyldings dy't wurde brûkt yn boarne konfiguraasje manifesten bewarre yn Helm releases.
- In ôfbylding kin wiske wurde as it net is assosjearre mei in HEAD fan git (bygelyks om't de oerienkommende HEAD sels wiske is) en wurdt net brûkt yn alle manifestaasjes yn it Kubernetes-kluster en yn Helm-releases.
Parallelôfbylding bouwe (↓)
- Ferzje: 1.1
- Data: jannewaris-febrewaris april*
De hjoeddeiske ferzje fan werf sammelet de bylden en artefakten beskreaun yn werf.yaml, opfolgjend. It is needsaaklik om it proses fan it sammeljen fan ûnôfhinklike stadia fan bylden en artefakten parallel te meitsjen, en ek handige en ynformative útfier te leverjen.
* Opmerking: de deadline is ferskood fanwegen ferhege prioriteit foar it útfieren fan ferdielde gearstalling, wat mear horizontale skaalmooglikheden sil tafoegje, lykas ek it brûken fan werf mei GitHub Actions. Parallelle gearstalling is de folgjende optimisaasjestap, dy't fertikale skaalberens leveret by it gearstallen fan ien projekt.
Oergong nei Helm 3 (↓)
- Ferzje: 1.2
- Data: febrewaris-maart mei*
Omfettet migraasje nei nije codebase en in bewezen, handige manier om besteande ynstallaasjes te migrearjen.
* Opmerking: oerskeakelje nei Helm 3 sil gjin wichtige funksjes tafoegje oan werf, om't alle haadfunksjes fan Helm 3 (3-way-merge en gjin tiller) al yn werf ymplementearre binne. Boppedat hat werf neist de oantsjutte. Dizze oergong bliuwt lykwols yn ús plannen en sil útfierd wurde.
Jsonnet foar it beskriuwen fan Kubernetes-konfiguraasje (↓)
- Ferzje: 1.2
- Data: jannewaris-febrewaris april-mei
Werf sil konfiguraasjebeskriuwings foar Kubernetes stypje yn Jsonnet-formaat. Tagelyk bliuwt werf kompatibel mei Helm en komt der in kar foar beskriuwingsformaat.
De reden is dat Go-sjabloanen, neffens in protte minsken, in hege yngongsbarriêre hawwe, en de fersteanberens fan 'e koade fan dizze sjabloanen lijt ek.
De mooglikheid om oare Kubernetes-konfiguraasjebeskriuwingssystemen yn te fieren (bygelyks Kustomize) wurdt ek beskôge.
Wurkje binnen Kubernetes (↓)
- Ferzje: 1.2
- Data: april-mei-mei-juni
Doel: Soargje derfoar dat ôfbyldings binne boud en de applikaasje wurdt levere mei runners yn Kubernetes. Dy. Nije ôfbyldings kinne wurde boud, publisearre, skjinmakke en ynset direkt fan Kubernetes pods.
Om dizze mooglikheid út te fieren, moatte jo earst ferdielde ôfbyldings kinne bouwe (sjoch punt hjirboppe).
It fereasket ek stipe foar de bestjoeringsmodus fan 'e bouwer sûnder in Docker-tsjinner (dat wol sizze Kaniko-like build of build in userspace).
Werf sil it bouwen op Kubernetes stypje net allinich mei Dockerfile, mar ek mei har Stapel-bouwer mei inkrementele werbou en Ansible.
In stap nei iepen ûntwikkeling
Wy hâlde fan ús mienskip (, ) en wy wolle dat hieltyd mear minsken meihelpe om werf better te meitsjen, begripe de rjochting wêryn wy geane en meidwaan oan de ûntwikkeling.
Heel koartlyn waard besletten om oer te skeakeljen nei om it wurkproses fan ús team te iepenbierjen. No kinne jo de direkte plannen sjen, lykas aktueel wurk op 'e folgjende gebieten:
- ;
- ;
- ;
- .
In protte wurk is dien mei problemen:
- Ferwiderje irrelevante.
- De besteande wurde yn ien opmaak brocht, mei in foldwaande oantal details en details.
- Nije problemen mei ideeën en suggestjes binne tafoege.
Hoe kinne jo ferzje v1.1 ynskeakelje
De ferzje is op it stuit beskikber yn (yn kanalen stâl и rotsfêst releases sille ferskine as stabilisaasje optreedt, lykwols ea sels is al stabyl genôch foar gebrûk, omdat gie troch de kanalen alpha и Beta). Aktivearre op de folgjende wize:
source $(multiwerf use 1.1 ea)
werf COMMAND ...konklúzje
De nije poadiumopslacharsjitektuer en bouweroptimisaasjes foar Stapel- en Dockerfile-bouwers iepenje de mooglikheid om distribúsje- en parallelbouwen yn werf út te fieren. Dizze funksjes sille ynkoarten ferskine yn deselde v1.1-release en sille automatysk beskikber wurde fia it meganisme foar automatyske bywurking (foar brûkers ).
Yn dizze release is in taggingstrategy basearre op ôfbyldingynhâld tafoege - ynhâld-basearre tagging, dat is wurden de standert strategy. It haadkommandolog is ek opnij bewurke: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
De folgjende wichtige stap is om ferdielde gearkomsten ta te foegjen. Ferdielde builds binne sûnt v1.0 in hegere prioriteit wurden as parallelle builds, om't se mear wearde tafoegje oan werf: fertikale skaalfergrutting fan bouwers en stipe foar efemere bouwers yn ferskate CI/CD-systemen, en ek de mooglikheid om offisjele stipe te meitsjen foar GitHub Actions . Dêrom waarden de útfieringsterminen foar parallelle gearkomsten ferskood. Wy wurkje lykwols om beide mooglikheden sa gau mooglik út te fieren.
Folgje it nijs! En ferjit net om ús te besykjen by om in probleem te meitsjen, fine in besteande en foegje in plus ta, meitsje in PR, of sjoch gewoan de ûntwikkeling fan it projekt.
PS
Lês ek op ús blog:
- «»
- «";
- In rige notysjes oer ynnovaasjes yn werf:
- «";
- «";
- «";
- «".
Boarne: www.habr.com