er vores open source GitOps CLI-værktøj til at bygge og levere applikationer til Kubernetes. Som lovet, markerede begyndelsen på at tilføje nye funktioner til werf og revidere traditionelle tilgange. Nu er vi glade for at kunne præsentere release v1.1, som er et stort skridt i udviklingen og et fundament for fremtiden samler werf. Versionen er i øjeblikket tilgængelig i .
Grundlaget for udgivelsen er den nye arkitektur for scenelagring og optimering af begge samleres arbejde (til Stapel og Dockerfile). Den nye lagerarkitektur åbner mulighed for at implementere distribuerede assemblies fra flere værter og parallelle assemblies på samme vært.
Optimering af arbejde omfatter at slippe af med unødvendige beregninger på stadiet med beregning af fasesignaturer og ændring af mekanismerne til beregning af filkontrolsummer til mere effektive. Denne optimering reducerer den gennemsnitlige tid for projektopbygning ved hjælp af werf. Og inaktive builds, når alle stadier findes i cachen etaper-opbevaring, er nu rigtig hurtige. I de fleste tilfælde vil genstart af builden tage mindre end 1 sekund! Dette gælder også procedurer for verificering af stadier i teams arbejde. werf deploy и werf run.
Også i denne udgivelse dukkede en strategi til at tagge billeder efter indhold op - indholdsbaseret tagging, som nu er aktiveret som standard og den eneste anbefalede.
Lad os se nærmere på de vigtigste innovationer i werf v1.1, og samtidig fortælle dig om planer for fremtiden.
Hvad er ændret i werf v1.1?
Nyt trinnavneformat og algoritme til at vælge trin fra cachen
Ny regel for generering af scenenavne. Nu genererer hver scenebygning et unikt scenenavn, som består af 2 dele: en signatur (som den var i v1.0) plus en unik midlertidig identifikator.
For eksempel kan navnet på det fulde scenebillede se sådan ud:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...eller generelt:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
her:
-
SIGNATUREer en scenesignatur, som repræsenterer identifikatoren for sceneindholdet og afhænger af historikken for redigeringer i Git, der førte til dette indhold; -
TIMESTAMP_MILLISECer en garanteret unik billedidentifikator, der genereres på det tidspunkt, hvor et nyt billede bygges.
Algoritmen til at vælge stadier fra cachen er baseret på at kontrollere forholdet mellem Git-commits:
- Werf beregner signaturen for et bestemt trin.
- В etaper-opbevaring Der kan være flere stadier for en given signatur. Werf udvælger alle stadier, der matcher signaturen.
- Hvis den aktuelle fase er knyttet til Git (git-arkiv, brugerdefineret fase med Git-patches:
install,beforeSetup,setup; eller git-latest-patch), så vælger werf kun de stadier, der er forbundet med en commit, der er en forfader til den aktuelle commit (som bygningen kaldes for). - Fra de resterende passende stadier vælges en - den ældste efter oprettelsesdato.
En scene for forskellige Git-grene kan have den samme signatur. Men werf forhindrer cachen, der er forbundet med forskellige grene, i at blive brugt mellem disse grene, selvom signaturerne matcher.
.
Ny algoritme til at oprette og gemme stadier i scenelageret
Hvis werf ikke finder et passende trin ved valg af trin fra cachen, påbegyndes processen med at samle et nyt trin.
Bemærk, at flere processer (på en eller flere værter) kan begynde at bygge den samme fase på omtrent samme tid. Werf bruger en optimistisk blokeringsalgoritme etaper-opbevaring i det øjeblik, hvor det nysamlede billede gemmes etaper-opbevaring. På denne måde, når den nye scenebygning er klar, blokerer werf etaper-opbevaring og gemmer kun et frisk indsamlet billede der, hvis et passende billede ikke længere findes der (ved signatur og andre parametre - se den nye algoritme for valg af stadier fra cachen).
Et nysamlet billede har med garanti en unik identifikator TIMESTAMP_MILLISEC (se nyt format for scenenavn). I tilfældet i etaper-opbevaring et passende billede vil blive fundet, werf vil kassere det nyligt kompilerede billede og bruge billedet fra cachen.
Med andre ord: den første proces, der afslutter opbygningen af billedet (den hurtigste) vil få ret til at gemme det i etaper-lagring (og så er det dette enkelte billede, der vil blive brugt til alle builds). En langsom byggeproces vil aldrig blokere en hurtigere proces fra at gemme byggeresultaterne fra det nuværende trin og gå videre til næste build.
.
Forbedret Dockerfile builder ydeevne
I øjeblikket består pipelinen af trin for et billede bygget fra en Dockerfile af et trin - dockerfile. Ved beregning af signaturen beregnes kontrolsummen af filerne context, som vil blive brugt under montagen. Før denne forbedring gik werf rekursivt gennem alle filer og opnåede en kontrolsum ved at summere konteksten og tilstanden for hver fil. Startende med v1.1 kan werf bruge beregnede kontrolsummer gemt i et Git-lager.
Algoritmen er baseret på . Algoritmen tager højde for poster i .dockerignore og krydser filtræet kun rekursivt, når det er nødvendigt. Således har vi afkoblet læsning af filsystemet, og algoritmens afhængighed af størrelsen context er ikke væsentlig.
Algoritmen kontrollerer også usporede filer og tager dem om nødvendigt i betragtning i kontrolsummen.
Forbedret ydeevne ved import af filer
Versioner af werf v1.1 bruger en rsync-server, når . Tidligere blev importen udført i to trin ved hjælp af en mappemontering fra værtssystemet.
Importydelsen på macOS er ikke længere begrænset af Docker-volumener, og importen gennemføres på samme tid som Linux og Windows.
Indholdsbaseret tagging
Werf v1.1 understøtter såkaldt tagging efter billedindhold - indholdsbaseret tagging. Mærkerne for 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 offentliggjorte billeder af den såkaldte scenesignatur billede. Hvert billede er mærket med sin egen signatur af stadierne i dette billede, som beregnes efter de samme regler som den almindelige signatur for hver etape separat, men er en generel identifikator for billedet.
Signaturen for billedstadierne afhænger af:
- indholdet af dette billede;
- historier om Git-ændringerne, der førte til dette indhold.
Et Git-lager har altid dummy-commits, der 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 indholdsbaseret tagging løses problemerne med unødvendige genstarter af applikationspods i Kubernetes på grund af ændringer i billednavnet, selvom indholdet af billedet ikke er ændret. Dette er i øvrigt en af grundene til, at det forhindrer lagring af mange mikrotjenester af en applikation i et enkelt Git-lager.
Indholdsbaseret tagging er også en mere pålidelig tagging-metode end tagging på Git-grene, fordi indholdet af de resulterende billeder ikke afhænger af rækkefølgen, hvori pipelines udføres i CI-systemet til at samle flere commits af den samme branche.
Det er vigtigt: starter fra nu etaper-signatur - Er den eneste anbefalede tagging-strategi. Det vil blive brugt som standard i kommandoen werf ci-env (medmindre du udtrykkeligt angiver et andet taggingskema).
. En separat publikation vil også blive viet til denne funktion. OPDATERET (3. april): Artikel med detaljer .
Logningsniveauer
Brugeren har nu mulighed for at styre outputtet, indstille logningsniveauet og arbejde med debugging information. Indstillinger tilføjet --log-quiet, --log-verbose, --log-debug.
Som standard indeholder output minimum information:
Når du bruger verbose output (--log-verbose) kan du se, hvordan werf fungerer:
Detaljeret output (--log-debug), udover werf debugging information, indeholder også logfiler over brugte biblioteker. For eksempel kan du se, hvordan interaktion med Docker Registry opstår, og du kan også registrere de steder, hvor der bruges en betydelig mængde tid:
Fremtidsplaner
Advarsel! Valgmulighederne beskrevet nedenfor er markeret v1.1 vil blive tilgængelige i denne version, mange af dem i den nærmeste fremtid. Opdateringer kommer via automatiske opdateringer . Disse funktioner påvirker ikke den stabile del af v1.1-funktioner; deres udseende kræver ikke manuel brugerindgreb i eksisterende konfigurationer.
Fuld support til forskellige Docker Registry implementeringer (NYT)
- Version: v1.1
- Datoer: marts
Målet er, at brugeren skal bruge en tilpasset implementering uden begrænsninger ved brug af werf.
I øjeblikket har vi identificeret følgende sæt løsninger, som vi vil garantere fuld support til:
- Standard (bibliotek/registrering)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub-pakker
- GitLab Registry*,
- Havn*,
- Kaj.
Løsninger, der i øjeblikket er fuldt understøttet af werf, er markeret med en stjerne. For andre er der støtte, men med begrænsninger.
To hovedproblemer kan identificeres:
- Nogle løsninger understøtter ikke fjernelse af tags ved hjælp af Docker Registry API, hvilket forhindrer brugere i at bruge werfs automatiske oprydning. Dette gælder for AWS ECR, Docker Hub og GitHub-pakker.
- Nogle løsninger understøtter ikke såkaldte indlejrede repositories (Docker Hub, GitHub-pakker og Quay) eller gør det, men brugeren skal oprette dem manuelt ved hjælp af UI eller API (AWS ECR).
Vi vil løse disse og andre problemer ved hjælp af native API'er af løsningerne. Denne opgave omfatter også dækning af den fulde cyklus af werfdrift med test for hver af dem.
Distribueret billedopbygning (↑)
- Version: v1.2 v1.1 (prioriteten for implementering af denne funktion er blevet øget)
- Datoer: marts-april marts
I øjeblikket kan werf v1.0 og v1.1 kun bruges på én dedikeret vært til operationer med at bygge og udgive billeder og implementere applikationen til Kubernetes.
For at åbne op for mulighederne for distribueret arbejde af werf, når opbygning og implementering af applikationer i Kubernetes lanceres på flere vilkårlige værter, og disse værter ikke gemmer deres tilstand mellem builds (midlertidige løbere), er werf forpligtet til at implementere muligheden for at bruge Docker Registry som scenebutik.
Tidligere, da werf-projektet stadig hed dapp, havde det sådan en mulighed. Vi er dog stødt på en række problemer, der skal tages i betragtning, når denne funktionalitet implementeres i werf.
Bemærk. Denne funktion kræver ikke, at samleren arbejder inde i Kubernetes pods, fordi For at gøre dette skal du slippe af med afhængigheden af den lokale Docker-server (i Kubernetes-poden er der ingen adgang til den lokale Docker-server, fordi selve processen kører i en container, og werf understøtter ikke og vil ikke understøtte arbejder med Docker-serveren over netværket). Support til at køre Kubernetes vil blive implementeret separat.
Officiel support til GitHub Actions (NY)
- Version: v1.1
- Datoer: marts
Inkluderer werf dokumentation (afsnit henvisningen и vejlede), samt den officielle GitHub Action for at arbejde med werf.
Derudover vil det give werf mulighed for at arbejde på flygtige løbere.
Mekanikken for brugerinteraktion med CI-systemet vil være baseret på at placere etiketter på pull-anmodninger for at igangsætte bestemte handlinger for at bygge/udrulle applikationen.
Lokal udvikling og implementering af applikationer med werf (↓)
- Version: v1.1
- Datoer: januar-februar april
Hovedmålet er at opnå en enkelt samlet konfiguration til udrulning af applikationer både lokalt og i produktionen uden komplekse handlinger.
werf skal også have en driftstilstand, hvor det vil være praktisk at redigere applikationskoden og øjeblikkeligt modtage feedback fra den kørende applikation til fejlretning.
Ny rengøringsalgoritme (NY)
- Version: v1.1
- Datoer: april
I den nuværende version af werf v1.1 i proceduren cleanup Der er ingen mulighed for at rense billeder til den indholdsbaserede tagging-ordning - disse billeder vil akkumulere.
Den nuværende version af werf (v1.0 og v1.1) bruger også forskellige oprydningspolitikker for billeder udgivet under tagging-skemaer: Git branch, Git tag eller Git commit.
En ny algoritme til rensning af billeder baseret på historien om commits i Git, samlet for alle tagging-skemaer, er blevet opfundet:
- Hold ikke mere end N1 billeder forbundet med de N2 seneste commits for hver git HEAD (grene og tags).
- Gem ikke mere end N1 scenebilleder forbundet med de N2 seneste commits for hver git HEAD (grene og tags).
- Gem alle billeder, der bruges i alle Kubernetes-klyngressourcer (alle kube-kontekster i konfigurationsfilen og navneområderne scannes; du kan begrænse denne adfærd med specielle indstillinger).
- Gem alle billeder, der bruges i ressourcekonfigurationsmanifester, der er gemt i Helm-udgivelser.
- Et billede kan slettes, hvis det ikke er forbundet med nogen HEAD fra git (for eksempel fordi det tilsvarende HEAD selv blev slettet) og ikke bruges i nogen manifester i Kubernetes-klyngen og i Helm-udgivelser.
Parallel billedopbygning (↓)
- Version: v1.1
- Datoer: januar-februar april*
Den nuværende version af werf samler billederne og artefakter, der er beskrevet i werf.yaml, sekventielt. Det er nødvendigt at parallelisere processen med at samle uafhængige stadier af billeder og artefakter samt give et praktisk og informativt output.
* Bemærk: deadline er blevet flyttet på grund af øget prioritet for implementering af distribueret samling, hvilket vil tilføje flere horisontale skaleringsmuligheder, samt brugen af werf med GitHub Actions. Parallel montering er det næste optimeringstrin, der giver lodret skalerbarhed ved samling af ét projekt.
Overgang til Helm 3 (↓)
- Version: v1.2
- Datoer: februar-marts maj*
Inkluderer migrering til ny kodebase og en gennemprøvet, bekvem måde at migrere eksisterende installationer på.
* Bemærk: Skift til Helm 3 vil ikke tilføje væsentlige funktioner til werf, fordi alle nøglefunktionerne i Helm 3 (3-vejs-fletning og ingen rorpind) allerede er implementeret i werf. Desuden har werf ud over de angivne. Denne overgang forbliver dog i vores planer og vil blive implementeret.
Jsonnet til beskrivelse af Kubernetes-konfiguration (↓)
- Version: v1.2
- Datoer: januar-februar april-maj
Werf understøtter konfigurationsbeskrivelser for Kubernetes i Jsonnet-format. Samtidig vil werf forblive kompatibel med Helm, og der vil være et valg af beskrivelsesformat.
Årsagen er, at Go-skabeloner ifølge mange mennesker har en høj adgangsbarriere, og forståelsen af koden for disse skabeloner lider også.
Muligheden for at introducere andre Kubernetes konfigurationsbeskrivelsessystemer (for eksempel Kustomize) overvejes også.
Arbejde inde i Kubernetes (↓)
- Version: v1.2
- Datoer: april-maj maj-juni
Mål: Sørg for, at billeder er bygget, og at applikationen leveres ved hjælp af løbere i Kubernetes. De der. Nye billeder kan bygges, publiceres, renses og implementeres direkte fra Kubernetes pods.
For at implementere denne mulighed skal du først være i stand til at bygge distribuerede billeder (se punkt ovenfor).
Det kræver også understøttelse af builder-driftstilstanden uden en Docker-server (dvs. Kaniko-lignende build eller indbygget brugerrum).
Werf vil understøtte bygning på Kubernetes ikke kun med Dockerfile, men også med sin Stapel-builder med trinvise genopbygninger og Ansible.
Et skridt mod åben udvikling
Vi elsker vores samfund (, ), og vi ønsker, at flere og flere mennesker hjælper med at gøre werf bedre, forstår den retning, vi bevæger os i, og deltager i udviklingen.
For ganske nylig blev det besluttet at skifte til for at afsløre vores teams arbejdsproces. Nu kan du se de umiddelbare planer, samt det aktuelle arbejde på følgende områder:
- ;
- ;
- ;
- .
Der er blevet arbejdet meget med problemer:
- Fjernede irrelevante.
- De eksisterende bringes til et enkelt format med et tilstrækkeligt antal detaljer og detaljer.
- Nye problemer med ideer og forslag er tilføjet.
Sådan aktiverer du version v1.1
Versionen er i øjeblikket tilgængelig i (i kanaler stabil и klippefast frigivelser vil dog blive vist efterhånden som stabilisering sker ea selv er allerede stabil nok til brug, fordi gik gennem kanalerne alpha и beta). Aktiveret på følgende måde:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Konklusion
Den nye scenelagringsarkitektur og builder-optimeringer for Stapel- og Dockerfile-byggere åbner muligheden for at implementere distribuerede og parallelle builds i werf. Disse funktioner vises snart i den samme version 1.1 og bliver automatisk tilgængelige via den automatiske opdateringsmekanisme (for brugere ).
I denne udgivelse er der tilføjet en tagging-strategi baseret på billedindhold - indholdsbaseret tagging, som er blevet standardstrategien. Hovedkommandologgen er også blevet omarbejdet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Det næste vigtige skridt er at tilføje distribuerede samlinger. Distribuerede builds er blevet en højere prioritet end parallelle builds siden v1.0, fordi de tilføjer mere værdi til werf: lodret skalering af buildere og understøttelse af flygtige buildere i forskellige CI/CD-systemer, samt muligheden for at lave officiel support til GitHub Actions . Derfor blev implementeringsfristerne for parallelle samlinger rykket. Vi arbejder dog på at implementere begge muligheder hurtigst muligt.
Følg nyhederne! Og glem ikke at besøge os kl at oprette et problem, finde et eksisterende og tilføje et plus, oprette en PR eller blot se udviklingen af projektet.
PS
Læs også på vores blog:
- «»
- «";
- En række noter om innovationer i werf:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com