— vores open source GitOps CLI-værktøj til opbygning og levering af applikationer i Kubernetes. Som lovet, markerede begyndelsen på tilføjelsen af nye funktioner til werf og en revision af de kendte tilgange. Nu er vi glade for at præsentere udgivelsen v1.1, som er et stort skridt fremad og en base for fremtiden. bygger werf. Versionen er i øjeblikket tilgængelig i .
Grundlaget for udgivelsen er en ny arkitektur til stadieopbevaring og optimering af arbejdet i begge byggere (for Stapel og Dockerfile). Den nye arkitektur for opbevaring åbner op for mulighederne for at realisere distribuerede bygninger fra flere værter og parallelle bygninger på én vært.
Optimeringen af arbejdet inkluderer at eliminere unødige beregninger på stadie-signaturberegningstrinnet og ændre mekanismerne til beregning af filchecksums til mere effektive. Denne optimering reducerer den gennemsnitlige byggetid for projekter med werf. Og tomme bygninger, når alle stadier findes i cachen, stages-storage, er nu virkelig hurtige. I de fleste tilfælde vil en genstart af bygningen tage mindre end 1 sekund! Dette gælder også for verificeringsprocedurerne for stadier under arbejdet med holdene werf deploy og werf run.
Denne udgave introducerer også en strategi for billedtagging baseret på indhold — content-based tagging, som nu er aktiveret som standard og er den eneste anbefalede.
Lad os se nærmere på de vigtigste nyheder i werf v1.1, og samtidig fortælle om fremtidsplanerne.
Hvad er ændret i werf v1.1?
Nyt navnformat for stadier og algoritme til valg af stadier fra cachen
Ny regel for generering af et stadienavn. Nu genererer hver bygning af et stadie et unikt stadienavn, der består af 2 dele: signatur (som i v1.0) plus en unik tidsstempelidentifikator.
For eksempel kan det fulde navn på stadiebilledet se således ud:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… eller i generel form:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Her:
-
SIGNATURE— er signaturen for stadiet, som repræsenterer en identifikator for indholdet af stadiet og afhænger af historikken af ændringer i Git, der førte til dette indhold; -
TIMESTAMP_MILLISEC— er et garanteret unikt identifikator for billedet, der genereres på tidspunktet for bygningen af det nye billede.
Algoritmen til valg af stadier fra cachen er baseret på kontrol af slægtskab mellem Git-commits:
- Werf beregner signaturen for en given fase.
- I stages-storage Der kan eksistere flere faser for denne signatur. Werf vælger alle passende faser efter signaturen.
- Hvis den aktuelle fase er relateret til Git (git-archive, brugerdefineret fase med Git-patches:
installation,beforeSetup,setup; eller git-latest-patch), vælger werf kun de faser, der er relateret til den commit, der er en forfader til den aktuelle commit (for hvilken bygningen er kaldt). - Af de resterende passende faser vælges en — den ældste efter oprettelsesdato.
Fasen for forskellige Git-grene kan have den samme signatur. Men werf vil forhindre brugen af cache, der er relateret til forskellige grene, mellem disse grene, selvom signaturerne er identiske.
.
Ny algoritme til oprettelse og gemming af faser i fase-lageret
Hvis werf ikke finder en passende fase under cache-søgningen, initieres processen med at opbygge en ny fase.
Lad os bemærke, at flere processer (på en eller flere værter) kan begynde at bygge den samme fase på omtrent samme tid. Werf bruger en optimistisk låsningsalgoritme stages-storage på tidspunktet for gemning af det nyopbyggede billede i stages-storage. Så når den nye fase er klar, låser werf stages-storage og gemmer det nyopbyggede billede der, kun hvis der ikke allerede findes et passende billede (efter signatur og andre parametre — se den nye algoritme til cache-søgning af faser).
Det nyopbyggede billede vil garanteret have en unik identifikator efter TIMESTAMP_MILLISEC (se det nye navngivningsformat for faser). I tilfælde af at der findes et passende billede i stages-storage , vil werf forkaste det nyopbyggede billede og bruge billedet fra cachen.
Med andre ord: den første proces, der afslutter opbygningen af billedet (den hurtigste), får ret til at gemme det i stages-storage (og derefter vil dette ene billede blive brugt til alle opbygninger). Den langsomme opbygningsproces vil aldrig blokere den hurtigere proces fra at gemme resultaterne af den aktuelle fase og gå videre til bygningen af den næste.
.
Forbedret ydeevne for Dockerfile byggeren
I øjeblikket består pipeline-faserne for billedet, der bygges fra Dockerfile, af en enkelt fase — dockerfile. Ved beregning af signaturen tages der hensyn til checksummerne for filerne context, som vil blive brugt under opbygningen. Før denne opgradering gennemgik werf rekursivt alle filer og beregnede en kontrolsum ved at opsummere konteksten og modulerne af hver fil. Fra versionerne v1.1 kan werf bruge de beregnede kontrolsummer, der er gemt i Git-repositoriet.
I bunden af algoritmen ligger . Algoritmen tager højde for posterne i .dockerignore og gennemgår rekursivt filstrukturen kun når det er nødvendigt. På den måde er vi frigjort fra at læse filsystemet, og algoritmens afhængighed af størrelsen på context er ikke betydelig.
Algoritmen tjekker også untracked-filer og medtager dem i kontrolsummen, når det er nødvendigt.
Ydelsen ved import af filer er forbedret
I versionerne af werf v1.1 anvendes en rsync-server ved . Tidligere blev importen udført i to trin ved at montere et bibliotek fra værtsystemet.
Ydelsen ved importer på macOS er ikke længere begrænset af Docker-volumener, og importer udføres på samme tid som i Linux og Windows.
Indholdbaseret tagging
Werf v1.1 understøtter den såkaldte tagging baseret på indholdet af et billede — content-based tagging. Tagene til de resulterende Docker-billeder afhænger af indholdet af disse billeder.
Når du kører kommandoen werf publish --tags-by-stages-signature eller werf ci-env --tagging-strategy=stages-signature vil tagges med den såkaldte stadiesignatur af billedet. Hvert billede tagges med sin egen stadiesignatur, der beregnes efter de samme regler som den almindelige signatur for hver enkelt fase, men som er en generaliserende identifikator for billedet.
Stadiesignaturen for billedet afhænger af:
- indholdet af dette billede;
- historien om ændringer i Git, der førte til dette indhold.
I Git-repositoriet findes der altid tomme commits, som ikke ændrer indholdet af billedfilerne. For eksempel commits med kun kommentarer eller merge-commits, eller commits, der ændrer de filer i Git, som ikke vil blive importeret til billedet.
Ved brug af indholdbaseret tagging løses problemerne med unødvendige genstart af pod'er i applikationen i Kubernetes på grund af ændringer i billednavnet, selvom indholdet af billedet ikke er ændret. Dette er for øvrigt en af årsagerne til, at det er besværligt at gemme mange mikrotjenester af én applikation i et enkelt Git-repositorium.
Content-based tagging er en mere pålidelig metode til tagging end tagging baseret på Git-grene, fordi indholdet af de resulterende billeder ikke afhænger af rækkefølgen af pipeline-udførelser i CI-systemet til opbygning af flere commits fra den samme gren.
Det er vigtigtfra dette øjeblik stages-signature — det er den eneste anbefalede tagging-strategi. Denne vil blive brugt som standard i teamet werf ci-env (medmindre en anden tagging-scheme angives tydeligt).
. Denne funktion vil også blive dækket i en separat publikation. OPDATERET (3. april): Artikel med detaljer .
Loggerniveauer
Brugeren har nu mulighed for at kontrollere output, angive loggerniveauet og arbejde med debugging-information. Mulighederne er tilføjet --log-quiet, --log-verbose, --log-debug.
Som standard indeholder output minimum information:
Ved brug af detaljeret output (--log-verbose) kan man følge, hvordan werf fungerer:
Det detaljerede output (--log-debug), ud over debugging-informationen fra werf, indeholder også logs fra de anvendte biblioteker. Man kan for eksempel se, hvordan interaktionen med Docker Registry foregår, samt registrere steder, hvor der bruges væsentlig tid:
Fremtidige planer
Opmærksomhed! De følgende funktioner markeret med v1.1 vil være tilgængelige i denne version, mange af dem - snart. Opdateringer vil komme via autoopdateringer . Disse funktioner berører ikke den stabile del af funktionerne i v1.1, deres fremkomst kræver ingen manuel indgriben fra brugeren i eksisterende konfigurationer.
Fuld støtte til forskellige implementeringer af Docker Registry (NYT)
- Version: v1.1
- Tidsramme: marts
Målet er, at brugeren skal kunne bruge enhver implementering uden begrænsninger, når de bruger werf.
I øjeblikket har vi identificeret følgende sæt løsninger, som vi agter at sikre fuld støtte til:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Løsninger markeret med en stjerne er i øjeblikket allerede fuldt understøttet af werf. For de øvrige er der støtte, men med begrænsninger.
Der kan identificeres to hovedproblemer:
- Nogle løsninger understøtter ikke sletning af tags via Docker Registry API, hvilket ikke giver brugerne mulighed for at bruge den automatiske oprydning, der er implementeret i werf. Dette gælder for AWS ECR, Docker Hub og GitHub Packages.
- Nogle løsninger understøtter ikke såkaldte nested repositories (Docker Hub, GitHub Packages og Quay) eller understøtter dem, men brugeren skal oprette dem manuelt ved hjælp af UI eller API (AWS ECR).
Disse og andre problemer planlægger vi at løse ved at bruge de native API'er fra løsningerne. Denne opgave inkluderer også testdækning af hele arbejdsflowet i werf for hver af dem.
Distribueret bygning af billeder (↑)
- Version: v1.2 v1.1 (prioriteten for implementeringen af denne funktion er blevet forøget)
- Tidsrammer: marts-april marts
I øjeblikket kan werf v1.0 og v1.1 kun bruges på én dedikeret vært til bygning og publicering af billeder og deployment af applikationer i Kubernetes.
For at åbne mulighederne for distribueret arbejde med werf, hvor bygning og deployment af applikationer i Kubernetes kører på flere tilfældige værtssystemer, og disse værtssystemer ikke bevarer deres tilstand mellem bygninger (midlertidige runners), kræver werf implementering af muligheden for at bruge Docker Registry som lagringssted for faser.
Tidligere, da projektet werf stadig hed dapp, var der denne funktion. Men vi stødte på en række problemer, der skal tages i betragtning ved implementeringen af denne funktion i werf.
Bemærk. Denne mulighed forudsætter ikke, at byggeren arbejder indenfor pods i Kubernetes, da det ville kræve at slippe af med afhængigheden af den lokale Docker-server (i pod'en Kubernetes er der ikke adgang til den lokale Docker-server, fordi selve processen kører i en container, og netværksarbejde med Docker-serveren understøttes ikke af werf og vil ikke blive understøttet). Støtte til arbejde i Kubernetes vil blive implementeret separat.
Officiel support for GitHub Actions (NY)
- Version: v1.1
- Tidsramme: marts
Inkluderer dokumentationen for werf (afsnit reference og guide), samt den officielle GitHub Action til arbejde med werf.
Desuden vil det muliggøre, at werf kan arbejde på efemerale runners.
Interaktionen mellem brugeren og CI-systemet vil være baseret på tildeling af labels til pull-requests for at iværksætte bestemte handlinger til bygning/deployment af applikationen.
Lokal udvikling og deployment af applikationer med werf (↓)
- Version: v1.1
- Tidsrammer: januar-februar april
Hovedmålet er at opnå en ensartet konfiguration til deployment af applikationer både lokalt og i produktion, uden komplicerede handlinger, "out of the box".
werf kræver også en arbejdsmetode, hvor det er nemt at redigere applikationens kode og straks få feedback fra den kørende applikation til debugging.
Ny oprydningsalgoritme (NY)
- Version: v1.1
- Frister: april
I den nuværende version af werf v1.1 i proceduren cleanup er der ikke inkluderet oprydning af billeder til indholdsbaseret tagging — disse billeder vil hobe sig op.
I den nuværende version af werf (v1.0 og v1.1) anvendes forskellige oprydningspolitikker for billeder offentliggjort efter tagging-skemer: Git-gren, Git-tag eller Git-commit.
En ny, ensartet oprydningsalgoritme for alle tagging-skemer er blevet udviklet baseret på commit-historikken i Git:
- Opbevar ikke mere end N1 billeder, der er relateret til de N2 seneste commits for hver git HEAD (gren og tags).
- Opbevar ikke mere end N1 billed-faser, der er relateret til de N2 seneste commits for hver git HEAD (gren og tags).
- Opbevar alle billeder, der bruges i eventuelle ressourcer i Kubernetes-klusteret (alle kube-kontekster i konfigurationsfilen og namespaces scannes; denne adfærd kan begrænses med særlige indstillinger).
- Opbevar alle billeder, der bruges i konfigurationsressource-manifester gemt i Helm-udgivelser.
- Et billede kan fjernes, hvis det ikke er relateret til nogen HEAD fra git (for eksempel fordi den pågældende HEAD blev slettet) og ikke bruges i nogen af manifestterne i Kubernetes-klusteret og i Helm-udgivelser.
Parallel bygning af billeder (↓)
- Version: v1.1
- Frister: januar-februar april*
Den nuværende version af werf bygger billeder og artefakter, som er beskrevet i werf.yaml, sekventielt. Det er nødvendigt at parallelisere processen med at bygge uafhængige faser af billeder og artefakter samt sikre en praktisk og informativ output.
* Bemærk: Fristen er flyttet på grund af øget prioritet for implementeringen af distribueret byggeri, hvilket vil tilføje flere muligheder for horisontal skalerbarhed samt brug af werf med GitHub Actions. Den parallelle bygning er næste trin i optimeringen, som giver vertikal skalerbarhed ved bygning af et enkelt projekt.
Overgang til Helm 3 (↓)
- Version: v1.2
- Frister: februar-marts maj*
Omfatter overgangen til den nye kodebase og en velafprøvet, brugervenlig metode til migrering af eksisterende installationer.
* Bemærk: Overgangen til Helm 3 vil ikke tilføre betydelige funktioner til werf, da alle nøglefunktioner i Helm 3 (3-way-merge og fraværet af tiller) allerede er implementeret i werf. Desuden har werf ud over dem, der er nævnt. Denne overgang er dog stadig på vores liste og vil blive gennemført.
Jsonnet til beskrivelse af Kubernetes-konfiguration (↓)
- Version: v1.2
- Tidsramme: januar-februar april-maj
Werf vil understøtte beskrivelsen af konfigurationer for Kubernetes i Jsonnet-format. Samtidig forbliver werf kompatibel med Helm, og der vil være mulighed for at vælge beskrivelsesformat.
Årsagen hertil er, at skabelonerne i Go-sproget, ifølge mange vurderinger, har en høj indlæringskurve, og læsbarheden af koden i disse skabeloner er også påvirket.
Der overvejes også muligheden for at implementere andre systemer til beskrivelse af Kubernetes-konfiguration (f.eks. Kustomize).
Arbejdet inden for Kubernetes (↓)
- Version: v1.2
- Tidsramme: april-maj maj-juni
Mål: at muliggøre opbygning af billeder og levering af applikationen ved hjælp af runners i Kubernetes. Det vil sige, at nye billeder kan bygges, publiceres, rengøres og deployeres direkte fra Kubernetes-pods.
For at realisere denne mulighed er først muligheden for distribueret opbygning af billeder nødvendig (se punkt ovenfor).
Der kræves også understøttelse af en byggemåde uden Docker-server (dvs. Kaniko-lignende byggeri eller bygning i userspace).
Werf vil understøtte byggeri i Kubernetes ikke kun ved hjælp af Dockerfile, men også ved hjælp af sin egen opsamler Stapel med inkrementelle opbygninger og Ansible.
Et skridt mod åben udvikling
Vi elsker vores fællesskab (, ) og ønsker, at flere mennesker hjælper med at gøre werf bedre, forstår, hvilken retning vi bevæger os i, og deltager i udviklingen.
For nylig blev det besluttet at skifte til for at åbne op for vores teams arbejdsgange. Det er nu muligt at se de kommende planer samt det aktuelle arbejde inden for følgende områder:
- ;
- ;
- ;
- .
Der er gjort meget arbejde med issues:
- Uaktuelle er fjernet.
- Eksisterende er bragt til et ensartet format med tilstrækkelig detaljer og beskrivelse.
- Nye issues med idéer og forslag er blevet tilføjet.
Sådan aktiveres version v1.1
Versionen er i øjeblikket tilgængelig i (i kanalerne stable og rock-solid udgivelser vil komme, efterhånden som de stabiliseres, men ea den er allerede stabil nok til brug, da den har passeret gennem kanalerne alpha og beta). Aktiveres på følgende måde:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Konklusion
Den nye arkitektur til opbevaring af stadier og optimering af samlerens arbejde for Stapel og Dockerfile-aggregatorer åbner muligheder for at implementere distribuerede og parallelle builds i werf. Disse funktioner vil snart være tilgængelige i version 1.1 og bliver automatisk tilgængelige gennem autoopdateringsmekanismen (for brugere ).
I denne udgivelse er der tilføjet en strategi for taggning efter billedindhold - content-based tagging, - som er blevet standardstrategi. Desuden er loggen over primære kommandoer blevet revideret: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Næste væsentlige skridt vil være tilføjelsen af distribuerede builds. Distribuerede builds er siden version 1.0 blevet en højere prioritet end parallelle builds, da de tilføjer mere værdi til werf: vertikal skalering af samlere og støtte til ephemeral samlere i forskellige CI/CD-systemer, samt muligheden for at implementere officiel støtte til GitHub Actions. Derfor er tidsrammen for implementering af parallelle builds blevet flyttet. Men vi arbejder på at implementere begge muligheder hurtigst muligt.
Hold dig opdateret! Og glem ikke at tjekke ind hos os på , for at oprette en issue, finde en eksisterende og give den et plus, oprette en PR eller bare følge udviklingen af projektet.
P.S.
Læs også på vores blog:
- «»
- «»;
- Cykelnotater om nyheder i werf:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
